this post was submitted on 06 Jul 2024
483 points (94.5% liked)
Privacy
31975 readers
648 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
Chat rooms
-
[Matrix/Element]Dead
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If someone can read my Signal keys on my desktop, they can also:
Signal should change this because it would add a little friction to a certain type of attack, but a messaging app designed for ease of use and mainstream acceptance cannot provide a lot of protection against an attacker who has already gained the ability to run arbitrary code on your user account.
Not necessarily.
https://en.m.wikipedia.org/wiki/Swiss_cheese_model
If you read anything, at least read this link to self correct.
This is a common area where non-security professionals out themselves as not actually being such: The broken/fallacy reasoning about security risk management. Generally the same "Dismissive security by way of ignorance" premises.
It's fundamentally the same as "safety" (Think OSHA and CSB) The same thought processes, the same risk models, the same risk factors....etc
And similarly the same negligence towards filling in holes in your "swiss cheese model".
....etc
The same logic you're using is the same logic that the industry has decades of evidence showing how wrong it is.
Decades of evidence indicating that you are wrong, you know infinitely less than you think you do, and you most definitely are not capable of exhaustively enumerating all influencing factors. No one is. It's beyond arrogant for anyone to think that they could ๐คฆ๐คฆ ๐คฆ
Thus, most risks are considered valid risks (this doesn't necessarily mean they are all mitigatable though). Each risk is a hole in your model. And each hole is in itself at a unique risk of lining up with other holes, and developing into an actual safety or security incident.
In this case
Thus this is just straight up negligence on their part.
There's not really much in the way of good excuses here. We're talking about a run of the mill problem that has baked in solutions in most major frameworks including the one signal uses.
https://www.electronjs.org/docs/latest/api/safe-storage
I was just nodding along, reading your post thinking, yup, agreed. Until I saw there was a PR to fix it that signal ignored, that seems odd and there must be some mitigating circumstances on why they haven't merged it.
Otherwise that's just inexcusable.
The PR had some issues regarding files that were pushed that shouldn't have been, adding refactors that should have been in separate PRs, etc...
Though the main reason is that Signal doesn't consider this issue a part of their threat model.
Those are outside Signal's scope and depend entirely on your OS and your (or your sysadmin's) security practices (eg. I'm almost sure in linux you need extra privileges for those things on top of just read access to the user's home directory).
The point is, why didn't the Signal devs code it the proper way and obtain the credentials every time (interactively from the user or automatically via the OS password manager) instead of just storing them in plain text?
They're arguing a red herring. They don't understand security risk modeling, argument about signals scope let's their broken premise dig deeper. It's fundamentally flawed.
It's a risk and should be mitigated using common tools already provided by every major operating system (ie. Keychain).
"Highways shouldn't have guard rails because if you hit one you've already gone off the road anyway."
You'd need write access to the user's home directory, but doing something with desktop notifications on modern Linux is as simple as
dbus-monitor "interface='org.freedesktop.Notifications'" | grep --line-buffered "member=Notify\|string" | [insert command here]Replacing the Signal app for that user also doesn't require elevated privileges unless the home directory is mounted
noexec.Feel free to submit a pull request. We could use your help.
I don't see the reasoning in your answer (I do see its passive-aggressiveness, but chose to ignore it).
I asked "why?"; does your reply mean "because lack of manpower", "because lack of skill" or something else entirely?
In case you are new to the FOSS world, that being "open source" doesn't mean that something cannot be criticized or that people without the skill (or time!) to submit PRs must shut the fu*k up.
It's in the draft phase from what I can see.
https://github.com/signalapp/Signal-Desktop/pull/6849
(for Android) https://molly.im/ restores the encryption to this file and adds other useful things