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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 !
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.
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:
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.
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.
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.
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.
The password manager I use (pass) has a really simple and widely supported ‘backup’ mechanism built in (git).
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
passand adds a few interesting features like git auto-syncing and browser integration.For the issue of having your names unencrypted, I came with the following idea for
safe, which could also work withpassor 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
safeas a backend):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:
And when you want to de-obfuscate it, you can decrypt the secret “
hashmap”, and used that to rename your entries:Yeah this downside bothers me a lot and it felt I’m pretty much alone in that. It’s what prevented me from using
passfor 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.
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.
Every time I see
passcome 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 ofpass. So I’m not sure that it isn’t talked about much.I do personally use
passand 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.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.
Came here to say the same thing. My backup of my
passrepo 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.
I switched from
passto 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.
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.
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.
The unfortunate issue with
passis 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.
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).
Who said anything about it being public? Private git repos exist, either self hosted or with some paid service.
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 !
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.
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!
1password is a proprietary service, one day they will no longer exist.
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.
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.
Is it more probable that I’ll stop existing first, though?
Recent history is full of technology companies that have gone under, or were acquired and their services shuttered.
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.
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.
That’s a little too cynical for my liking.
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.