• Dem Bosain@midwest.social
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    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.

    • SeattleRain@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      What app stops a pre install keylogger. I’m all for hearing criticism of Signal but it’s always about things they can’t control.

    • Dessalines@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      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.

    • uis@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      But, but, “just use disk encryption”. Just…no…WTF?

      So not encrypting keys is bad, but actually encrypting them is bad too? Ok.

      Any on of your recipients could be using the desktop app and there’s no way to know unless they tell you.

      Another applefan? How it THIS supposed to be in scope of E2EE? Moreover, how having a way to know if recepient is using desktop app is not opposite of privacy?

      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.

      Indeed. This is why I use Matrix. Also, fuck showing phone numbers to everyone(I heard they did something about it) and registration with phone numbers.

      • Dem Bosain@midwest.social
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        Any “secure” so that relies on someone else for security is not secure.

        Fuck the scope of E2EE. Signal makes a lot of claims on their website that are laughable. The desktop app is their main weakness. Attachments are stored unencrypted, keys in plaintext. If they were serious about security, they would depricate the windows app and block it from their servers.

        WTF does Apple have to do with anything?

        • uis@lemm.ee
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          Any “secure” so that relies on someone else for security is not secure.

          Fuck the scope of E2EE.

          When someone has FSB/NSA agent behind them reading messages, no amount of encryption will help. Biggest cybersecurity vulnreability is located between monitor and chair. When you are texting someone else, that someone else’s chair-monitor space is also vulnreable.

          Signal makes a lot of claims on their website that are laughable.

          Well, maybe. I didn’t read their claims, nor I use signal.

          Attachments are stored unencrypted, keys in plaintext.

          Is OS-level encryption plaintext or not? If yes, then they are encrypted, provided user enables such feature in OS. If not - nothing if encrypted fundamentally.

          If they were serious about security, they would depricate the windows app and block it from their servers.

          WTF does Apple have to do with anything?

          You just used applefans’ argument. Yeah, I wonder what.

    • Zak@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      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.

      • gomp@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 months ago

        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?

        • Zak@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          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.

          • gomp@lemmy.ml
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            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.

        • douglasg14b@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

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

          • Liz@midwest.social
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 months ago

            “Highways shouldn’t have guard rails because if you hit one you’ve already gone off the road anyway.”

      • douglasg14b@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 months ago

        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@programming.dev
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 months ago

          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.

    • refalo@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      98% of desktop apps (at least on Windows and Linux) are already broken by design anyways. Any one app can spy on and keylog all other apps, all your home folder data, everything. And anyone can write a desktop app, so only using solutions that (currently) don’t have a desktop app version, seems silly to me.

  • Borna Punda@lemmy.zip
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    8 months ago

    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.

    • Zak@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      The alternative is safeStorage, which uses the operating system’s credential management facility if available. On Mac OS and sometimes Linux, this means another process running in the user’s account is prevented from accessing it. Windows doesn’t have a protection against that, but all three systems do protect the credentials if someone copies data offline.

      Signal should change this, but it isn’t a major security flaw. If an attacker can copy your home directory or run arbitrary code on your device, you’re already in big trouble.

    • x1gma@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      The third option is to use the native secret vault. MacOS has its Keychain, Windows has DPAPI, Linux has has non-standardized options available depending on your distro and setup.

      Full disk encryption does not help you against data exfil, it only helps if an attacker gains physical access to your drive without your decryption key (e.g. stolen device or attempt to access it without your presence).

      Even assuming that your device is compromised by an attacker, using safer storage mechanisms at least gives you time to react to the attack.

    • refalo@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      A better thing to be worried about IMO is that Signal contains proprietary code. Also to my knowledge nobody is publicly verifying the supposed “reproducible builds” if they even still exist.

  • thayer@lemmy.ca
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    8 months ago

    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.

    • Zak@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      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.

    • BearOfaTime@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      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.

    • ooterness@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      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.

      • thayer@lemmy.ca
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        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.

      • refalo@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        8 months ago

        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.

      • thayer@lemmy.ca
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        8 months ago

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

        • ruse8145@lemmy.sdf.org
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          8 months ago

          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

          • refalo@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            8 months ago

            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.

          • thayer@lemmy.ca
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            8 months ago

            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.

        • refalo@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          8 months ago

          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.

      • communism@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        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.

        • lemmyvore@feddit.nl
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 months ago

          If any part of the data gets corrupted you lose the whole thing. Recovery tools can’t work with partially corrupted encrypted data.

          • communism@lemmy.ml
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            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.

      • devfuuu@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        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.

          • devfuuu@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            If you suspend the laptop when moving locations instead of shutting down or hibernating to disk then disk encryption is useless.

            • thayer@lemmy.ca
              link
              fedilink
              English
              arrow-up
              0
              ·
              8 months ago

              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.

          • refalo@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            8 months ago

            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.

  • Majestic@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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.

      • Majestic@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        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.

      • southsamurai@sh.itjust.works
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        A different encrypted messaging service. Decent, but hasn’t taken off despite using email for accounts rather than phone bonkers numbers

        • Mubelotix@jlai.lu
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          All these apps are going to have to understand that they MUST be compatible between each other

          • southsamurai@sh.itjust.works
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            I mean, not really.

            Which standard are they going to be forced to use? What infrastructure? What encryption? Are they going to be forced to develop apps for every platform?

            The best you can hope to expect is apps using the same standard being compatible. Xmpp, matrix, whisper, whatever. Even matrix bridges don’t really fix compatibility across standards very well.

            It’s nice to think that anyone anywhere, could expect to install any app and communicate with anyone else and maintain encryption as well as full privacy. But as far as anyone I’ve ever seen talk about it that’s actually trained in the technology behind it all, it isn’t possible unless there’s a single, enforced standard in use.

            Does it suck to have to deal with multiple apps? Hell yes. But I also don’t like the idea of being forced to use whatever compromise protocol would make it realistic. I’d rather have a dozen apps with no single gatekeeper between them.

  • Prethoryn Overmind@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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.

  • Brayd@discuss.tchncs.de
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    Does anyone know how iMessage handles this on desktop (on Macs) as they (as far as I know) upgraded their encryption recently?

    • doodledup@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      How is a Desktop OS any different from a mobile one? This is where you need to be more specific.

      • thayer@lemmy.ca
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        8 months ago

        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.

  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    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

  • sntx@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I have three things to say:

    1. Everyone, please make sure you’ve set up sound disk encryption
    2. That’s not a suprise (for me at least)
    3. 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.
  • x1gma@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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.

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      If someone has access to your machine you are screwed anyway. You need to store the encryption key somewhere

      • x1gma@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        Yes, in your head, and in your second factor, if possible, keeping them always encrypted at rest, decrypting at the latest possible moment and not storing (decrypted) secrets in-memory for longer than absolutely necessary at use.

    • refalo@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      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.

      • uis@lemm.ee
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        AFAIK Android encrypts entire fs with one key. And ACL is not encryption.

      • Liz@midwest.social
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

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

        Emphasis mine.

        • ChapulinColorado@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          I think the point is the developers might have just migrated the code without adjustments since that is how it was implemented before. Similar to how PC game ports sometimes run like shit since they are a close 1-1 of the original which is not always the most optimized or ideal, but the quickest to output.

          • x1gma@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            Been a few days since using electron, but AFAIK electron can’t be used as a wrapper for android apps, or can it? Or is their android app a web app wrapped into a “native” android app too?

            Also, since this seems to be an issue since 2018, 6 years should be plenty to rewrite using a native secure storage…

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      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.

      • x1gma@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        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.

        • dave@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          Well yes, but also how would users react if they had to type in their passphrase every time they open the app? This is also exactly what we’re giving up everywhere else by clicking ‘remember this device’.

        • lemmyvore@feddit.nl
          link
          fedilink
          English
          arrow-up
          0
          ·
          8 months ago

          If someone gets access they can delete your keys, or set up something that can intercept your keys in other ways.

          The security of data at rest is just one piece of the puzzle. In many systems the access to the data is considered much more important than whether the data itself is encrypted in one particular scenario.

    • uis@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

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

      Ok. Enter password at every launch.

  • mtchristo@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    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?

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      Why is this a shock? Someone would need to have already compromised your device. Even if it was encrypted with a password they still could install a key logger

      • mtchristo@lemm.ee
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        It is easier to compromise a device than to try and compromise encrypted communications.

    • derpgon@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      Matrix. You can host any version you want, and when you have to update, just do a version diff between you current and latest versions and check yourself.