Signal is finally tightening its desktop client's security by changing how it stores plain text encryption keys for the data store after downplaying the issue since 2018.
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.
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.
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.
Also this isn’t how security works. Please refer to the Swiss cheese model.
Unless you can guarantee that every application ever installed on every computer will always be secure under every circumstances then you’re already breaking your security model.
An application may expose a vulnerable web server which may allow read only file system access without exposing the user to any direct control of their computer from an attacker. Now your lack of security posture for your application (signal) now has a shared fate to any other application anyone else built.
This is just one of many easy examples that are counter to your argument here.
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.
Removed by mod
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.
Removed by mod
They don’t necessarily need RCE access.
Also this isn’t how security works. Please refer to the Swiss cheese model.
Unless you can guarantee that every application ever installed on every computer will always be secure under every circumstances then you’re already breaking your security model.
An application may expose a vulnerable web server which may allow read only file system access without exposing the user to any direct control of their computer from an attacker. Now your lack of security posture for your application (signal) now has a shared fate to any other application anyone else built.
This is just one of many easy examples that are counter to your argument here.
Exactly. They just need to be able to send a file somewhere, and there are other attacks where they can do what w/o code execution.