But… That’s how encryption keys are stored.
Signal under fire for storing encryption keys in plaintext
Submitted 4 months ago by neme@lemm.ee to privacyguides@lemmy.one
https://stackdiary.com/signal-under-fire-for-storing-encryption-keys-in-plaintext/
Comments
pearsaltchocolatebar@discuss.online 4 months ago
Evotech@lemmy.world 4 months ago
No your don’t understand, you’re supposed to encrypt the keys.
Then you encrypt that key
And then that key
Until it’s all encrypted /s
boredsquirrel@slrpnk.net 4 months ago
opportunistic TPM integration would be nice.
I.e. use the security chip of the device, if one is found. Otherwise use password.
mashbooq@lemmy.world 4 months ago
This same “discovery” gets reported on once or twice a year; it’s starting to feel like a FUD campaign rather than actual research
potatopotato@sh.itjust.works 4 months ago
Yeah but it really shouldn’t be that way. Just add a pin or something, it’s way too easy for people to just grab devices or install malware to leak keys
eco_game@discuss.tchncs.de 4 months ago
I just read the full article, and I’m not even that concerned about storing the key in plaintext. I find the possibility of copying the files, and then being able to run the same session simultaneously a lot scarier.
kakito69@sh.itjust.works 4 months ago
Not storing it in plaintext would require setting up some kind of password, right?
boredsquirrel@slrpnk.net 4 months ago
Some way to encrypt the decryption key.
This could also mean TPM + Pin. Or using a Nitrokey, externally, which stores the password to decrypt the decryption key.
Blizzard@lemmy.zip 4 months ago
Should the encryption keys be… encrypted?
henfredemars@infosec.pub 4 months ago
With what? Where would you store the encryption key for the encryption key on a desktop system where it would not be accessible to an attacker?
Perhaps there could be a pin or password that must be entered every time to decrypt it into memory.
eco_game@discuss.tchncs.de 4 months ago
As the article states, currently all processes are able to read the file which contains the key. Instead, you could store the key in the macOS Keychain (and Linux/Windows equivalents), which AFAIK is a list of all sorts of sensitive data (think WiFi passwords etc.), encrypted with your user password. I believe the Keychain also only let’s certain processes see certain entries, so the Signal Desktop App could see only its own encryption key, whereas for example iMessage would only see the iMessage encryption key.
boredsquirrel@slrpnk.net 4 months ago
Something you know, something you have, something you are.
3FA:
- Pin
- Security Key/TPM/Secure element
- fingerprint / iris scan
You could also start with just one of these
RagingHungryPanda@lemm.ee 4 months ago
Yo dawg
joeldebruijn@lemmy.ml 4 months ago
While true I don’t get why this is long known and also news at the same time.
For Signal Backup tools for example this isn’t a bug but a feature and the only way to make long term archival of chats possible.
boredsquirrel@slrpnk.net 4 months ago
You could archive chats encrypted too.
joeldebruijn@lemmy.ml 4 months ago
Yep, decrypt … export elsewhere to csv txt json … encrypt
JoeyJoeJoeJr@lemmy.ml 4 months ago
If your computer is compromised to the point someone can read the key, read words 2-5 again.
This is FUD. Even if Signal encrypted the local data, at the point someone can run a process on your system, there’s nothing to stop the attacker from adding a modified version of the Signal app, updating your path, shortcuts, etc to point to the malicious version, and waiting for you to supply the pin/password. They can siphon the data off then.
Anyone with actual need for concern should probably only be using their phone anyway, because it cuts your attack surface by half (more than half if you have multiple computers), and you can expect to be in possession/control of your phone at all times, vs a computer that is often left unattended.
Reddfugee42@lemmy.world 4 months ago
“if you’ve lost physical security, you’ve lost all security.”
otter@lemmy.ca 4 months ago
I’ve heard criticism of the desktop app before as well, maybe they’ll finally rework it?
jicevif@futurology.today 4 months ago
Always knew this project was a honeypot because of their insistence on needing a phone number. Welp. Let’s see how they damage control yet again.
actionjbone@sh.itjust.works 4 months ago
It originally needed a phone number because it was originally a phone texting app.
best_username_ever@sh.itjust.works 4 months ago
You have the source. Read it if you want.
DieserTypMatthias@lemmy.ml 4 months ago
Who is behind Stackdiary, btw?
breadsmasher@lemmy.world 4 months ago
Kinda should have been in the headline
Tramort@programming.dev 4 months ago
It is a super important detail, but it’s still unforgivable for an app that expects privacy to be part of its brand identity.
breadsmasher@lemmy.world 4 months ago
yeah absolutely agreed
brakebreaker101@lemmy.world 4 months ago
This is a big difference between privacy and security.