1. 13
  1.  

  2. 11

    The password manager I use (pass) has a really simple and widely supported ‘backup’ mechanism built in (git).

    1. 7

      One downside of pass that I don’t see being talked about much is that the key names are not encrypted. This leaks a bit of metadata. Other than that’s it’s pretty much perfect for me.

      https://github.com/gopasspw/gopass is also quite good, uses the same storage as pass and adds a few interesting features like git auto-syncing and browser integration.

      1. 5

        For the issue of having your names unencrypted, I came with the following idea for safe, which could also work with pass or similar secret keepers:

        When syncing your secrets online, you can obfuscate the whole directory renaming all your entries after their sha256’d names, and store the conversion in a new secret, say “hashmap”. Your directory structure is then totally unreadable, unless you have the key to read the secrets themselves.
        I like this approach, because your safe protects itself. Here is my implementation (again, using safe as a backend):

        #!/bin/sh
        ORIG=$HOME/.secrets
        HASH=$HOME/.hashes
        
        # Create a new vault with the same master password
        mkdir -p $HASH
        cp $ORIG/master $HASH
        
        # Copy all secret in new vault, using their hashed names as key
        for p in $(find $ORIG -type f | grep -v /master$); do
        	n="${p##$ORIG/}"
        	h=$(echo $n | openssl sha256 | cut -d' ' -f2)
        	cp $p "$HASH/$h"
        
        	# print "HASH	NAME" for the hashmap
        	printf '%s\t%s\n' "$h" "$n"
        done | safe -s $HASH -a hashmap
        

        Note: the hash is the one of the entry name, not the password itself of course ;)

        Then you end up with a password store like the following, which you can store in plain sight over git or whatever:

        .hashes/master
        .hashes/hashmap
        .hashes/455f66d5e5f75ec1334127d73a3479b7a66c69ef4cc094e28def2075cc731035
        .hashes/d3eb539a556352f3f47881d71fb0e5777b2f3e9a4251d283c18c67ce996774b7
        .hashes/98623d38989a6957ec74319dc4552480fa3d96a59c5ffcac76c0e080d3940406
        .hashes/df58574b01c57710a70ba201df6b5fb8dc0bf3906b8bf39f622936f92e6ffec7
        

        And when you want to de-obfuscate it, you can decrypt the secret “hashmap”, and used that to rename your entries:

        $ safe -s ~/.hashes "hashmap"
        455f66d5e5f75ec1334127d73a3479b7a66c69ef4cc094e28def2075cc731035        dedup.key
        d3eb539a556352f3f47881d71fb0e5777b2f3e9a4251d283c18c67ce996774b7        dummy
        98623d38989a6957ec74319dc4552480fa3d96a59c5ffcac76c0e080d3940406        token/gitlab
        df58574b01c57710a70ba201df6b5fb8dc0bf3906b8bf39f622936f92e6ffec7        switch
        
        1. 4

          Yeah this downside bothers me a lot and it felt I’m pretty much alone in that. It’s what prevented me from using pass for ages.

          I’d made the switch eventually and I’m really happy with it, but I had to add an the name obfuscation myself. The “unix philosophy” of pass is great because you can actually build stuff on top of it.

          1. 1

            Yeah the weird thing was all the outrage that 1Password got literally the same issue, but nobody it saying a thing for pass. Not that I recommend outrage but I think it’s important to be aware of the attack vectors.

            1. 6

              Every time I see pass come up, it’s not long before someone mentions that the names of passwords aren’t kept secret. This seems like the most frequently mentioned and most severe downside of pass. So I’m not sure that it isn’t talked about much.

              I do personally use pass and I do it in spite of the names being leaked. My threat model isn’t particularly sophisticated, so I’m generally okay with hiding the names simply by not sharing the repo.

        2. 5

          Note that git use is optional. My ‘pass’ passwords are backed up daily along with the rest of the important files in my home directory, no extra work required as they’re just GPG-encrypted text files.

          1. 4

            Came here to say the same thing. My backup of my pass repo is a) it’s on every device I use and b) gets synced monthly to my off-site backup drive. If I lose the encryption key I’m in trouble, but I back that up, too.

            Using 2 password managers seems like a strange solution to me.

            1. 2

              I switched from pass to KeePassXC a while ago. I use Syncthing to get the DB to my phone for use with KeePassDX and encrypted backups are automatically taken overnight with borg.

              Recommending two password managers is a little odd, I agree, but he does bring up a good point that everything is fallible and multiple backups are a good thing to have.

              1. 3

                Eh, it’s 2 applications reading the same file format. Calling them 2 password managers would be the same as using 1password on 2 platforms, I don’t even see that worth mentioning.

                FWIW, I also use KeepassXC on Linux+Windows, and Keepass2Android on Android, and Syncthing. I only sync down to my phone like once a month, and it works beautifully.

              2. 2

                If I lose the encryption key I’m in trouble, but I back that up, too.

                I use gopass, which allows for multiple encryption keys for the same password store. This is very useful in the case of losing access to one of them, or the intended purpose, having multiple users of the same store.

              3. 4

                The unfortunate issue with pass is that when it uses git to back itself up, you still need a way to backup your GPG key, which is of course incompatible with git. Even if your GPG key is encrypted, I doubt you’d want to publish it online. So in order to backup your password manager, you must come up with 2 different backup medium, which means twice as much possibilities to lock yourself out.

                Also, managing a GPG keyring can have a lot of problems on its own on a daily usage basis (using a device without your keys, syncing keys, …). On this topic, using password managers based on a master password can help a lot.

                1. 1

                  Those are all good points. Since I use GPG for basically everything else (signing commits, communication, etc), the work to back that up I don’t really consider it to be part of the ‘backup my password manager’ activity.

                  The beauty of pass is that the storage mechanism is just a bunch of flat text files. Back them up however you want, you don’t have to use git (but it is nice that git support is built in).

                  I doubt you’d want to publish it online

                  Who said anything about it being public? Private git repos exist, either self hosted or with some paid service.

                  1. 1

                    When you use GPG on a daily basis for other stuff, this would make more sense indeed. It is not my case though, so it bothered me a lot. So much that I ended up writing my own to mirror “pass” usage but with a master password. The cool stuff about it is that I can now store my GPG key inside my secret manager 😉

                    You’re right about private repos indeed, I think making it private makes it more complex to use git to sync it across devices. It makes for a good backup anyway as you said ! The flat file structure is great, and the composability of the tool makes it a breeze to obfuscate, backup, convert or integrate to any workflow !

                    1. 1

                      I think making it private makes it more complex to use git to sync it across devices.

                      Not that complex, but yes, you now have to use either password or key auth to access it. And keep track of that, etc. The main thing I like about this setup is that it’s made from several simple components. Any of which could be replaced without affecting the others (or affecting them enough to require significant changes). And the architecture is simple enough for me to understand it without having to trust some external entity to always do the right thing and not break.

              4. 3

                You can look at the whole history over the last 10 years, and 1Password has never been down for more than 3 hours. Most outages are <1 hour, scheduled ahead of time for maintenance in the middle of the night. :shrug:

                I feel really good about giving them money!

                1. 5

                  1password is a proprietary service, one day they will no longer exist.

                  1. 4

                    There are many solid businesses that have been around since before the notion of free software even existed. And the average open source project doesn’t exactly have a long maintenance lifetime. I think I’ll take my chances.

                    1. 3

                      Pass is simple enough that it could be reimplemented in an afternoon if its ‘maintenance lifetime’ ended and it was (magically, for some reason, but I’ll play along) no longer available to decrypt my passwords.

                    2. 3

                      Is it more probable that I’ll stop existing first, though?

                      1. 4

                        Recent history is full of technology companies that have gone under, or were acquired and their services shuttered.

                      2. 1

                        However the 1Password apps store a local copy of the data so even if the servers go offline (or down forever) you can still access the data and the desktop app lets you export the data.

                        1. 3

                          That’s how it works today, but there’s no guarantee it’ll work like that tomorrow. And since it’s proprietary, you’re just along for the ride.

                          1. 0

                            That’s a little too cynical for my liking.

                          2. 1

                            LastPass and Bitwarden does this too. However, you can’t access it in situations when you’re online and they have a problem with their logon servers. Their apps reach out to the server to verify the login and get a fault condition. Their apps don’t then allow you to access the password vaults even though you have all you need to decrypt it locally. The local copy only works if you go offline first and then try to login.