Signal downplays encryption key flaw, fixes it after X drama
Signal downplays encryption key flaw, fixes it after X drama
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.
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.
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.
Yeah, I know about this. That's why backups are so important.
The whole drama seems to be pushing for Electron's safeStorage API, which uses a device's secrets manager. But aren't secrets stored there still accessible when the machine is unlocked anyway? I'm not sure what this change accomplishes other than encryption at rest with the device turned off - which is redundant if you're using full disk encryption.
I don't think they're downplaying it, it just doesn't seem to be this large security concern some people are making it to be.
This is like the third time in the past two months I've seen someone trying to spread FUD around Signal.
Yeah they are, this problem is super overblown. Weirdly I've seen articles about this coming up for other apps too, like the ChatGPT app for MacOS storing conversation history in plain text on the device. Weird that this is suddenly a problem.
If someone wants better security, the can use full disk encryption and encrypt their home directory and unlock it on login.
Security comes in layers, still better than storing the keys in plaintext, and FDE is also important.
This is like the third time in the past two months I’ve seen someone trying to spread FUD around Signal.
If any other messenger had the same issue, Moxie Marlinspike and fans would have an outcry on biblical proportions.
They do
But aren't secrets stored there still accessible when the machine is unlocked anyway?
I think the OS prevents apps from accessing data in those keychains, right? So there wouldn't be an automated/scriptable way to extract the key in as easy of a way.
But that's the thing: I haven't found anything that indicates it can differentiate a legitimate access from a dubious one; at least not without asking the user to authorize it by providing a password and causing the extra inconvenience.
If the wallet asked the program itself for a secret - to verify the program was legit and not a malicious script - the program would still have the same problem of storing and retrieving that secret securely; which defeats the use of a secret manager.
xz? twitter? x11? placeholder?
It's an equation. One of those "left for the reader". Please start solving it.