- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
You must log in or # to comment.
E2EE is not supposed to protect if device get compromised.
One could argue that Windows is compromised right out of the box.
Intrinsically/semantically no but the expectation is that the texts are encrypted at rest and the keys are password and/or tpm+biometric protected. That’s just how this works at this point. Also that’s the government standard for literally everything from handheld devices to satellites (yes, actually).
At this point one of the most likely threat vectors is someone just taking your shit. Things like border crossings, rubber stamped search warrants, cops raid your house because your roommate pissed them off, protests, needing to go home from work near a protest, on and on.
If your device is turned on and you are logged in, your data is no longer at rest.
Signal data will be encrypted if your disk is also encrypted.
If your device’s storage is not encrypted, and you don’t have any type of verified boot process, then thats on you, not Signal.
That’s not how this works.
If the stored data from signal is encrypted and the keys are not protected than that is the security risk that can be mitigated using common tools that every operating system provides.
You’re defending signal from a point of ignorance. This is a textbook risk just waiting for a series of latent failures to allow leaks or access to your “private” messages.
There are many ways attackers can dump files without actually having privileged access to write to or read from memory. However, that’s a moot point as neither you nor I are capable of enumerating all potential attack vectors and risks. So instead of waiting for a known failure to happen because you are personally “confident” in your level of technological omnipotence, we should instead not be so blatantly arrogant and fill the hole waiting to be used.
Also this is a common problem with framework provided solutions:
https://www.electronjs.org/docs/latest/api/safe-storage
This is such a common problem that it has been abstracted into apis for most major desktop frameworks. And every major operating system provides a key ring like service for this purpose.
Because this is a common hole in your security model.
Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.
Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.
Damn reading literacy has gone downhill these days.
Please reread my post.
But this should be an OS level protection that can be offered to Signal as an app, not the other way around.
- OSs provide keyring features already
- The framework signal uses (electron) has a built in API for this EXACT NEED
Cmon, you can do better than this, this is just embarrassing.
Why exactly am I re-reading your post? Im in complete agreement with you? Should I not be?
Signal data will be encrypted if your disk is also encrypted.
True.
and you don’t have any type of verified boot process
How motherboard refusing to boot from another drive would protect anything?
Its more about protecting your boot process from malware.
Well, yes. By refusing to boot. It can’t prevent booting if motherboard is replaced.
EDIT: s/do anything/prevent booting/
Thats correct. Thats one of the many perks.
EDIT: s/do anything/prevent booting/
TPM isn’t all that reliable. You will have people upgrading their pc, or windows update updating their bios, or any number of other reasons reset their tpm keys, and currently nothing will happen. In effect people would see Signal completely break and loose all their data, often seemingly for no reason.
Talking to windows or through it to the TPM also seems sketchy.
In the current state of Windows, the sensible choice is to leave hardware-based encryption to the OS in the form of disk encryption, unfortunate as it is. The great number of people who loose data or have to recover their backup disk encryption key from their Microsoft account tells how easily that system is disturbed (And that Microsoft has the decryption keys for your encrypted date).
Mfw end to end can be compromised at the end.
That said, they should fix this anyway
Indeed, End-to-End Encryption protects data between those ends, not ends themselves. If ends are compromised, no math will help you.
Plaintext should never be used in any application that deals with security, ever.
unless you’re reading ciphertext yourself, this doesn’t make sense
deleted by creator
Oh wow that’s quite a red flag ngl
How in the fuck are people actually defending signal for this, and with stupid arguments such as windows is compromised out of the box?
You. Don’t. Store. Secrets. In. Plaintext.
There is no circumstance where an app should store its secrets in plaintext, and there is no secret which should be stored in plaintext. Especially since this is not some random dudes random project, but a messenger claiming to be secure.
Edit: “If you got malware then this is a problem anyway and not only for signal” - no, because if secure means to store secrets are used, than they are encrypted or not easily accessible to the malware, and require way more resources to obtain. In this case, someone would only need to start a process on your machine. No further exploits, no malicious signatures, no privilege escalations.
“you need device access to exploit this” - There is no exploiting, just reading a file.
You. Don’t. Store. Secrets. In. Plaintext.
Ok. Enter password at every launch.
All your session cookies are stored in plaintext.
Chrome cookies are encrypted, for exactly the reasons stated. If malware gains access to your system and compromises it in a way that DPAPI calls can be replicated in the way Chrome does it, then your sessions will also be compromised. But this is way harder to do, and at least prevents trivial data exfiltration.
That applies to pretty much all desktop apps, your browser profile can be copied to get access to all your already logged in cookie sessions for example.
And there are ways to mitigate this attack (essentially the same as a AiTM or pass-the-cookie attacks, so look those up). Thus rendering your argument invalid.
Just because “something else might be insecure”, doesn’t in any way imply “everything else should also be insecure as well”.
Ah yes, another prime example that demonstrates that Lemmy is no different than Reddit. Everyone thinks they are a professional online.
Nothing sensitive should ever lack encryption especially in the hands of a third party company managing your data claiming you are safe and your privacy is protected.
No one is invincible and it’s okay to criticize the apps we hold to high regards. If your are pissed people are shitting on Signal you should be pissed Signal gave people a reason to shit on them.
deleted by creator
If your device gets compromised, it’s no longer the company’s problem.
lack encryption especially in the hands of a third party company managing your data
Are we still talking about local-only keys?
deleted by creator
The real problem is that the security model for apps on mobile is much better than that for apps on desktop. Desktop apps should all have private storage that no other non-root app can access. And while we’re at it, they should have to ask permission before activating the mic or camera.
macOS has nailed it*, even though it’s still not as good as iOS or Android, but leagues and bounds better than Windows and especially Linux.
ETC: *sandboxing/permission system
What’s wrong with the Flatpak permissions system on Linux?
It’s a joke. Apps have defined permissions already allowed on install and some of them have too many things set to allow like home or host access. Also, changing any permission requires restarting the app. It’s heading in the right direction, but it has a looooong way to go to catch up with macOS, let alone Android and iOS.
Bruh windows and linux have a secrets vault (cred manager and keyring respectively, iirc) for this exact purpose.
Even Discord uses it on both OSs no problem
There is just no excuse for not even salting or SOMETHING to keep the secrets out of plaintext. The reason you don’t store in plaintext is because it can lead to even incidental collection. Say you have some software, perhaps spyware, perhaps it’s made by a major corporation so doesn’t get called that and it crawls around and happens to upload a copy of a full or portion of the file containing this info, now it’s been uploaded and compromised potentially not even by a malicious actor successfully gaining access to a machine but by poor practices.
No it can’t stop a sophisticated malware specifically targeting Signal to steal credentials and gain access but it does mean casual malware that hasn’t taken the time out to write a module to do that is out of luck and increases the burden on attackers. No it won’t stop the NSA but it’s still something that it stops someone’s 17 year old niece who knows a little bit about computers but is no malware author from gaining access to your signal messages and account because she could watch a youtube video and follow along with simple tools.
The claims Signal is an op or the runner is under a national security letter order to compromise it look more and more plausible in light of weird bad basic practices like this and their general hostility. I’ll still use it and it’s far from the worst looking thing out there but there’s something unshakably weird about the lead dev, their behavior and practices that can’t be written off as being merely a bit quirky.
for not even salting
Wrong secret
I mean combined with any kind of function, even a trivial kind. A salt derived from some machine state data (a random install id generated on install, a hash of computer name, etc) plus a rot13 or something would still be better than leaving it plaintext.
Malware has access to it.
If fs is not encrypted, then malicious hardware(FSB agent’s laptop) also has access to it. If encrypted, then it we are back to statement many people told here about encrypting fs.
plus a rot13
That’s not salting.
I have three things to say:
- Everyone, please make sure you’ve set up sound disk encryption
- That’s not a suprise (for me at least)
- It’s not much different on mobile (db is unecrypted) - check out molly (signal fork) if you want to encrypt it. However encrypted db means no messages until you decrypt it.
This shows an incredibly cavalier approach to security on the part of the team working on signal.
This just in: threat actors compromising your devices is bad. More at 11.
Obviously the keys could be stored more securely, but if you’ve got malware on your machine that can exploit this you’ve already got bigger problems.
That’s not how this works.
This sort of “dismissive security through ignorance” is how we get so many damn security breaches these days.
I see this every day with software engineers, a group that you would think would be above the bar on security. Unfortunately a little bit of knowledge results in a mountain of confidence (see Dunning Kruger effect). They are just confident in bad choices instead.
“We don’t need to use encryption at rest because if the database is compromised we have bigger problems” really did a lot to protect the last few thousand companies from preventable data exfiltration that was in fact the largest problem they had.
Turns out that having read access to the underlying storage for the database doesn’t necessarily mean that the database and all of your internal systems are more compromised. It just means that the decision makers were making poor decisions based on a lack of risk modeling knowledge.
That said the real question I have for you here is:
Are you confident in your omniscience in that you can enumerate all risks and attack factors that can result in data being exfiltrated from a device?
If not, then why comment as if you are?
dawg what the shitfuck
You are telling me this has been going on for almost a decade now, and no one ever noticed ?
So we trust open source apps under the premise that if malicious code gets added to the code, at least one person will notice ? Here it shows that years pass before anyone notices and millions of people’s communications could have been compromised by the world’s most trusted messaging app.
I don’t know which app to trust after this, if any?
Signal has so many red flags that I’m beginning to wonder if it is a honeypot.
What other red flags do you have in mind?
Signal is actively hostile to alternative clients, or decoupling from Google.
Back when the Signal org used to be called Open Whisper Systems it received grants and auditing from the Open Technology Fund which, at the time, was still a part of Radio Free Asia.
https://web.archive.org/web/20150521181458/https://www.opentechfund.org/project/open-whisper-systems
