Carbophile ,
@Carbophile@lemmy.zip avatar

The backlash is extremely idiotic. The only two options are to store it in plaintext or to have the user enter the decryption key every time they open it. They opted for the more user-friendly option, and that is perfectly okay.

If you are worried about an outsider extracting it from your computer, then just use full disk encryption. If you are worried about malware, they can just keylog you when you enter the decryption key anyways.

Majestic ,

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.

possiblylinux127 ,
@possiblylinux127@lemmy.zip avatar

To encrypt it you would need to store a encryption key

rmuk ,

It's plaintext all the way down.

Prethoryn ,
@Prethoryn@lemmy.world avatar

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.

x1gma ,

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.

refalo ,

How in the fuck are people actually defending signal for this

Probably because Android (at least) already uses file-based encryption, and the files stored by apps are not readable by other apps anyways.

And if people had to type in a password every time they started the app, they just wouldn't use it.

Liz ,

Popular encrypted messaging app Signal is facing criticism over a security issue in its desktop application.

Emphasis mine.

lemmyvore ,

You. Don't. Store. Secrets. In. Plaintext.

SSH stores the secret keys in plaintext too. In a home dir accessible only by the owning user.

I won't speak about Windows but on Linux and other Unix systems the presumption is that if your home dir is compromised you're fucked anyway. Effort should be spent on actually protecting access to the home personal files not on security theater.

floquant ,

Not true, SSH keys need their passphrase to be used. If you don't set one, that's on you.

Mubelotix ,
@Mubelotix@jlai.lu avatar

Come on, 95% of users don't set passwords on their ssh keys

idunnololz ,
@idunnololz@lemmy.world avatar

Where are these stays from lmao.

x1gma ,

Kinda expected the SSH key argument. The difference is the average user group.

The average dude with a SSH key that's used for more than their RPi knows a bit about security, encryption and opsec. They would have a passphrase and/or hardening mechanisms for their system and network in place. They know their risks and potential attack vectors.

The average dude who downloads a desktop app for a messenger that advertises to be secure and E2EE encrypted probably won't assume that any process might just wire tap their whole "encrypted" communications.

Let's not forget that the threat model has changed by a lot in the last years, and a lot of effort went into providing additional security measures and best practices. Using a secure credential store, additional encryption and not storing plaintext secrets are a few simple ones of those. And sure, on Linux the SSH key is still a plaintext file. But it's a deliberate decision of you to keep it as plaintext. You can at least encrypt with a passphrase. You can use the actual working file permission model of Linux and SSH will refuse to use your key with loose permissions. You would do the same on Windows and Mac and use a credential store and an agent to securely store and use your keys.

Just because your SSH key is a plaintext file and the presumption of a secure home dir, you still wouldn't do a ~/passwords.txt.

DemBoSain ,
@DemBoSain@midwest.social avatar

Why is Signal almost universally defended whenever another security flaw is discovered? They're not secure, they don't address security issues, and their business model is unsustainable in the long term.

But, but, if you have malware "you have bigger problems". But, but, an attacker would have to have "physical access" to exploit this. Wow, such bullshit. Do some of you people really understand what you're posting?

But, but, "windows is compromised right out of the box". Yes...and?

But, but, "Signal doesn't claim to be secure". Fuck off, yes they do.

But, but, "just use disk encryption". Just...no...WTF?

Anybody using Signal for secure messaging is misguided. Any on of your recipients could be using the desktop app and there's no way to know unless they tell you. On top of that, all messages filter through Signal's servers, adding a single-point-of-failure to everything. Take away the servers, no more Signal.

GlenRambo ,

Whats the next best alternative?

Isoprenoid ,

Meeting in person.

Zak ,
@Zak@lemmy.world avatar

