As mentioned in the comments, plain text keys aren’t bad because they are necessary. You have to have at least one plain text key in order to be able to use encryption
I kind of agree that this may be a little overblown. Exploiting this requires device and filesystem access so if you can get the keys you can already get a lot more stuff.
deleted by creator
It’s eventually going to have to be stored in plaintext somewhere. Where are you then putting the encryption key for the encryption keys and how do you start the chain of decryption without the first key?
Sorry, I don’t think I understand what you’re suggesting. Are you saying encryption keys should themselves be encrypted?
FYI this story isn’t about plaintext passwords, it’s about plaintext encryption keys to chat history.
I deleted my reply, because I don’t know what I’m talking.
Also not a surprise because as the article notes it’s been known and discussed since at least 2018
How else should the keys be stored?
There are system specific encryption methods like keychain services on iOS to store exactly this kind of sensitive information.
In the device’s secure enclave (e.g. TPM).
After your edit, the post points to an image only, no longer the link to the source. Please edit back the link, if not at least into the body.
Fixed it! Thank you.
Isn’t Signal Open Source? If so, why is it a surprise then?
Its not a surprise but it has not really received a lot of attention since people have reported it.
https://github.com/signalapp/Signal-Desktop/issues/5751
Also signal as a service is not really open source because it is not selfhostable. The server backend is proprietary afaik.
The back end is open source, but sometimes they’ve lagged years behind releasing the source code. Other developers have stood up copies of the signal network. Session, for example.
You can self host your own signal, but it’s not federated, so you’d have nobody to talk to
So effectively its not FOSS.
It’s absolutely FOSS. It is not, however federated. But that is not a requirement to be free and open source software
Think of it like this, Linux is free and open source software, even if I don’t give you a shell on my computer.
You can use the code, however you want, in any project you want.
It isn’t, because their business practices violate the four FOSS essential freedoms:
- The freedom to run the program for any purpose
- The freedom to study and modify the program
- The freedom to redistribute copies of the original or modified program
- The freedom to distribute modified versions of the program
Specifically, freedom 4 is violated, because you are not permitted to distribute a modified version of the program that connects to the Signal servers (even if all your modified version does is to remove Google Play Services or something similar).
The license does not prevent number four from happening, they just ask people not to do it
The link is broken, but this is apparently an issue with Signal Desktop, not regular Signal. The proposed solution does not work on Windows: https://www.electronjs.org/docs/latest/api/safe-storage
[…] content is protected from other users on the same machine, but not from other apps running in the same userspace.
It’s unfortunately about the best you can do on Windows.
Thanks for the heads up on the broken link! I fixed it.
Restricting access to files within a user is why sandboxing is useful. It in theory limits the scope of a vulnerability in an app to only the files it can read (unless there is a sandbox escape). Android instead prevents apps from accessing other apps’ files by having each app run as a separate user.
One way to keep the encryption keys encrypted at rest is to require the login password (or another password) to open the app, and use it to encrypt the keys. That said, if an adversary can read Signal’s data, they can almost certainly just replace Signal with a password-stealing version.
by any process on the system
This IS bad. Btw they can ask the user to type the password rather than saving it in a plaintext. I can’t believe comments on this thread defend Signal…
But can you trust that a user will pick a difficult to break password? They likely will pick something simple to remember but that is not a good password.
The we are just back to essentially having a plaintext password because if the attacker has a good dictionary, it will be easy to crack.
I can agree, but I MYSELF will pick a strong PW. So they better just fucking encrypt the thing, fucking please for the love of god.
