Lately I’ve been increasingly worried about corrupted payloads of even open source password managers. Password managers are among the world’s biggest honeypots. Maybe you trust the coders of the password manager. Maybe it’s Open Source. But do you trust all of its upstream dependencies? And all their CI build processes? And each of their developers’ security?

That’s part of why I won’t use an Electron-based password manager like BitWarden: there’s no Electron app with a minimal dependency graph. Even Electron itself could easily fall victim if someone important in the development pipeline is compromised… And besides, Electron sucks anyway.

So, one way I can mitigate against the possibility of a malicious payload being delivered on password manager update is to not put all my eggs in one basket. For example, where I can, I authenticate with a Yubikey (if only by TOTP on Yubico Authenticator). Then my password isn’t enough. But where do I store the recovery codes? Ugh: in the password manager.

I’ve been thinking on this for a while, and I haven’t really found a perfect solution that provides me a way to store secrets without also being too reliant on one party’s software. If I rely heavily on the password manager, that puts too much trust in it. If I rely more on a hardware token, that’s too risky in case of loss of theft.

What’s a security-aware nerd to do?

  • theonlykl@partizle.com
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    What’s funny working in the cybersecurity space is we’ve actually adopted Bitwarden I’m out org. Now, with that said to your point not all our eggs are in one basket.

    Most of our auth (if not all) relies on another mechanism for authentication. Typically some other 2FA mechanism that isn’t stored in our org Bitwarden vault. We enforce that separation with the assumption that if our vault is compromised the core aspects of the business easily accessible isn’t necessary breached.

    The break glass accounts / etc that are not protected by 2FA are 99% of the time locked down to only be able to use that use from very specific subnets and or source systems. The ones that are accessible outside (say a AWS account) is always locked down with a hardware key. This isn’t fool proof either as technically in a very targeted attack you could focus on the admin/IT user and work your way through their system. To your point…it’s Electron based, but we also found not offering it and making it easy for the typical user often led to even worse practices being adhered to.

    We’ve embraced Bitwarden at this point pretty heavily, but at some point we will be rolling our own instance and migrating that way. This will allow a bit more separation and control for more of our break glass based accounts.

    • bouncing@partizle.comOPM
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      I think for a business, there’s usually someone somewhere with the keys to the kingdom and that can be appealed. If you lose your secrets, they can be reissured.

      For individuals it can be more complex. For instance, you mentioned you don’t keep all your eggs in one basket. A yubikey is a great second factor for that, but then what if it gets lost? Well, you keep your recovery codes, right? Are they stored somewhere safe from fire? Are they, for instance, in a password manager?

      In simpler terms, suppose your house burns down and your devices in it. Suppose you used end-to-end encryption for your iCloud files. Could you get all that data back? And if so, how? It’s a useful thought experiment.

      • theonlykl@partizle.com
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 year ago

        Current have two Yubikeys for personal use. One is a backup and remains in a fireproof safe, while the other is on my most / all of the time via my keyring. Agree the individual side is a bit more complex.

        For me I took the approach of not relying that much on cloud services and rolling a lot of it myself. My data then gets backed up to a backup repository via borgbase in the EU. Usually try to follow the 3,2,1 rule for backups. Three copies of your data on two different medias with one copy offsite (ok the two different medias thing i cheat a bit and have a couple extra disks).

        The enterprise side we’ve talked about implementing Yubikeys in the org, but havent gotten all the buy in on that yet.

            • bouncing@partizle.comOPM
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              That’s the weak spot. It seems unlikely, but if there were a natural disaster or house fire, you’d lose access to your vault and your data.

              In my case, that would be irreplaceable family photos, which is why I’m thinking about this more. I have an off-site backup for my data, but I’d need to be able to decrypt it.