- cross-posted to:
- technology@lemmy.world
- foss@beehaw.org
- cross-posted to:
- technology@lemmy.world
- foss@beehaw.org
You must log in or register to comment.
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 does Windows do? Genuine question, I’ve not used it since the 7 days. Regarding Linux, that’s true for stuff installed through regular package managers and whatnot, but Flatpak is pushing a more sandboxed and permission oriented system, akin to Android.
You have granular control over universal windows apps (ie windows 8+ apps) and one global lock over all desktop apps (non uwp), and one global lock over everything. It’s pretty solid considering how little control Microsoft has and it’s wonderful fetish for compatibility.
Tldr basically same as Linux, except app distribution in Linux was bad enough for so long that more stuff is in the new restricted format while windows still has tons of things which will never go away and aren’t in the sandbox. I think not finding a way to sandbox all desktop apps was a mistake.
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.
They do sort of with Flatpak
Firejail and bwrap. Flatpaks. There are already ways to do this, but I only know of one distro that separates apps by default like Android does (separate user per app), which is the brand new “EasyOS”.
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.
Does anyone know how iMessage handles this on desktop (on Macs) as they (as far as I know) upgraded their encryption recently?
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.
To encrypt it you would need to store a encryption key
It’s plaintext all the way down.
The irony
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.
Alternative headline: Someone has a feature request for Signal which would be of interest to a few people with very specific security needs.
You mean the types of people who would use signal to communicate with others?
It’s not a bad feature to ensure that eg if there’s a malicious process running on your computer it can’t send all your signal data to whomever
Needing to enter a secure passphrase each time you want to use signal in exchange for one more fragile layer of defence for that one part of your data in a scenario that would normally mean you’ve already lost unless you’re running a super-secure compartmentalized operating system like qubes or something is probably not worth it for most people.
I already enter a passphrase every time I want to use Signal; I use the Molly client on my phone. It’s really not a big deal. I also enter a passphrase every time I launch my password manager, every time I launch my two-factor authentication app on my phone, and every time I open my email client. I think it’s fairly standard to protect sensitive data on your computer with encryption at rest and to decrypt it upon launching the application that handles the data.
It’s really not a big deal
For most casual users, it is a deal-breaker. And it’s hard to get everyday people to use your software with roadblocks like that.
every time I open my email client.
You must not get email very often, this is absolutely a non-starter for me.
For most casual users, it is a deal-breaker. And it’s hard to get everyday people to use your software with roadblocks like that.
That’s fair enough, but the way the mobile app works is that you can opt in to having encryption at rest with a passphrase, so if you want to leave your signal database unencrypted you can.
You must not get email very often, this is absolutely a non-starter for me.
Once you open it you can leave it open if you need notifications. Sometimes I leave it open, sometimes I just want to check my emails and then close it. Idk, I really think typing in a password for authentication/decryption regularly is such a non-issue, like for instance do you not regularly type in a password when you run a command with sudo? Again, if it’s opt-in I also don’t see the issue, except for the issue of allowing people to not encrypt their Signal data thus potentially compromising the people they’re messaging, but obviously that issue is currently universal for Signal desktop.
Huh. I would’ve thought most desktop users just leave it running all day long like I do. Obviously there is the disk encryption passphrase at boot, adding another one for signal would in my case be redundant.
But the point is not only how easy it is to enter a passphrase, but also how much security that actually gains you. I don’t think it does much on the typical desktop, be it windows or linux, where there are so many ways to escalate or persist privilege for anyone that has user-level access.
Obviously there is the disk encryption passphrase at boot, adding another one for signal would in my case be redundant.
I also have full disk encryption, but I still have some databases on my disk encrypted because I decrypt my disk when I boot my computer. But yeah if you have Signal open (& its db decrypted) all the time it would probably be minimal. I don’t have Signal open all the time though, only when I want to check messages or am actively using it
I don’t think it does much on the typical desktop, be it windows or linux, where there are so many ways to escalate or persist privilege for anyone that has user-level access.
The point would be encryption, even the root user wouldn’t be able to read encrypted data if they don’t have the passphrase
If you have root, intercepting all the user’s keystrokes is trivial.
I would’ve thought most desktop users just leave it running all day long like I do.
They do. OP is not a normal user.
This has nothing to do with the mobile app, which also has password/biometric unlocking, it’s about the desktop electron app.
I know. I never said it was about the mobile app?
You did but it says “desktop” right in the page title.
I’m now genuinely not sure what you’re saying. I did what? I said it was about the mobile app? I didn’t say it was about the mobile app?
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
Thanks ChatGPT.
Oh wow that’s quite a red flag ngl
If your system is compromised to such an extend, it really doesn’t make much difference how the keys are stored at rest.
But my system is not compromised?
Did you read the article?
How do you know?
Because I check my system and I don’t even use Signal?
“checking” does not prevent anything bad from happening. and if that file were read by a malicious actor, it would likely be immediate and you’d never even notice.
Did you see that I said “I don’t use Signal”?
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 it takes is an App that you”trust” to break that trust
I get what you’re trying to say, but that’s something I’d classify as “compromised” as well.
For sure, just suggesting that “compromised” doesn’t necessarily mean you got hacked by someone because they tricked you into giving a password, or they scraped it from another website, or you installed something sketchy. It could be as simple as Microsoft scans all your files with AI, or Meta snoops other social media (which it has been caught doing).
So you’re saying that the os itself is compromised? Gee, good luck protecting your processes from the fucking os, no matter how you do it.
Why? They would need access to the device
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”.
It is the same concept. Once your machine is pwded you are screwed
That’s all hinges on the assumption that your computer is pwned. Which is wrong
You don’t necessarily have to have privileged access to read files or exfiltrated information.
That point doesn’t matter anyways though because you’re completely ignoring the risk here. Please Google “Swiss cheese model”. Your comment is a classic example of non-security thinking… It’s the same comment made 100x in this thread with different words
Unless you can list out all possible risks and exploits which may affect this issue, then you are not capable of making judgement calls on the risk itself.
You act as though you somehow have more knowledge than everyone else. They problem is that you don’t understand encryption and permissions. You can’t just magically make something unreadable by programs with the same permission level. If you encrypt it there will need to be a key to decrypt it. That can could conceivably be encrypted with a password but that would require someone to enter a password. If they don’t enter a password they key will be stored plain text so anyone could easily decrypt your messages. Programs running as a user have the same permissions as that user. Does that make sense? You can’t just make something selectively unreadable with the current security model. I guess you could try to implement some sort or privileged daemon but that would open up more issues than it solved.
I would have a problem if Signal claimed that the desktop messages were encrypted at rest. However, they don’t make any such claim. If you are concerned about security I would recommend running everything in virtual machines and flatpaks. This way the chances of something misbehaving in a way that causes harm is minimized.
I’m not claiming some grand level of knowledge here. I also cannot enumerate all risks. The difference is that I know that I don’t know, and the danger that poses towards cognitive biases when it comes to false confidence, and a lack of effective risk management. I’m a professional an adjacent field, mid way into pivoting into cybersecurity, I used to think the same way, that’s why I’m so passionate here. It’s painful to see arguments and thought processes counter to the fundamentals of security & safety that I’ve been learning the past few years. So, yeah, I’m gonna call it out and try and inform.
All that crap said:
And you are right, the problem gets moved. However, that’s the point, that’s how standardization works, and how it’s supposed to work. It’s a force multiplier, it smooths out the implementation. Moving the problem to the OS level means that EVERYONE benefits from advanced in Windows/Macos/Linux. Automatically.
It’s not signal’s responsibility, it shouldn’t be unless that’s a problem they specifically aim to solve. They have the tools available to them already, electron has a standardized API for this,
secureStorage. Which handles the OS interop for them.I’m not arguing that signal needs to roll their own here. The expectation is that they, at least, utilize the OS provided features made available to their software.
IIRC this is how those Elon musk crypto livestream hacks worked on YouTube back in the day, I think the bad actors got a hold of cached session tokens and gave themselves access to whatever account they were targeting. Linus Tech Tips had a good bit in a WAN show episode
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.
Are you confident in your omnipotence 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?
While it would certainly be nice to see this addressed, I don’t recall Signal ever claiming their desktop app provided encryption at rest. I would also think that anyone worried about that level of privacy would be using disappearing messages and/or regularly wiping their history.
That said, this is just one of the many reasons why whole disk encryption should be the default for all mainstream operating systems today, and why per-app permissions and storage are increasingly important too.
Does encrypting your disks change something for the end user in day to day usage? I’m honest, I’ve never used encrypted disks in my life.
It’s transparent for end user basically, but protects the laptop at least when outside and if someone steals the computer. As long as it was properly shutdown.
Define properly shut down. Do your thieves usually ask first?
If you suspend the laptop when moving locations instead of shutting down or hibernating to disk then disk encryption is useless.
Most operating systems will require your desktop password upon resume, and most thieves are low-functioning drug users who are not about to go Hacker Man on your laptop. They will most likely just wipe the system and install something else; if they can even figure that out.
I think they’re just referring to an outdated concept of OSes with non-journaling filesystems that can cause data corruption if the disk is shut off abruptly, which in theory could corrupt the entire disk at once if it was encrypted at a device level. But FDE was never used in the time of such filesystems anyways.
Whole disk encryption wouldn’t change your daily usage, no. It just means that when you boot your PC you have to enter your passphrase. And if your device becomes unbootable for whatever reason, and you want to access your drive, you’ll just have to decrypt it first to be able to read it/write to it, e.g. if you want to rescue files from a bricked computer. But there’s no reason not to encrypt your drive. I can’t think of any downsides.
If any part of the data gets corrupted you lose the whole thing. Recovery tools can’t work with partially corrupted encrypted data.
I don’t think that’s a big deal with Signal data. You can log back into your account, you’d just lose your messages. idk how most people use Signal but I have disappearing messages on for everything anyway, and if a message is that important to you then back it up.
No, the average user will never know the difference. I couldn’t tell you exactly what the current performance impact is for hardware encryption, but it’s likely around 1-4% depending on the platform (I use LUKS under Linux).
For gamers, it’s likely a 1-5 FPS loss, depending on your hardware, which is negligible in my experience. I play mostly first and third person shooter-style games at 1440p/120hz, targeting 60-90 FPS, and there’s no noticeable impact (Ryzen 5600 / RX 6800XT).
If it has to go to disk for immediate loading of assets while playing a video game you’re losing more than 1-5 fps
Yeah, I’m sure there are a lot of variables there. I can only say that in my experience, I noticed zero impact to gaming performance when I started encrypting everything about 10 years ago. No stuttering or noticeable frame loss. It was a seamless experience and brings real peace of mind knowing that our financial info, photos, and other sensitive files are safely locked away.
Maybe, but not every frame while you’re playing. No game is loading gigs of data every frame. That would be the only way most encryption algorithms would slow you down.
You’re more likely going to get stuttering or asset streaming issues which are going to have more impact than losing a few fps.
For gamers, it’s likely a 1-5 FPS loss
I highly doubt it… would love to see some hard data on that. Most algorithms used for disk encryption these days are already faster than RAM, and most games are not reading gigabytes/sec from the disk every frame during gameplay for this to ever matter.
It depends on how you set it up. I think the default in some cases (like Windows Bitlocker) is to store the key in TPM, so everything becomes transparent to the user at that point, although many disagree with this method for privacy/security reasons.
The other method is to provide a password or keyfile during bootup, which does change something for the end user somewhat.
I don’t recall Signal ever claiming their desktop app provided encryption at rest.
I’m not sure if they’ve claimed that, but it does that using SQLCipher.
Full disk encryption doesn’t help with this threat model at all. A rogue program running on the same machine can still access all the files.
It does help greatly in general though, because all of your data will be encrypted when the device is at rest. Theft and B&Es will no longer present a risk to your privacy.
Per-app permissions address this specific threat model directly. Containerized apps, such as those provided by Flatpak can ensure that apps remain sandboxed and unable to access data without explicit authorization.
Exactly.
I’ll admit to being lazy and not enabling encryption on my Windows laptops. But if I deployed something for someone, it would be encrypted.
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.
I presume keys are already sort of encrypted?
Nope. Your presumption is wrong.
👍
especially in the hands of a third party company managing your data claiming you are safe and your privacy is protected.
Yeah, especially in this specific situation that isn’t relevant to this situation.
If your device gets compromised, it’s no longer the company’s problem.
Where are you going to store the encryption key? At the end of the day the local machine is effectively pwded anyway
They could just add a password
Whatever its stores and however it stores it doesn’t matter to me: I moved its storage space to my ~/.Private encrypted directory. Same thing for my browser: I don’t use a master password or rely on its encryption because I set it up so it too saves my profile in the ~/.Private directory.
See here for more information. You can essentially secure any data saved by any app with eCryptfs - at least when you’re logged out.
Linux-only of course. In Windows… well, Windows.
Or ext4 encrytion. Which is overpowered. You can have different keys for different files and directories.
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
Sure, I was aware. You have the same problem with ssh keys, gpg keys and many other things
However, you can save encrypted ssh, gpg keys and save that encryption key in the OS keyring.
Is it possible to seamlessly integrate, so when something requests those keys you’ll get a prompt?
With SSH at least you can password protect the key itself so that you always get a prompt.
Nice, didn’t know, I’ll look into it
Yes, but you STILL need to enter password on every reboot.
Can we please all just acknowledge that desktop operating systems absolutely suck (in regards to security)?
How is a Desktop OS any different from a mobile one? This is where you need to be more specific.
There are too many differences for me to list here, but unlike mobile operating systems, Windows and most Linux desktops do not provide sandboxed environments for userspace apps by default. Apps generally have free reign over the whole system; reading/writing data from/to other apps without restriction or notification. There are virtually no safeguards against malicious actors.
Mobile operating systems significantly restrict system-level storage space, making key areas read-only to prevent data access or manipulation. They also protect app storage, so one app can’t arbitrarily access or modify data stored for a different app.
Mobile operating systems also follow an image-based update model, wherein updates are atomic. System software updates are generally applied successfully all at once or not at all, helping to ensure your phone is never left in a partial or unusable state after a system update.
For desktop users, macOS, and atomic Linux distros combined with Flatpak are the closest comparisons.
