1. 2

    I only got a handful and I’ve always named them after the characters from the Wiedźmin (Witcher) books: Geralt, Ciri, Yennefer, Regis, Anguleme, Cahir, Jaskier, Triss, etc.

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

                1. 7

                  I’ve always wanted to make games so the project closest to my heart is Dose Response. It’s a small open-world roguelike where you play an addict. Written in Rust, running on Linux, Windows, macOS as well as WebAssembly. Free/Libre/Open Source, pay what you want.

                  Unfortunately, I did not have a lot of time and energy to update it after the 1.0 release yet.

                  1. 4

                    A great game! Thank you for sharing.

                    1. 2

                      Thank you for playing! I’m glad you like it!

                  1. 4

                    This is not a very good idea, IMO. Many utilities/tools tend to create folders and files in the home directory, like Ghidra for example, creates a ~/ghidra_scripts. It’s bound to get messy fast. It’s probably a better idea to maintain a separate “dotfiles” folder where you symlink config files/folders that you want to persist across installs, and version that using git instead.

                    1. 3

                      What do you mean?

                      The first line in the ~/.gitignore file causes it to ignore everything. Anything you want to track you need to add explicitly and new files won’t even show up in git status.

                      1. 2

                        Oh right, yes. My bad. I’d failed to notice the first like in your .gitignore.

                        1. 1

                          Not mine, but yeah I wondered :-). I’m using the more traditional dotfiles approach as well.

                          I had actually tried to put my home dir under git ages ago, running exactly into the issues you’ve mentioned. Ignoring everything by default and only adding files explicitly does sound like an interesting alternative to consider at least.

                      2. 1

                        This argument makes sense to me when it comes to synchronizing two or more different computers.

                        What kind of version control systems is preferable when it comes to the synchronization/backup of the ~/Documents folder alone? I guess syncing Windows/Linux mashines should not be a problem here, no?

                        I using rsync for backups these days, and never thought about looking into version control systems. Any experiences here?

                        1. 2

                          It depends. If your files for backup are generally text based, i.e. config files, then using a VCS is a good idea. Something like git offers great ease in managing them. But if your files are binaries, like pictures for example, then rsync is alright, I guess.

                      1. 6

                        I’m one of those people who learned English with British textbooks and for me that’s a mega useful feature, as I constantly opt for the British spellings, even though I know in Computer Science we’re not supposed to use them.

                        I am spelling British and am rather unapologetic about it. Languages have dialects and people should spell in any colour they want to.

                        (I see the strive for consistency, but as long as the particular codebase has not standardised on a spelling, I won’t walk around and figure out which one it uses)

                        1. 2

                          I’m Canadian, even for words that we consistently spell British (which is most of them I think), I spell American in source code. Most source code seems to be American and I want to minimize the number of identifier mispredictions for anyone editing it - including myself.

                          1. 1

                            It’s the same for non-English speakers. Few people write code in anything other than American English.

                            1. 1

                              But don’t they generally then also spell American English outside the code, then?

                              I don’t (English is my second language, my spelling is British, but in code I do American for the same reasons gpm outlined). However, I come to contact with a lot of non-native speakers and I feel that pretty much all of them lean American in both their spelling and pronunciation in all contexts.

                              1. 1

                                My point was primarily about English, not specifically only the American dialect.

                          2. 2

                            I’m an American and I use American spellings in my own code and writing about code. That said I see no reason why British people or nonnative speakers who learned British rather than American spellings should feel the need to switch. I think nearly every educated AmEng speaker is familiar enough with British useages (and vice versa) that there’s no serious barrier of comprehensibility.

                            As a matter of fact, in my readings of the recently-deceased Joe Armstrong’s papers and other writing about Erlang, he (a British person who worked in Sweden) did in fact use British spellings like “colour” without any kind of problem.