this post was submitted on 12 Jul 2024
254 points (93.2% liked)
Technology
59374 readers
7416 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The argument still holds. If they have remote execution access, they already have your data. Encryption can't protect your data here because encrypted data will automatically become unencrypted once the user logs into the computer. If the attacker has remote access they can log into your account and the data will be unencrypted.
No, defense in depth is still important.
It's true that full-disk encryption is useless against remote execution attacks, because the attacker is already inside that boundary. (i.e., As you say, the OS will helpfully decrypt the file for the attacker.)
However, it's still useful to have finer-grained encryption of specific files. (Preferably in addition to full-disk encryption, which remains useful against other attack vectors.) i.e., Prompt the user for a password when the program starts, decrypt the data, and hold it in RAM that's only accessible to that running process. This is more secure because the attacker must compromise additional barriers. Physical access is harder than remote execution with root, which is harder than remote execution in general.
You don't need root (dump memory). You need the user password or to control the binary. Both of them relatively easy if you have user access. For example, change ENV variable to point to a patched binary first, spoof the password prompt, and then continue execution as the normal binary does.
Sure, but there's still no excuse for "store the password in plaintext lol". Once you've got user access, files at rest are trivial to obtain.
You're proposing what amounts to a phishing attack, which is more effort, more time, and more risk. Anything that forces the attacker to do more work and have more chances to get noticed is a step in the right direction. Don't let perfect be the enemy of good.
I am not proposing anything actually, I am implying that this change won't modify the threat model in any substantial way. Your comment implied that it kind of did, requiring root access - which is a slightly different tm, not so much on single user machines..
So my point is that "The data is safe until your user password is safe" is a very tiny change compared to "your data is safe until your device is safe". There are tons of ways to get the password once you have local access, and what I strongly disagree with is that it requires more work or risk. A sudo fake prompt requires a 10-lines bash script since you control the shell configuration, for example. And you don't even need to phish, you can simply create a SUID shell and use "sudo chmod +s shell" to any local configuration or script where the user runs a sudo command, and you are root, or you dump the keyring or...etc. Likewise, 99.9% of the users don't run integrity monitoring tools, or monitor and restrict egress access, so these attacks simply won't be noticed.
So what I am saying is that an encrypted storage is better than a plaintext storage for the key, but if this requires substantial energies from the devs that could have been put on work that substantially improved the security posture, it is a net negative in terms of security (I don't know if it is the case), and that nobody after this change should feel secure about their signal data in case their device would be compromised.