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.
I understand Signal’s stance on this. For this vulnerability, the attacker needs physical access to computer. If the attacker has already gained physical access, the attacker can already access your messages, crypto wallets, password managers.
Many password managers also have this flaw. For example, Someone can change Keepass master password if the user is already logged in to the session, if they have physical access to the PC and lock you out of all your accounts.
Yeah, this is why I added a hardware key to my db. The hardware key is required not just for reading the db, but writing to it as well.
Another tip: use something like an OnlyKey that has its own locking and self-destruct mechanisms so this method isn’t foiled by simply acquiring the key.
For example, Someone can change Keepass master password if the user is already logged in to the session, if they have physical access to the PC and lock you out of all your accounts.
This seems like easy fix is available. On Windows, Access Shadow copies, restore previous version from $DayBeforeLockout. Or on Linux, specific file systems have automatic volume level snapshotting available. Or on either…restore the keepass file from a backup before the change.
They don’t need physical access (hold the device in their hand), they just need a command execution, which is a much lower bar. I expect some defence in depth for an application that holds some of the most private information there is about me.
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.
I understand Signal’s stance on this. For this vulnerability, the attacker needs physical access to computer. If the attacker has already gained physical access, the attacker can already access your messages, crypto wallets, password managers.
Many password managers also have this flaw. For example, Someone can change Keepass master password if the user is already logged in to the session, if they have physical access to the PC and lock you out of all your accounts.
Yeah, this is why I added a hardware key to my db. The hardware key is required not just for reading the db, but writing to it as well.
Another tip: use something like an OnlyKey that has its own locking and self-destruct mechanisms so this method isn’t foiled by simply acquiring the key.
This seems like easy fix is available. On Windows, Access Shadow copies, restore previous version from $DayBeforeLockout. Or on Linux, specific file systems have automatic volume level snapshotting available. Or on either…restore the keepass file from a backup before the change.
Yeah, I know about this. That’s why backups are so important.
They don’t need physical access (hold the device in their hand), they just need a command execution, which is a much lower bar. I expect some defence in depth for an application that holds some of the most private information there is about me.
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.