this post was submitted on 12 Jul 2024
253 points (93.2% liked)
Technology
59589 readers
3394 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
I am not proposing anything actually, I am implying that this change won't modify the threat model in any substantial way. Your comment implied that it kind of did, requiring root access - which is a slightly different tm, not so much on single user machines..
So my point is that "The data is safe until your user password is safe" is a very tiny change compared to "your data is safe until your device is safe". There are tons of ways to get the password once you have local access, and what I strongly disagree with is that it requires more work or risk. A sudo fake prompt requires a 10-lines bash script since you control the shell configuration, for example. And you don't even need to phish, you can simply create a SUID shell and use "sudo chmod +s shell" to any local configuration or script where the user runs a sudo command, and you are root, or you dump the keyring or...etc. Likewise, 99.9% of the users don't run integrity monitoring tools, or monitor and restrict egress access, so these attacks simply won't be noticed.
So what I am saying is that an encrypted storage is better than a plaintext storage for the key, but if this requires substantial energies from the devs that could have been put on work that substantially improved the security posture, it is a net negative in terms of security (I don't know if it is the case), and that nobody after this change should feel secure about their signal data in case their device would be compromised.