1. 85
  1.  

  2. 24

    There is no. winning. against a persistent unsandboxed local attacker. This comes up regularly disguised in different ways, like as reports that setting environment variables can compromise TLS, etc.

    If someone has full long-lasting control of the browser (like someone that can use a remote desktop thing to install an off-the-shelf rootkit) nothing will save you. Not 2FA, as they will just wait for you to use it or phish it from a real Google page; not a sync passphrase, as the browser needs it in memory to use the passwords and the attacker can just take it from there; not 1Password, as even if the vault is locked and their memory scrubbing implementation is perfect (which is unlikely), the attacker can just wait for you to type the password.

    This is not security nihilism (nothing is perfectly secure, etc.), this is just threat modeling. It’s important not to spend complexity and user tolerance on unwinnable battles.

    You could say “but this attacker looks incompetent so maybe it would have stopped them”, but they had access to the victim’s email, presumably they would just have reset any passwords they couldn’t find.

    Refreshing sessions still makes sense against opportunistic unsophisticated local attackers, like a domestic partner just sitting at the laptop that was left unlocked, but even then if they use that privilege to install malware it’s game over. (This is way less true on mobile platforms, because other apps can’t take control of the browser or mail app, and something we really should be doing better on at the platform level, but not a winnable battle on desktop at the web service level for now. Also remember this before criticizing an OS for tightening isolation.)

    (Disclaimer: I work at Google but have no particular insight into the account security team’s thinking and decisions.)

    1. 2

      This is way less true on mobile platforms, because other apps can’t take control of the browser or mail app

      Agreed. However this doesn’t mitigate the risk completely, for instance an accessibility service on Android can do a lot.

      Adding a TLS CA to the system or enabling a nasty VPN service displays something, but I’d guess most users will just ignore it.

    2. 10

      I’ll be damned. I had some passwords from 2008 there and I had completely forgot about it. Nice writeup and a good reminder that it’s very easy to leave breadcrumbs everywhere.

      P.S.: it’s extremely inconvenient to delete passwords on the GPM as there is no “delete all” option.

      1. 7

        You know what, IMO the spookiest thing about this story is NoMachine. I’ve never heard of it before, this is the first reference I’ve seen towards it. The website is a lot of marketing fluff, but nothing about exactly how they went about securing it. So the first reference I’ve ever heard of it is a story about how somebody managed to bypass it’s security somehow to get remote access to a machine that had important credentials on it. This suggests I should stay far, far away from it, at least until I see a deep dive into how this was possible and how the company responsible for it is working to ensure that it can never happen again.

        I can’t say I’ve ever heard of anybody breaking into a server with access secured through SSH configured with best practices.

        I mean you can bash Google a bit for this I guess, but with how huge their systems and attack surface is, it’s hard to believe they could ever secure things enough that letting somebody unauthorized get your account credentials won’t result in very bad things happening. Maybe we should try and stop it before that happens.

        1. 1

          NX is typically secured with…SSH. The same best practices should apply.

        2. 11

          A nice personal story that covers a lot of issues with how we use and manage credentials. Authentication is a hard problem.

          1. 4

            Authentication is a moderately difficult problem but with some good existing solutions. Revocation; however, is an incredibly hard problem. The only solutions that work well involve going via an intermediary.

            With WebAuthn, I can have keys stored in a TPM or other security element processor and protected by biometrics. My OS never sees them, the coprocessor signs a nonce from the server and so even a full compromise can only log in live, it can’t exfiltrate my credentials. Unfortunately, the biometrics are not completely unhackable, so if I sell or lose a machine, I need to remove that as an authorised key on every service. For things that I sign into with GitHub, I can just invalidate the key with GitHub, but now GitHub is a mediator for these things and can see all of the things that I log into. I don’t mind this since I only use GitHub sign in for things that are related to open source projects and that GitHub could track anyway, but it’s not a general solution.

          2. 6

            Yikes, I had some passwords saved in passwords.google.com, and I didn’t even know this service existed! Some Google product must have had a conveniently placed “OK whatever” button somewhere.

            It’s quite scary that Google allows exporting all of them without re-checking 2FA. A compromised session is a disaster, but that’s an express lane for total pwnage.

            1. 3

              I’m surprised safari autofilled, and also surprised that they were able to extract the password from the page.

              For the first part all modern Macs gate autofill on touchid, I guess in the absence of touchid it just autofills?

              For the latter safari has a lot of guards against software control of the UI (because that is such a powerful tool in the event of compromise).

              But then as FiloSottile says, if you’ve got an unsandboxed app with an open port then that’s a super powerful tool for an attacker.

              Seriously network connected software, especially that which supports incoming connection should always be sandboxed, it can be a bit annoying at times, but it certainly isn’t hard. :-/

                1. 8

                  That wouldn’t help; the issue from the article is a glut of password managers, not a shortage of them.