If someone can read my Signal keys on my desktop, they can also:

  • Replace my Signal app with a maliciously modified version
  • Install a program that sends the contents of my desktop notifications (likely including Signal messages) somewhere
  • Install a keylogger
  • Run a program that captures screenshots when certain conditions are met
  • [a long list of other malware things]

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.

douglasg14b ,
@douglasg14b@lemmy.world avatar

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".

"Oh that can't happen because that would mean x,y,z would have to happen and those are even worse"

"Oh that's not possible because A happening means C would have to happen first, so we don't need to consider this is a risk"

....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

  • signal was alerted to this over 6 years ago
  • the framework they use for the desktop app already has built-in features for this problem.
    • this is a common problem with common solutions that are industry-wide.
  • someone has already made a pull request to enable the electron safe storage API. And signal has ignored it.

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

fuzzzerd ,

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.

ChairmanMeow ,
@ChairmanMeow@programming.dev avatar

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.

lemmyvore ,

Now replace "signal" in your comment with "ssh" and think it over.

todd_bonzalez ,

Anybody using Signal for secure messaging is misguided. Any one of your recipients could be using the desktop app and there's no way to know unless they tell you.

That's why I only communicate face-to-face inside of a soundproofed faraday cage.

If the app manages the keys, then you can't trust the app.

If the recipient manages their own keys, then you can't trust the recipient.

Encryption is fundamentally insecure. Once I encrypt something, nobody should be able to decrypt it ever again.

dessalines ,
@dessalines@lemmy.ml avatar

Basically for the same reason people often defend apple: the user interface is shiny, and they claim to be privacy oriented.

Signal is a centralized US hosted service, that alone should be enough to disqualify it, outside of our many other criticisms.

yogthos ,
@yogthos@lemmy.ml avatar

This shows an incredibly cavalier approach to security on the part of the team working on signal.

ruse8145 ,

Moxie would be spinning in his grave if he weren't still working there...

dessalines ,
@dessalines@lemmy.ml avatar

Moxie tried to put a crypto-coin into signal. He is not to be trusted in the slightest.

catalog3115 ,

E2EE is not supposed to protect if device get compromised.

NegativeLookBehind ,
@NegativeLookBehind@lemmy.world avatar

One could argue that Windows is compromised right out of the box.

refalo ,

Source:

Zpiritual ,

Microsoft are integrating adware and spyware straight into the os.

ForgottenFlux OP ,

Summary:

  • Signal's desktop app stores encryption keys for chat history in plaintext, making them accessible to any process on the system
  • Researchers were able to clone a user's entire Signal session by copying the local storage directory, allowing them to access the chat history on a separate device
  • This issue was previously highlighted in 2018, but Signal has not addressed it, stating that at-rest encryption is not something the desktop app currently provides
  • Some argue this is not a major issue for the "average user", as other apps also have similar security shortcomings, and users concerned about security should take more extreme measures
  • However, others believe this is a significant security flaw that undermines Signal's core promise of end-to-end encryption
  • A pull request was made in April 2023 to implement Electron's safeStorage API to address this problem, but there has been no follow-up from Signal
GolfNovemberUniform ,
@GolfNovemberUniform@lemmy.ml avatar

Oh wow that's quite a red flag ngl

poVoq ,
@poVoq@slrpnk.net avatar

If your system is compromised to such an extend, it really doesn't make much difference how the keys are stored at rest.

GolfNovemberUniform ,
@GolfNovemberUniform@lemmy.ml avatar

But my system is not compromised?

poVoq ,
@poVoq@slrpnk.net avatar

Did you read the article?

phoneymouse ,

If the keys are accessible to any process, your system doesn’t need to be compromised. All it takes is an App that you”trust” to break that trust and snatch everything up. Meta has already been caught fucking around with other social media apps on device. They even intercepted Snapchat traffic on some users devices in order to collect that data. It could be as simple as you installed WhatsApp and they went and pillaged your Signal files.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • privacy@lemmy.ml
  • test
  • worldmews
  • mews
  • All magazines