There's a ton of positivity here, but on the balance there are some significant issues with pass that I think bear mention:
- The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in.
- `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
- It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc.
- The name makes it nearly impossible to search for
I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth
> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc.
pass sets up a .gitattributes and configures git to convert gpg files to text via a custom driver. This enables a text-diff of the encrypted contents out of the box (at least for a store I've just set up to test this).
- Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...
- Hard to install if not packaged. I tried to install `pass` on a headless NAS, but it required gpg, which looked hard to cross-compile to aarch64.
- `pass` is a light interface over `gpg`. So it has all the problems of GPG – I've had a few annoyances with `gpg-agent`. Many organizations are trying to ditch GnuPG and switch to simpler and better cryptography tools, like age. https://github.com/FiloSottile/age
- Android with `pass` was a bad experience. The official package was unmaintained. The fork was not packaged in F-Droid. The UI was cumbersome.
I still use pass, for lack of an obviously better universal solution. There's FiloSottile/passage for minimal change, just replacing gpg with age, but no Android. A better alternative would be gopass, which is portable across all unixes, is compatible with `pass` and has an age plugin. But still no Android packaging. https://www.gopass.pw
> - Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...
What do you mean? I copy my repo to new computers by just copying .password-store and I've never had a problem.
Sometimes I add "/notes" with unstructured text contents, and for a few special cases I created a file "/json" with some machine-readable things in JSON format.
It's not perfect, and I do dislike the way that the metadata isn't encrypted, but on the whole I'm happy with the solution.
Yeah sure, but then are the conventions you came up with shared by all the tools in the ecosystem too (ex: browserpass)? Since the keystone (pass) declined to provide strong guidance, you end up with fragmentation and incompatibility.
Yeah, but that's just your convention. I, for example, store password in
private/foo.com/foo-com-login
The first line of that file is password, the rest are optional notes. I think using first line for password and the rest for metadata was intended originally.
I love pass, but I agree that it would be nice to have an established standard of where to put username etc.
> - The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in.
Fair, but you can use your own conventions.
> - `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
Just split it into `site/pass`, `site/secret-question`, etc. The fact that it's just using a directory tree is quite nice.
> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful
`git diff` would be an odd command to run on generated passwords even without encryption. What matters is that you know when the last change was for a password or site with `git log <file/dir>`, and you can just `git checkout -d <old commit sha>` if needed.
> - The name makes it nearly impossible to search for
in the terminal `$ pass` typically suggests the associated package.
There is an established convention for usernames, which is to put "user:" at the start of the line. It can't be the first line of the file but is otherwise not order dependent. The browser plugins and android app implement this and do autofill based on it. That is suggested on the main site.
If you blat your password with generate, it can be recovered because it is in git. A nice to have for pass might be a flag to autoinsert only on the first line, but in lieu of that, pwgen should do the job and is what pass uses under the hood.
> I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth
> stored in encrypted sqlite3
you had me at encrypted sqlite3. it would be great if you mention in readme that it uses SQLCipher
There is a bit of structure imposed if you want to use the provided automation for inserting passwords in the clipboard. The password comes as the first line. Then you are going to end up with the user name on the second line. Everything past that point is gloriously unstructured. I have a pass entry floating around here with an entire onboarding email in it...
For me the unstructured data is a big bonus. And it's not really unstructured. You can put Username: xxx and browser plugins like browserpass will pick that up.
Browser password managers with passkeys are more convenient for me, but a pass vault can still be useful for recovery codes and API keys.
I used pass for a while but couldn’t see what threat model it actually solves:
If you let GPG agent cache your key, any script (e.g. an npm post-install) can just run `pass ls` or `pass my/secrets` and dump all your credentials. At that point it’s basically just full-disk encryption with extra steps—might as well keep everything in ~/passwords.txt.
If you don’t cache the key, you’re forced to type your long GPG password every single time you need a secret.
I tried a YubiKey for on-demand unlocking, but the integration is clunky and plugging it in constantly is a pain if you need passwords multiple times per hour.
That’s true for any password manager. If the database/store is unlocked (so the master password is cached or available in RAM), all passwords can be extracted. You have to lock the password manager when you don’t need it.
In fact, with Bitwarden, the cached password is exposed to the browser that has a large attack surface (including interacting with random remote servers). There was just a vulnerability in most browser based password managers including Bitwarden that would allow a remote attacker trick a user send out their passwords.
I use Bitwarden but mostly for non-critical passwords.
Doesn't good 2factor minimize a large attack surface like this?
I like the idea of storing password data in individual encrypted files and using git to store changes, but I wonder if it creates more friction to retrive the information. I havent tried this solution yet. I will when I get more time. It seems like this solution would benefit from a more standardized specification for storing and retrieving information. I known its not every persons cup of tea, but maybe some kind of separated add-on for streamlining this process could be beneficial.
Modern operating systems isolate individual apps such that a malicous app can not access the RAM of another app. There is a difference between not making an effort to protect passwords and requiring an OS exploit to do so.
Memory isolation doesn't really help, though. If you have a malicious process running under the same user account as your password manager, it's still game over since that process could e.g.
- capture keyboard input
- capture your screen
- silently install browser extensions to capture your credentials
- modify your shell config, .desktop files, $PATH, … to have you e.g. call a backdoored version of your password manager, or put a modified version of sudo on your $PATH that logs your password (=> root access => full memory access)
- …
You can use Qubes OS for true VM-level isolation, or use hardware security keys where possible, or run sensitive applications in dedicated VMs.
I think that in general it is game over the moment you have malicious processes running. I use firejail for most applications, which I believe is the bare minimum, or bubblewrap.
Yeah. Personally, I'm crossing my fingers for SpectrumOS[0] to make things a bit easier. As the developer notes on her website[1]:
<qyliss> I have embarked on the ultimate yak shave
<qyliss> it started with "I wish I could securely store passwords on my computer"
<qyliss> And now I am at the "I have funding to build my own operating system" level
I don't know how usable SpectrumOS is so far – I guess we'd have to compile it ourselves in order to find out. Either way, it is being developed quite actively, see https://spectrum-os.org/git/
As for how it compares to Qubes, I don't think I'll be able to tell you more than https://spectrum-os.org/design.html & friends. I suppose the upshot is:
- KVM instead of Xen
- One VM per application
- Single file system for user data (to which users can grant VMs access on a folder-by-folder basis)
- Package system from NixOS (nixpkgs) for reproducibility & immutability
Ugghh, once again I forgot that HN removes line breaks unless you use double line breaks or indent by 2 spaces, and now it's too late to edit my comment.
@dang People keep running into this. (See e.g. this comment[0] from a few days ago.) It also makes it rather awkward to write lists IMO. What's the reason for removing line breaks and could this be changed?
For modern operating systems capturing keyboard input is locked down to avoid keyloggers. Capturing your screen requires explicit user permission to do so, popping up a dialog. Apps are isolated so another app can't interfere and install a browser extention or modify shell configs, etc.
The OS protections apply to all applications. In addition, the job of agents like gpg-agent or ssh-agent is to protect secret keys while they are cached (like preventing OS writing keys to swaps). You can configure them to erase keys after a certain time, require user’s confirmation for each key operation, store gpg keys in internal TPM or external hsm, and would talk to the agent through specific sockets.
Unlike browser-based password managers, the agents don’t continuously interact with the browser code and remote elements (probably don’t have network access at all).
One area that matters that I forgot to mention in my comment below is that, as a result of all above, Pass doesn’t check the domains and doesn’t protect against phishing. There might be extensions, but at that point, you might as well use keepassxc.
I just leave my yubi plugged in. It requires a physical touch anyway (at least you can configure it for that which I have). And my place is physically secure.
The good thing also is that unlike with fido2 you only have to enter the pin once for OpenPGP. Then it stays unlocked while it's plugged in. But still needs the physical touch for every password. Perfect and convenient for me.
It also works great on mobile with openkeychain and password store. Both are not really maintained now but I don't really care because the encryption is in hardware anyway (yubikey over nfc)
I store my passwords on an encrypted file partition sqlite database. My script grabs the pass and immediately closes the partition afterwards.
You can also just encrypt your passwords into individual encrypted files (one for each password) and have your script clear the gpg agent after a passfile is decrypted.
I can't remember how but pass for me works in brave browser and Firefox, as well as on mobile. It's my only password manager. I'm assuming some browser plugin.
Is the biometrics step (fingerprint reader) on macOS much different from a ubikey? I imagine implementation may have some differences, but in practice it seems I can already protect access to my GPG key using the built-in reader, so what’s the advantage of ubikey in that respect? Genuinely curious.
The TouchID is bound to a device - of course, I could copy my secret into a secure enclave that is only accessible through TouchID. Could even just store my GPG key there. With a Yubikey, I generate the key on an airgapped device and store it on the Yubikey. No other piece of hardware ever needs to see my secret key in plaintext. I could achieve the same with TouchID, generate the secret key inside the enclave, but then I cannot move the secret keys out without some other computer baring witness to that.
I really do not want to give Apple any more leverage over me, I'm looking to minimize it.
it took a while to get it to work well, but I use yubikey here, and recommend it.
I do need to find and pulg it in sometimes, but overall might leave it plugged in.
and I have it configured to require a touch for every operation
This is interesting for CLI lovers, but I feel KeepassXC on desktop + KeepassDX on Android (with the password DB stored on my own machine and accessed remotely via Wireguard) is a better solution for normies.
keepass has a very underrated feature i never see much talk about where you can have multiple vaults and have them open and search both at the same time (or at least the two apps you mentioned support that anyway).
most password managers are based around the idea of one single vault which creates the problem of having to treat every password like it needs the maximum amount of security. in my own case i would guess maybe 70% of my passwords are for unimportant sites where it wouldnt be a huge issue if someone else got the credentials, but every time i need to log into one of those sites i need to enter my long master password.
with keepass i can put that 70% into a separate vault and use a shorter master password that is quicker to type, and i dont need to worry as much if im opening that vault on a computer where i might not be sure its completely secure
Also, KeepassXC and OG KeePass with a plugin can auto-open another vault from an entry in the primary vault. This works well if you have the more secure vault open a less secure vault, or in my case open a shared vault used for common passwords off a network share at work.
I also preach the tiered password security model. For the common, frequently used passwords that don't need max security, I just use the browser store (with a copy in KP).
I keep a Keepass vault with my 2FA secrets and a separate one with my passwords. This reduces the biggest fear I have where one compromise reveals everything.
These are both offline backups of my Bitwarden, which is my daily driver. Bitwarden doesn't store any of my 2FA info though.
I use pass also on my phone in combination with Termux. I keep the passwords stores in sync using git. pass on android also supports copying your password directly into the clipboard, which is especially nice on a mobile device.
My family members are all with iPhones, and their Passwords is very good. I only backup a couple of sensitive passwords to my pass store just in case. The rest of the passwords are basically disposable.
Don't forget keepassxc.cli, which allows you to programmatically set and retrieve secrets. The interface is significantly more user friendly arcane. I used it when I needed to build an encrypted secrets bundle (so that one long password could temporarily unlock some API keys required for a disaster-recovery situation.) I was able to generate a single file plus a "Makefile" to unlock it and pass the keys into the appropriate environments.
I had attempted to use GNU `pass' first, but sadly, it requires me to manage gnupg, which is a well known minefield of poor default options, and assumes it should be integrated into your shell by storing things in your user profile directory (instead of using the directory relative to where you call it.) This jeopardized my copy-one-file workflow, so despite its ubiquity I had to abandon it.
The only use case of mine that's not solved by keepass is creating passwords on two separate machines without a direct connection, and merging them later.
I solve this by Syncthing running on all clients. Very rarely do I ever have a problem with conflicts. Only if I add a new pass while my phone is offline and then make another edit on my computer would there be an issue. I think it only happened once, and that was because I did it on purpose to see what happened.
Turns out syncthing creates a .conflict file and then I tell keepassxc to do a merge on the two files and then we are back to normal.
I would love to use KeepassXC but it doesn't make it easy to share credentials with the wife. I _could_ use a dedicated vault, but we'll then need to cut-paste things for sharing existing credentials.
So, for now, I've settled on Vaultwarden and it has been surprisingly stable so far.
Shameless plug. I built a tool[1] to manage Keepass archives in the terminal which might scratch some of the itches I am reading here: it has a TUI, but can be piped into other commands too.
Im thinking of trying this, I just used local files until now with keepass. in my case a synology nas to hold the file, a two bay equipped with 2.5" ssd that i already use for notes, music, and other stuff + wg
This is fun if you never leave yourself, but be wary with whom you share it. As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly. (Or none, if you can't be bothered.) (Don't ask.)
Or if someone newly needs access, there's no standard way of re-encrypting the files you're guessing they need. You need to hack something together yourself
It uses git, but the commit messages are autogenerated and useless. It might as well have used Dropbox for all the use you get out of it when wanting to find the version before someone corrupted data with their somehow-broken gopass client
There is no way to ever erase anything you've accidentally pushed, short of rewriting the git history and breaking it for everyone (or for personal use: other client devices)
It looks nice and simple, and I like that I can interface with it with manual tools (e.g. write my own commit messages to have some idea of wtf is going on, e.g. when mass-reencrypting to not have 300 commits), but the simplicity is also the pitfall. Feels a bit similar to using hash(site_name+main_password) as a per-site password: beautiful in simplicity but various practical issues
Does anyone have good experiences with a password manager for a corporate environment? Ideally not having yet-another service to maintain, but also not have a server compromise equal business compromise (so end-to-end encryption between the users; verifying fingerprints or some such). From what I found so far, Bitwarden seems to meet that bill but I don't know if there are also others
> As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly.
You can setup different directories to use different keys, and you don't need to limit yourself to a single key for each password either. You can use multiple. So you can setup structures like:
- admins/.gpg-id "admin\n"
- techs/.gpg-id "admin\ntech\n"
where admin and tech are 2 keys for different groups of people. Admin having more access. Or even better:
- site_foo/.gpg-id "bob\nalice\n"
- site_bar/.gpg-id "bob\nrobert\n"
where each employee has their own key. So you can fine-tune which passwords need changing if an employee leaves, and which passwords an individual employee needs to be able to access.
You can setup git submodules to control which passwords which employees can know to exist.
And given that git is being used, you can know which passwords an individual employee ever had access to, were their access to change over time.
"having access to" is not the same as having opened it, though. A server could log which files were retrieved without knowing what the contents are
By having such audit logging, we could see that we e.g. don't need to call the alarm company to change the phone password. Most people don't work in the office outside of business hours and so never need to call them, but since it's the only way of proving you're an employee if you accidentally set off the alarm, we give everyone access to that password. There's at least a dozen examples like that
I have no practical experience yet, but i evaluated the market for a password sharing solution for a team with similar requirements within an enterprise.
It uses a public/private key approach, where the plain passwords never leave the local machine and shared passwords are re-encrypted with each users public key.
My current employer uses 1password and it has a couple of nifty features like "vaults" shared with a group of people, an "op run" command to inject secrets using a .env file, service accounts to fetch passwords in CI, etc.
Sounded nice, but I'm not sure what this actually adds. I'm currently using 1Password for doing "environments", but it's all using the existing `op` CLI.
So adding a new collaborator to the project would involve adding them to the vault, then there is a shell script in the project that uses the CLI to write a new `.env` depending on the values from `op`.
Seems like this new environment stuff wouldn't add anything compared to such setup, at least today, is that fair? Seems to be even more manual and require copy-pasting, unless I misunderstand what the feature actually is.
Yeah, I think the idea is instead of writing a .env you would, perhaps eventually, have a command like op that just loads the environment whole cloth. But you probably won't get much value out of that today.
for a complete solution to dev envs and production secret management I use Envie https://github.com/ilmari-h/envie
it's like a drop in replacement for traditional env files
The Android Password Store application by msfjarvis was archived last year. It was forked and greatly updated by agrahn. There are APKs on GitHub Releases and F-Droid, but not Google Play Store.
Agreed, GPG is not the most intuitive tool, but once you are familiar enough with it, it opens some doors.
For me termux and pass (from F-droid) have solved my password management for many years. I never have to struggle finding passwords. The security aspect of it is the least I care about, it's the convenience and simplicity of it.
Since the passwords are all just files on a disk inside a directory tree, you can use any old file system tools to find your passwords. Same for MFA. I store the base32 string inside pass and that's the end of it.
I recently moved away from pass after a decade or so.
Two main reasons:
1. This laptop up was set up with flatpak versions of all GUI applications, including Firefox, and the browser plugin just doesn't work. I persisted with the work-around of `pass -c <path>` from the run command prompt for a while to paste into the browser, but its not ideal.
I made the switch from pass recently too. I had ~400 secrets stored in it for almost the same time as you.
Ultimately I wanted something easier to sync between multiple devices. Now that I am traveling more seriously I can't get away with only having a few important passwords saved on my phone and laptop.
It was a lot easier to sync (1) file with KeePassXC and it has 2 well supported Android apps to choose from. It took me around 3 hours one day to manually move everything over, I took that as an opportunity to prune and refactor everything which is why I didn't use the CSV import feature.
Password managers for me are a "write occasionally, read frequently" app so it's pretty painless to shoot over 1 file over my local network to keep 3 devices in sync.
That's curious. I moved from KeePassXC to pass precisely because the synchronization story for the database file wasn't working so well. For too many times I ended up with an outdated database in the backend server because the sync process failed to work properly.
After I moved to pass, every credential became its own file and I rarely edited the same credential in way too many devices. For the rare conflicts I had, having it being Git made it possible to resolve them without massive hassle.
Then again, that was also some many years ago. Maybe the synchronization story is better these days.
I didn't like the idea of pushing a pass git repo to a private GitHub repo.
For now I just temporarily drop the DB onto Google Drive manually (through the web site since I don't use the app) to quickly share it to the other devices without worrying about USB cables or running native apps on each device. Then I delete it from Google Drive.
I'm hesitent to use "sync" type of tools that run on each device because I don't have a central server. Also I really don't like the idea of running any type of cloud hosted network storage desktop app on each device to have a network drive.
We'll see how it goes I suppose.
I wonder if it'll involve writing a tiny shell script that I run on my desktop machine to handle syncing it across devices and it always ensures the latest copy makes its way onto each device. That would allow me to freely add new entries on any device and worry about syncing it across devices when I am 100% sure all devices are on the same local network. I think that will work out in the end.
I don't need real-time replication because if I'm on the road using my phone, I don't mind my desktop being outdated until I get back home.
> I didn't like the idea of pushing a pass git repo to a private GitHub repo.
I had the same reluctance at first, but after considering it was protected both with my gpg
key and my passphrase, and private on top of that, I came to the conclusion it is fine for me. It feels assuring to have it in a remote location where it is safe if I have burglary or fire or an accident like that. My keys are in a few secure locations too
> I persisted with the work-around of `pass -c <path>` from the run command prompt for a while to paste into the browser, but its not ideal.
There's also `passmenu` that comes with `pass`. You setup a keybinding that calls that. It autocompletes your password selection with a menu (calls dmenu) and puts it on your clipboard. You skip having to invoke the command prompt then manually calling `pass -c` and writing the path.
Well shit, I didn't realize the Android app was shelved. I checked out the fork and it looks like they're doing good work there. I'm a bit surprised that the maintainers of both didn't work out a transfer; who else better to take over the project than a active fork?
Makes me wonder if something else was the issue, such as disagreeing over security practices or the like.
> I persisted with the work-around of `pass -c <path>` from the run command prompt for a while to paste into the browser, but its not ideal.
I actually do this on purpose. The last time I checked into the plugin, it looked like it unlocked your gpg key at Firefox launch rather than at password prompt time. Also, I didn't like the fact that the plugin creator could simply send my passwords to themselves without my knowledge. Firefox and pass are big/trusted enough to not do this. But some random guy? That was outside my risk tolerance.
I'm in a similar situation and considering doing the same thing as you, for the same reasons, but I'm curious about how the offline experience is.
I'm often facing periods of bad to no connectivity, and I find the ability to lookup or even update a credential offline very useful. Not sure how much of it is possible with Vaulwarden and I couldn't find the time to try it yet.
Another anecdote: Started using a password manager in 2017 (8 years) and today I have 520 credentials, using it for everything from my normal accounts to environment variables, configuration and a bunch of other stuff. Only thing I handle myself outside of it is ssh and GPG keys.
I like pass and use it a lot, especially as it provides a good and safe backup for the case my vaultwarden instance goes up in smokes.
There is also a drop-in replacement with has some extra features and a bit better UX in some parts, personally I only really use it for the better support for handling multiple GPG keys, as I got some physical backup keys and it can be also nice teams for a shared vault.
Pass is still amazing after all these years. Shameless self plug: I wrote a gnome search provider for it so you can lookup passwords from the overview. Supports OTP as well. https://github.com/Fingel/ripasso-gnome-search-provider
I have heavily used Pass over the years. Here are some of its pros (an update to my comment several years ago):
* Your secret key can be stored in Yubikey, handled by a dedicated OpenPGP agent. This allows deriving a strong key from a weak one. Your password is basically a short PIN with max 3 tries. Every password retrieval can require a physical touch. This is convenient and secure!
Pass makes sense if you use it with a hardware key, with touch enabled. With this setup, it’s hard to beat its security.
* It uses public key cryptography, and comes with its advantages. You don’t need your master password to add/encrypt passwords. You only need that for decryption. Less exposure of master key, and more convenience.
For that reason, it’s well suited to share passwords with other people or devices. You can encrypt to multiple public keys. This adds multi user and device support.
You can easily add a backup offline public key (which you may print) if you lose your Yubikey.
* You can decrypt a single password without decrypting and exposing other passwords. The passwords are isolated, if you use Yubikey.
* Searching passwords is quick and transparent. You easily see what is in your store.
* You can use it programmatically, eg, your backup script can grab a password from the store.
* It’s a short bash script that you can verify, and delegates encryption to a dedicated well-audited cryptographic tool.
* PGP is a standard, and GPG and git are widely available. There is no database to break or migrate. You can read your passwords anywhere and in the future.
* The script is written by the creator of the acclaimed Wireguard!
There are also cons.
* Some people don’t like that it leaks metadata (filenames, and password tree), though there are versions of pass that fix it.
* Lately gpg is causing some troubles with Debian Trixie. GPG agent frequently locks the Yubikey and requires restarting pcscd (probably due to conflicts with pcscd).
There is a similar tool Passage using Age, maybe that solves it.
* There are mobile apps, but they are not as frequently updated as something like Bitwarden apps (which has client for every OS, and frequently fixes bugs and adds functionality).
* I haven’t used and not sure how good browser support is.
Here is a post on a similar password management with GPG replaced with Age
About mobile app, I never used pass until today, but it seems great, and so far I only tested it by installing it on my phone in Termux. Can't think of a reason for me to use a special app when running it in Termux works so well. Was happily surprised that even pass show -g worked out of the box, copying output to Android clipboard.
That is also nice since I have ssh already set up so syncing to my computer from the phone will be easy.
This guide covers many adjacent topics; the relevant
part is generating the secret key inside Yubikey, or in an airgapped system and doing “key-to-card” in gpg.
I used pass for many years and loved it. I sync'd my password store between 3+ devices including my Android phone using a git remote. I don't recall the exact reason - maybe the pass android client I had used for years went away? I decided to find the next best option and settled on keepassxc and KeePassDX. The backing store is a binary blob but it does surprisingly well via syncthing: autoupdate works and in the event of a conflict the db merge feature hasn't yet failed me.
Granted on the desktop I find using a (qt especially) GUI more invasive than a terminal but at least on the Android side the app is quite good.
I have a different approach I’ve used for about 10 years that I like a lot. All password metadata is stored in a plain JSON file indexed by name (usually site name). Each entry contains at the minimum a username. Optionally it has a version number and some password rules like the length (20 if absent) and the character classes that are allowed, along with how many of each character class are required. None of this data is sensitive, so if you look at the file you see my list of sites. The actual passwords are not stored, because my tool is actually a deterministic password generator, which prompts me for a passphrase and generates a password from the passphrase and a hash of all the metadata. One nice feature is that if I just change the version number I get a whole new password, and the “history” is still available by changing the version back.
The one major downside to it is that it is absolutely unusable for sharing passwords because obviously that would require sharing my passphrase, and there is no way to “store” a password that someone else set. I’ve thought about writing a mode that would encrypt a string (eg a shared password) with the metadata-generated password and store it in a separate piece of metadata for that purpose, but the number of times I’ve needed that has been extremely small.
I found the idea of a password generator appealing, mainly due to vault anxiety. I didn't (and still don't) like the idea that I can't access a resource without this precious vault. If I'm home with my tools, great. Otherwise, give me the right hash function, and I can MacGyver my way to PBKDF2 and generate my password.
However, once you introduce metadata (e.g., to deal with password rules), the idea loses most of its appeal. I wouldn't feel any more comfortable posting such a thing publicly than I would a vault.
The metadata doesn’t bother me at all. Anyone who wants to can read that I have a Seattle City Light account, that it’s password is v6, and that the password rules say it can have all alphanumeric characters and must have at least one of a weirdly narrow set of “special” characters. That information alone isn’t enough to get anywhere.
What could be considered more sensitive, if you cared, is usernames. Someone looking at my metadata would learn my hn username, for example. But I don’t really consider that “secret” info.
Of course. This is absolutely never used for sharing. That’s why it’s called out as a drawback. When I need a shared credential, I’m forced to use a completely different mechanism. But this is pretty rare with good practices (which discourage shared credentials).
I've been doing basically this for many years now.
Each password file is AES-encrypted with my master password.
I copy the whole vault around between machines with rsync.
When I run 'password bank' a shell script searches ~/private/Passwords for files that contain ‘bank’ and offers a menu, then gpg-decrypts the file I selected.
I also use this for scans of my passport, recording my bank account numbers, and anything else I want to keep around.
I thought I was the only one, and now I've found out there are thousands of us!
This means we don't need to move gpg/ssh keys we can just recreate them by remembering their passphrase (and other stuff like the date if we want).
# gpg key for the encryption of the password-store
passphrase2pgp --subkey --protect=2 --uid "helloworld" | gpg --import
#for access to the git remote repo add to it this public key :
passphrase2pgp -u emergency -f ssh -p > ~/.ssh/emergency.pub
#only use it to install a non-emergency key as a new authorized key :
passphrase2pgp -u emergency -f ssh | ssh-add -
I read a blog post for the above but can't remember what it was, but it's amazing now It's very easy to download and access the password-store from any devices, I use it in window, linux and termux.
Funnily enough I never used `pass generate` once, even tough I have more than 3700 passwords.
I always used the `pwgen` command, I don't know if there really is a big difference between the 2 (except pass generate being already in pass).
As for how to structure, here are some example of how I do it :
They are all only one line except some backup codes which use multiline.
Then it's very easy to get the password or the otp, just bind `passmenu`, `passmenu-otp` in your window manager or directly use the command line for multiline stuff.
I recently did a deep dive on cli password management in an attempt to harden my bash scripts. (yes, I love bash, despite HN always loving to talk crap about it)
Pass is just a shell wrapper around gnupg, when you run pass some/secret/path, what actually happens is pass constructs and executes a gpg command (e.g., gpg --decrypt ~/.password-store/some/secret/path.gpg) and the output of gpg (the plaintext secret) is piped to pass's stdout.
Most people know this though. What I learned I didn't know before though was this:
Memory Zeroing: after it's used (e.g., copied to a pipe or stdout), GPG's internal memory management aims to zero out those memory regions used as soon as they are no longer needed
Memory Locking: GnuPG also uses mlock() (or equivalent OS-specific calls) to lock sensitive memory pages into RAM. This prevents the plaintext keys and decrypted data from being swapped out to disk, protecting against swap-file forensics or cold boot attacks.
I had been banging my head against bash trying to do those things manually, and ended up with the conclusion it was best to use pass/gpg with the following addendums (from my notes in my skeleton secure bash template):
1. Minimize secret lifetime: Use subshells, functions with local variables, and unset, disable bash history
2. Pipe secrets directly: Pass secrets via stdin or process substitution directly to the consuming program without intermediate variables if possible.
3. Rely on the tools: Use pass, gpg, or KMS CLIs that are themselves implemented in lower-level languages and can (and should) implement these memory protection techniques internally.
Pass is great, but GPG keys are complicated and add a lot of extra overhead if you don't have one already. Frankly I cannot recommend anyone use GPG today for any purpose. I wrote a much simpler CLI password manager instead that meets explicit security models.
> Notably, pass fails both of these requirements, ... , and the files themselves do not use authenticated encryption.
With pass you can turn authentication on by setting an option to sign the files by default. That comes at the cost of requiring an extra entry of the passphrase so most do not turn this on. Few people are concerned with the idea that an attacker might modify their passwords so they don't work. There is no real benefit to an attacker. They could just delete the files.
Even if signatures are not turned on the regular PGP integrity protection would still be in effect so in the unlikely event that an attacker changed the file an error would be generated and presumably passed on to the user.
This article goes into some of the deficiencies of using GPG with pass. In particular, GPG uses asymmetric keys, so someone could encrypt a new password file with your public key and you wouldn't know.
Yes, that is specifically what enabling signatures prevents. You would know when the stored password stopped working and the content of the rest of the file changed.
That article is fairly rough. For one thing it references "The PGP Problem":
Yes signatures would prevent that, but as you noted it isn't enabled by default so most people don't use it. Optional security features don't count in my book :)
For the rebuttal you posted, I'll respond to one thing:
> The entire rant is basically about how OpenPGP is old and therefore bad and how new things, sometimes only vaguely defined, are good. So let's address this first.
> If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument. You would be unlikely to demand a newer design. Normally old designs that have stood the test of time are valued. Cryptography is based on mathematical/logical principles. Such principles don't age out on any sort of a schedule and are valued in some cases for thousands of years.
The "unbreached for the last 20 years" conclusion about mechanical security systems does not immediately apply to mathematical ones, and we can indeed see that it is empirically incorrect. The cryptographic world is littered with the corpses of cryptographic algorithms that were secure for decades and are now broken (MD5, SHA1, DES, small RSA keys, TLS 1.0), and their C implementations that had horrible vulnerabilities (HeartBleed, etc). Mathematical proofs will not help us here either, since e.g. there is no proof that GPG is IND-CCA. (Which is unlike new systems, which do have proofs!) GPG had its day, and now it should be retired.
Also, the quantum threat is a reasonable one in the "store now, decrypt later" model. A lot of people presumably use git to store their password store online and would be vulnerable to this. The passwords in the files would probably not be important anymore once quantum computers are created, but any other long term data or other personal information that people store in there could be decrypted.
Well yes but this is also a feature: you can store passwords without having the private key available. That can be handy.
I don't really see the value in an attacker being able to store new passwords anyway. Besides, in order to do that they'd already have to have breached my private git server too.
This is interesting. But does this program have some model or approach for using it in several devices? Is the database syncable in some way, or would you need to remote in to the master location to run it?
For use with multiple devices you can copy the database file to each of them, a smarter approach using syncing is very complicated and not one I considered here.
What i love in particular is the combination with OpenPGP keys on a yubikey. Because of this you have two factor and more importantly, you unlock each password individually. This way an attacker can't steal your entire database of passwords even if they have full control over your computer. They can only see the passwords you unlocked. Because each password requires a physical touch on the yubikey.
With some other community favourites like keepass and bitwarden, once your database is unlocked, all the data is open..
If only chip makers and computer manufacturers could agree on some useful common interface for managing keys so we could get more people to use these solutions.
No please, I don't want my keys locked into Google or Apple. They can block your account on a whim with no recourse. At least bit warden can do it now but the fido association seems to have beef with them because it's possible to extract the private key. This is exactly what I want though, to store it somewhere safe.
But for now I simply don't use passkeys. It needs to be 100% open and cloud independent.
I was talking about availability of hardware capabilities. And having a common interface to them so they are actually useful. Several of the machines I work on have a SAM, TPM, HSM chip or similar. But they’re not always present and they don’t necessarily have nice interfaces that makes writing software that works everywhere easy.
These are all running proprietary software that you can't upgrade. As an example, Yubikey had a bug a while ago where they were generating weak keys, which could be recreated from a bunch of signatures.
How would you build a dead man’s switch for pass?
I’d like my family to be able to access my store if I disappear, but not before. The obvious problem: to re-encrypt for their keys I’d need my private GPG key running somewhere, which defeats the point. Has anyone solved this cleanly without leaving a hot key around?
The beauty of pass is that there's a distinction between giving access to the encrypted vault vs giving access to decryption, and you can leverage this.
How I've been doing this is that I have 2 (sets of) backup people. The first set has access to the repo, but can't decrypt. The second set can decrypt (i.e. I have their pubkeys imported), but don't have access to the repo. I've chosen the people such that it's unlikely they collude against me, but in case something happens it's likely they'll be able to get in touch with each other.
There's also other possible approaches: e.g. instead of building a dead man's switch based on the encryption, you can build a dead man's switch based on the data. I.e. you'll use their pubkeys for encryption, but the repo itself is behind a dead man's switch.
key sharding with a trusted third party? computer systems can't know of your death, or even true time, so you have to trust something like a company holding the secrets for you, or your lawyer...
On MacOS, I tried using the Password App for passwords, but there is no cli to access it in scripts.
The keychain is accessible with a cli, but is not very nice to work with. Which is a bit sad, because being able to use touchid when running a script or signing commits would be nice.
Life saver! New version lacks OpenKeychain integration (they discuss in issues that it is also no longer maintained). Abandoned version of Android Password Store had some issues with embedded PGP manager and was not working for me.
But this fork works!
Best practice question for syncing pass across devices:
Since exporting and re-importing the private key to a phone seems risky, is the recommended approach to generate a separate GPG key pair on the mobile device and re-encrypt secrets to it?
I have a different pubkey per device. I store all the pubkeys in the pass repo, and have a shell script to re-encrypt everything with those keys. So when I add a new device, I just need to add its pubkey, and then re-encrypt on an existing device.
GPG is a big detractor, at least for me. Working with the GPG agent is usually a subpar, if not outright confusing, experience. I’d happily take a version that uses ssh-agent instead to achieve the same.
Pass might work if you really like terminals and only use computers with a Unix-like OS. But if you use a phone, or Windows, pass is just too clunky to use.
pass is easier for me - it enforces some reasonable structure, works well with other Unix tools, and has a built-in git support. You don't have to use "pass" command for everything, for example for getting passwords interactively I just combine fzf and gpg directly.
If encrypted file works for you, that's great! But thinks like syncing it across devices, accessing entries programmatically, a mobile app all require rolling something on your own - pass solves this for you (while still being very simple).
Bitwarden has a desktop GUI app as well as an official CLI. If you're comfortable with it, there are also community ones like https://github.com/doy/rbw
What kind of mobile functionality were you looking for? The (unofficial) iOS app is pretty good IMHO and integrates with iOS’s OS-level password filling, and also supports the pass-otp plugin’s format for 2fa codes if you use that plugin. There was a decent Android client I used a while back as well, though I don’t recall the name.
Not the parent, but dwindling yubikey support (for gpg key storage) is an issue, had to pull out a legacy version on Android for it to keep working (they changed the underlying crypto library and lost the support there)
No ipad version I've found supports yubikey either
- what if some site has weird password requirements and the derived password doesn’t work
- what if a site gets hacked and you need to rotate one password.
If you have to store data per-site anyway because of those cases, may as well just store passwords. You can (and should) still generate extremely high entropy passwords.
Additionally, you can store other data for example one could have scans of important documents that are stored in Pass which means they are GPG encrypted and backed by a git repository so they are versioned and shared across multiple machines.
- if your secret leaks and you don't know it (or you do know, but you need some time to change it), the attacker not only gets the snapshot of your password manager but also can derive all future passwords you'll generate, or past ones you long forgot about
- there's no way to know what you've entered before, since it's stateless. With data stored in a manager, I know what username I used and can associate other data. If your uniqueifying input is the domain, and let's say HN would become hn.yc or whatever and you visit it again in ten years, you'd have to remember that hn.yc accepts the password of what you entered as news.ycombinator.com
I have to admit though, hash(name+secret)=password is so simple and beautiful that it draws IT people like a fine artwork draws visitors. But for me, that doesn't outweigh the practical issues
Not all sites are safe, either by design or by people running them. Having a common secret+service name as password AND having at least one of those sites leaking your plaintext password could mean that your derivation may go public and all your other passwords and services fall because of that.
presumably the derivation would involve a cryptographically secure, non-reversible function so as to not compromise the secret should one of them be leaked.
There's a ton of positivity here, but on the balance there are some significant issues with pass that I think bear mention:
- The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in.
- `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
- It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc.
- The name makes it nearly impossible to search for
I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth
> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc.
pass sets up a .gitattributes and configures git to convert gpg files to text via a custom driver. This enables a text-diff of the encrypted contents out of the box (at least for a store I've just set up to test this).
Thank you ! It was missed in my .git/config, probably because it expects gpg2, and my installation only has gpg. No diff works correctly!
Eek doesn't this create a security hole? Or are those diffs gpg encrypted?
Other significant issues I've had with `pass`:
- Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...
- Hard to install if not packaged. I tried to install `pass` on a headless NAS, but it required gpg, which looked hard to cross-compile to aarch64.
- `pass` is a light interface over `gpg`. So it has all the problems of GPG – I've had a few annoyances with `gpg-agent`. Many organizations are trying to ditch GnuPG and switch to simpler and better cryptography tools, like age. https://github.com/FiloSottile/age
- Android with `pass` was a bad experience. The official package was unmaintained. The fork was not packaged in F-Droid. The UI was cumbersome.
I still use pass, for lack of an obviously better universal solution. There's FiloSottile/passage for minimal change, just replacing gpg with age, but no Android. A better alternative would be gopass, which is portable across all unixes, is compatible with `pass` and has an age plugin. But still no Android packaging. https://www.gopass.pw
> - Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory...
What do you mean? I copy my repo to new computers by just copying .password-store and I've never had a problem.
Isn't it just a git directory?
You should just `git clone that`.
If you move to age you will lose hardware backing though. No yubikey. That's the main attraction for me.
For the structure I "solved" that problem by creating folders with three main files:
Sometimes I add "/notes" with unstructured text contents, and for a few special cases I created a file "/json" with some machine-readable things in JSON format.It's not perfect, and I do dislike the way that the metadata isn't encrypted, but on the whole I'm happy with the solution.
Yeah sure, but then are the conventions you came up with shared by all the tools in the ecosystem too (ex: browserpass)? Since the keystone (pass) declined to provide strong guidance, you end up with fragmentation and incompatibility.
I view this as a feature.
Yeah, but that's just your convention. I, for example, store password in
private/foo.com/foo-com-login
The first line of that file is password, the rest are optional notes. I think using first line for password and the rest for metadata was intended originally.
I love pass, but I agree that it would be nice to have an established standard of where to put username etc.
> - The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in.
Fair, but you can use your own conventions.
> - `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
Just split it into `site/pass`, `site/secret-question`, etc. The fact that it's just using a directory tree is quite nice.
> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful
`git diff` would be an odd command to run on generated passwords even without encryption. What matters is that you know when the last change was for a password or site with `git log <file/dir>`, and you can just `git checkout -d <old commit sha>` if needed.
> - The name makes it nearly impossible to search for
in the terminal `$ pass` typically suggests the associated package.
I assume they mean "search the web for", which is definitely a problem I've faced in the passt.
`pass git diff` decrypts the passwords for me.
"pass generate" has a -i flag to only replace the password in a file (assumed to be the first line)
There is an established convention for usernames, which is to put "user:" at the start of the line. It can't be the first line of the file but is otherwise not order dependent. The browser plugins and android app implement this and do autofill based on it. That is suggested on the main site.
If you blat your password with generate, it can be recovered because it is in git. A nice to have for pass might be a flag to autoinsert only on the first line, but in lieu of that, pwgen should do the job and is what pass uses under the hood.
> I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth
> stored in encrypted sqlite3
you had me at encrypted sqlite3. it would be great if you mention in readme that it uses SQLCipher
There is a bit of structure imposed if you want to use the provided automation for inserting passwords in the clipboard. The password comes as the first line. Then you are going to end up with the user name on the second line. Everything past that point is gloriously unstructured. I have a pass entry floating around here with an entire onboarding email in it...
You have to love how this whole thread embodies Cunningham's Law
https://en.wikipedia.org/wiki/Ward_Cunningham#%22Cunningham'...
For me the unstructured data is a big bonus. And it's not really unstructured. You can put Username: xxx and browser plugins like browserpass will pick that up.
> I've been working on something similar...
but this is not a shell script...
Browser password managers with passkeys are more convenient for me, but a pass vault can still be useful for recovery codes and API keys.
I used pass for a while but couldn’t see what threat model it actually solves:
If you let GPG agent cache your key, any script (e.g. an npm post-install) can just run `pass ls` or `pass my/secrets` and dump all your credentials. At that point it’s basically just full-disk encryption with extra steps—might as well keep everything in ~/passwords.txt.
If you don’t cache the key, you’re forced to type your long GPG password every single time you need a secret.
I tried a YubiKey for on-demand unlocking, but the integration is clunky and plugging it in constantly is a pain if you need passwords multiple times per hour.
I eventually switched to Bitwarden.
That’s true for any password manager. If the database/store is unlocked (so the master password is cached or available in RAM), all passwords can be extracted. You have to lock the password manager when you don’t need it.
In fact, with Bitwarden, the cached password is exposed to the browser that has a large attack surface (including interacting with random remote servers). There was just a vulnerability in most browser based password managers including Bitwarden that would allow a remote attacker trick a user send out their passwords.
I use Bitwarden but mostly for non-critical passwords.
Doesn't good 2factor minimize a large attack surface like this?
I like the idea of storing password data in individual encrypted files and using git to store changes, but I wonder if it creates more friction to retrive the information. I havent tried this solution yet. I will when I get more time. It seems like this solution would benefit from a more standardized specification for storing and retrieving information. I known its not every persons cup of tea, but maybe some kind of separated add-on for streamlining this process could be beneficial.
>That’s true for any password manager
Modern operating systems isolate individual apps such that a malicous app can not access the RAM of another app. There is a difference between not making an effort to protect passwords and requiring an OS exploit to do so.
Memory isolation doesn't really help, though. If you have a malicious process running under the same user account as your password manager, it's still game over since that process could e.g.
- capture keyboard input - capture your screen - silently install browser extensions to capture your credentials - modify your shell config, .desktop files, $PATH, … to have you e.g. call a backdoored version of your password manager, or put a modified version of sudo on your $PATH that logs your password (=> root access => full memory access) - …
You can use Qubes OS for true VM-level isolation, or use hardware security keys where possible, or run sensitive applications in dedicated VMs.
I think that in general it is game over the moment you have malicious processes running. I use firejail for most applications, which I believe is the bare minimum, or bubblewrap.
Yeah. Personally, I'm crossing my fingers for SpectrumOS[0] to make things a bit easier. As the developer notes on her website[1]:
[0]: https://spectrum-os.org/[1]: https://alyssa.is/about/
What else can you tell me about Spectrum OS? Is it actively maintained? Is it usable? How does it compare to Qubes OS?
Also what do you think about Subgraph OS[1]? Although I think it is not maintained anymore, or is it?
[1] https://subgraph.com/img/sgos.png (old image which I remembered it by) (https://web.archive.org/web/20241206072718/https://subgraph....)
I don't know how usable SpectrumOS is so far – I guess we'd have to compile it ourselves in order to find out. Either way, it is being developed quite actively, see https://spectrum-os.org/git/
As for how it compares to Qubes, I don't think I'll be able to tell you more than https://spectrum-os.org/design.html & friends. I suppose the upshot is:
- KVM instead of Xen
- One VM per application
- Single file system for user data (to which users can grant VMs access on a folder-by-folder basis)
- Package system from NixOS (nixpkgs) for reproducibility & immutability
Ugghh, once again I forgot that HN removes line breaks unless you use double line breaks or indent by 2 spaces, and now it's too late to edit my comment.
@dang People keep running into this. (See e.g. this comment[0] from a few days ago.) It also makes it rather awkward to write lists IMO. What's the reason for removing line breaks and could this be changed?
[0]: https://news.ycombinator.com/item?id=44946386
For modern operating systems capturing keyboard input is locked down to avoid keyloggers. Capturing your screen requires explicit user permission to do so, popping up a dialog. Apps are isolated so another app can't interfere and install a browser extention or modify shell configs, etc.
And modern operating systems are being … ? macOS, I assume?
Can you name one of these modern operating systems?
iOS is a modern operating system.
It's also impossible to use it for anything productive.
The OS protections apply to all applications. In addition, the job of agents like gpg-agent or ssh-agent is to protect secret keys while they are cached (like preventing OS writing keys to swaps). You can configure them to erase keys after a certain time, require user’s confirmation for each key operation, store gpg keys in internal TPM or external hsm, and would talk to the agent through specific sockets.
Unlike browser-based password managers, the agents don’t continuously interact with the browser code and remote elements (probably don’t have network access at all).
One area that matters that I forgot to mention in my comment below is that, as a result of all above, Pass doesn’t check the domains and doesn’t protect against phishing. There might be extensions, but at that point, you might as well use keepassxc.
I just leave my yubi plugged in. It requires a physical touch anyway (at least you can configure it for that which I have). And my place is physically secure.
The good thing also is that unlike with fido2 you only have to enter the pin once for OpenPGP. Then it stays unlocked while it's plugged in. But still needs the physical touch for every password. Perfect and convenient for me.
It also works great on mobile with openkeychain and password store. Both are not really maintained now but I don't really care because the encryption is in hardware anyway (yubikey over nfc)
I store my passwords on an encrypted file partition sqlite database. My script grabs the pass and immediately closes the partition afterwards.
You can also just encrypt your passwords into individual encrypted files (one for each password) and have your script clear the gpg agent after a passfile is decrypted.
If you can spare a USB port you can use one of their Nano keys that just stays plugged in.
Even if someone/malware was to steal my yubikey pin they'd still need to convince me to tap the thing over 1,000 times to steal all my passwords.
I can't remember how but pass for me works in brave browser and Firefox, as well as on mobile. It's my only password manager. I'm assuming some browser plugin.
> a pass vault can still be useful for recovery codes and API keys
You might already be aware of this, but Bitwarden also has a CLI client that can be used for this purpose, at least casually.
And can run a local webserver to expose an API (though they still need to tighten up security on it)
You can configure the yubikey to need a PIN and/or touch to authorise the use a GPG key.
My main issue with pass is that it doesn’t work great on iOS with yubikeys.
Is the biometrics step (fingerprint reader) on macOS much different from a ubikey? I imagine implementation may have some differences, but in practice it seems I can already protect access to my GPG key using the built-in reader, so what’s the advantage of ubikey in that respect? Genuinely curious.
The TouchID is bound to a device - of course, I could copy my secret into a secure enclave that is only accessible through TouchID. Could even just store my GPG key there. With a Yubikey, I generate the key on an airgapped device and store it on the Yubikey. No other piece of hardware ever needs to see my secret key in plaintext. I could achieve the same with TouchID, generate the secret key inside the enclave, but then I cannot move the secret keys out without some other computer baring witness to that.
I really do not want to give Apple any more leverage over me, I'm looking to minimize it.
Is bitwarden in some way able to protect passwords while still being unlocked?
it took a while to get it to work well, but I use yubikey here, and recommend it. I do need to find and pulg it in sometimes, but overall might leave it plugged in. and I have it configured to require a touch for every operation
This is interesting for CLI lovers, but I feel KeepassXC on desktop + KeepassDX on Android (with the password DB stored on my own machine and accessed remotely via Wireguard) is a better solution for normies.
keepass has a very underrated feature i never see much talk about where you can have multiple vaults and have them open and search both at the same time (or at least the two apps you mentioned support that anyway).
most password managers are based around the idea of one single vault which creates the problem of having to treat every password like it needs the maximum amount of security. in my own case i would guess maybe 70% of my passwords are for unimportant sites where it wouldnt be a huge issue if someone else got the credentials, but every time i need to log into one of those sites i need to enter my long master password.
with keepass i can put that 70% into a separate vault and use a shorter master password that is quicker to type, and i dont need to worry as much if im opening that vault on a computer where i might not be sure its completely secure
Also, KeepassXC and OG KeePass with a plugin can auto-open another vault from an entry in the primary vault. This works well if you have the more secure vault open a less secure vault, or in my case open a shared vault used for common passwords off a network share at work.
I also preach the tiered password security model. For the common, frequently used passwords that don't need max security, I just use the browser store (with a copy in KP).
Pass actually has a similar feature: different directories in your git repo can have different gpg keys, effectively doing the same thing you like.
I keep a Keepass vault with my 2FA secrets and a separate one with my passwords. This reduces the biggest fear I have where one compromise reveals everything.
These are both offline backups of my Bitwarden, which is my daily driver. Bitwarden doesn't store any of my 2FA info though.
"Normies"? Everything is relative, I guess. I use 1Password and just hope for the best.
Right. Having an own machine 24/7 online and setting up wireguard to it does not sound very typical.
I use pass myself and I don't care about mobile. But I really don't know what to recommend family members.
I use pass also on my phone in combination with Termux. I keep the passwords stores in sync using git. pass on android also supports copying your password directly into the clipboard, which is especially nice on a mobile device.
My family members are all with iPhones, and their Passwords is very good. I only backup a couple of sensitive passwords to my pass store just in case. The rest of the passwords are basically disposable.
Don't forget keepassxc.cli, which allows you to programmatically set and retrieve secrets. The interface is significantly more user friendly arcane. I used it when I needed to build an encrypted secrets bundle (so that one long password could temporarily unlock some API keys required for a disaster-recovery situation.) I was able to generate a single file plus a "Makefile" to unlock it and pass the keys into the appropriate environments.
I had attempted to use GNU `pass' first, but sadly, it requires me to manage gnupg, which is a well known minefield of poor default options, and assumes it should be integrated into your shell by storing things in your user profile directory (instead of using the directory relative to where you call it.) This jeopardized my copy-one-file workflow, so despite its ubiquity I had to abandon it.
The only use case of mine that's not solved by keepass is creating passwords on two separate machines without a direct connection, and merging them later.
I solve this by Syncthing running on all clients. Very rarely do I ever have a problem with conflicts. Only if I add a new pass while my phone is offline and then make another edit on my computer would there be an issue. I think it only happened once, and that was because I did it on purpose to see what happened.
Turns out syncthing creates a .conflict file and then I tell keepassxc to do a merge on the two files and then we are back to normal.
Any particular reason for remote access via wg and not via syncthing? I'm also curious how you access it via wg on Android?
I already use WG to access other services running on my LAN. The DB is on a Samba share, and I use KeePassDX as a client on my phone (GrapheneOS).
I would love to use KeepassXC but it doesn't make it easy to share credentials with the wife. I _could_ use a dedicated vault, but we'll then need to cut-paste things for sharing existing credentials.
So, for now, I've settled on Vaultwarden and it has been surprisingly stable so far.
Shameless plug. I built a tool[1] to manage Keepass archives in the terminal which might scratch some of the itches I am reading here: it has a TUI, but can be piped into other commands too.
[1]: https://github.com/shikaan/keydex
FYI for desktop there is a "passmenu" script that you can bind to a key in your DE/WM.
Im thinking of trying this, I just used local files until now with keepass. in my case a synology nas to hold the file, a two bay equipped with 2.5" ssd that i already use for notes, music, and other stuff + wg
This is fun if you never leave yourself, but be wary with whom you share it. As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly. (Or none, if you can't be bothered.) (Don't ask.)
Or if someone newly needs access, there's no standard way of re-encrypting the files you're guessing they need. You need to hack something together yourself
It uses git, but the commit messages are autogenerated and useless. It might as well have used Dropbox for all the use you get out of it when wanting to find the version before someone corrupted data with their somehow-broken gopass client
There is no way to ever erase anything you've accidentally pushed, short of rewriting the git history and breaking it for everyone (or for personal use: other client devices)
It looks nice and simple, and I like that I can interface with it with manual tools (e.g. write my own commit messages to have some idea of wtf is going on, e.g. when mass-reencrypting to not have 300 commits), but the simplicity is also the pitfall. Feels a bit similar to using hash(site_name+main_password) as a per-site password: beautiful in simplicity but various practical issues
Does anyone have good experiences with a password manager for a corporate environment? Ideally not having yet-another service to maintain, but also not have a server compromise equal business compromise (so end-to-end encryption between the users; verifying fingerprints or some such). From what I found so far, Bitwarden seems to meet that bill but I don't know if there are also others
> As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly.
You can setup different directories to use different keys, and you don't need to limit yourself to a single key for each password either. You can use multiple. So you can setup structures like:
- admins/.gpg-id "admin\n"
- techs/.gpg-id "admin\ntech\n"
where admin and tech are 2 keys for different groups of people. Admin having more access. Or even better:
- site_foo/.gpg-id "bob\nalice\n"
- site_bar/.gpg-id "bob\nrobert\n"
where each employee has their own key. So you can fine-tune which passwords need changing if an employee leaves, and which passwords an individual employee needs to be able to access.
You can setup git submodules to control which passwords which employees can know to exist.
And given that git is being used, you can know which passwords an individual employee ever had access to, were their access to change over time.
"having access to" is not the same as having opened it, though. A server could log which files were retrieved without knowing what the contents are
By having such audit logging, we could see that we e.g. don't need to call the alarm company to change the phone password. Most people don't work in the office outside of business hours and so never need to call them, but since it's the only way of proving you're an employee if you accidentally set off the alarm, we give everyone access to that password. There's at least a dozen examples like that
I have no practical experience yet, but i evaluated the market for a password sharing solution for a team with similar requirements within an enterprise.
Another option in that area is https://www.passbolt.com/
It uses a public/private key approach, where the plain passwords never leave the local machine and shared passwords are re-encrypted with each users public key.
My current employer uses 1password and it has a couple of nifty features like "vaults" shared with a group of people, an "op run" command to inject secrets using a .env file, service accounts to fetch passwords in CI, etc.
It has dev environments now too! https://developer.1password.com/docs/environments/
Sounded nice, but I'm not sure what this actually adds. I'm currently using 1Password for doing "environments", but it's all using the existing `op` CLI.
So adding a new collaborator to the project would involve adding them to the vault, then there is a shell script in the project that uses the CLI to write a new `.env` depending on the values from `op`.
Seems like this new environment stuff wouldn't add anything compared to such setup, at least today, is that fair? Seems to be even more manual and require copy-pasting, unless I misunderstand what the feature actually is.
Yeah, I think the idea is instead of writing a .env you would, perhaps eventually, have a command like op that just loads the environment whole cloth. But you probably won't get much value out of that today.
for a complete solution to dev envs and production secret management I use Envie https://github.com/ilmari-h/envie it's like a drop in replacement for traditional env files
Bitwarden is pretty usable, we use it at our org, and while still has a rough edge or two for corporate use, gets better all the time.
My and my buddy have been using “pa” for our company with great success: https://git.j3s.sh/pa
It uses age and allows you to use multiple keys for encryption
I think one could build something nice on top of FOKS (https://foks.pub).
I agree
There's also the pass-otp extension that generates OTPs!
https://github.com/tadfisher/pass-otp
The pass android app is really nice too
https://play.google.com/store/apps/details?id=dev.msfjarvis....
It also works in termux
The Android Password Store application by msfjarvis was archived last year. It was forked and greatly updated by agrahn. There are APKs on GitHub Releases and F-Droid, but not Google Play Store.
https://github.com/agrahn/Android-Password-Store
Thank you for sharing. My solution has been to dump small scripts like this in ~/bin:
> This app isn't available for your device because it was made for an older version of Android.
And no, those apps don't work great, because they involve some clunky GPG app.
The app in the Google Store is no longer maintained, hence the warning.
It is however available in F-droid [1], and the newer versions don't need the secondary app and do everything internally.
[1]: https://f-droid.org/packages/app.passwordstore.agrahn
Agreed, GPG is not the most intuitive tool, but once you are familiar enough with it, it opens some doors.
For me termux and pass (from F-droid) have solved my password management for many years. I never have to struggle finding passwords. The security aspect of it is the least I care about, it's the convenience and simplicity of it.
Since the passwords are all just files on a disk inside a directory tree, you can use any old file system tools to find your passwords. Same for MFA. I store the base32 string inside pass and that's the end of it.
If you are using age instead of GPG for encryption purposes, I've found this to be useful: https://github.com/FiloSottile/passage
There are also other pass-like password managers that use age. The developer of one has made a comparison table: https://gitlab.com/retirement-home/seniorpw/-/tree/02dc02d1e.... (Disclosure: pago in the table is mine.)
I recently moved away from pass after a decade or so.
Two main reasons:
1. This laptop up was set up with flatpak versions of all GUI applications, including Firefox, and the browser plugin just doesn't work. I persisted with the work-around of `pass -c <path>` from the run command prompt for a while to paste into the browser, but its not ideal.
2. I realised that the Android app was archived. There's at least one fork, but who knows how that will be maintained going forward. https://github.com/android-password-store/Android-Password-S...
For now I'm content with hosting vaultwarden and using various Bitwarden clients.
I made the switch from pass recently too. I had ~400 secrets stored in it for almost the same time as you.
Ultimately I wanted something easier to sync between multiple devices. Now that I am traveling more seriously I can't get away with only having a few important passwords saved on my phone and laptop.
It was a lot easier to sync (1) file with KeePassXC and it has 2 well supported Android apps to choose from. It took me around 3 hours one day to manually move everything over, I took that as an opportunity to prune and refactor everything which is why I didn't use the CSV import feature.
Password managers for me are a "write occasionally, read frequently" app so it's pretty painless to shoot over 1 file over my local network to keep 3 devices in sync.
That's curious. I moved from KeePassXC to pass precisely because the synchronization story for the database file wasn't working so well. For too many times I ended up with an outdated database in the backend server because the sync process failed to work properly.
After I moved to pass, every credential became its own file and I rarely edited the same credential in way too many devices. For the rare conflicts I had, having it being Git made it possible to resolve them without massive hassle.
Then again, that was also some many years ago. Maybe the synchronization story is better these days.
I didn't like the idea of pushing a pass git repo to a private GitHub repo.
For now I just temporarily drop the DB onto Google Drive manually (through the web site since I don't use the app) to quickly share it to the other devices without worrying about USB cables or running native apps on each device. Then I delete it from Google Drive.
I'm hesitent to use "sync" type of tools that run on each device because I don't have a central server. Also I really don't like the idea of running any type of cloud hosted network storage desktop app on each device to have a network drive.
We'll see how it goes I suppose.
I wonder if it'll involve writing a tiny shell script that I run on my desktop machine to handle syncing it across devices and it always ensures the latest copy makes its way onto each device. That would allow me to freely add new entries on any device and worry about syncing it across devices when I am 100% sure all devices are on the same local network. I think that will work out in the end.
I don't need real-time replication because if I'm on the road using my phone, I don't mind my desktop being outdated until I get back home.
> I didn't like the idea of pushing a pass git repo to a private GitHub repo.
I had the same reluctance at first, but after considering it was protected both with my gpg key and my passphrase, and private on top of that, I came to the conclusion it is fine for me. It feels assuring to have it in a remote location where it is safe if I have burglary or fire or an accident like that. My keys are in a few secure locations too
I would never upload it to GitHub either even though it's encrypted. It still leaks the metadata. And I don't believe in cloud anyway.
I just set up a simple git server in docker for it. Takes almost no resources.
KeepassXC combined with Syncthing is enough for me too.
I've been using this combo since many years and it's been working flawlessly across: 2 mobile phones, 2 laptops, 1 Synology server.
> I persisted with the work-around of `pass -c <path>` from the run command prompt for a while to paste into the browser, but its not ideal.
There's also `passmenu` that comes with `pass`. You setup a keybinding that calls that. It autocompletes your password selection with a menu (calls dmenu) and puts it on your clipboard. You skip having to invoke the command prompt then manually calling `pass -c` and writing the path.
Well shit, I didn't realize the Android app was shelved. I checked out the fork and it looks like they're doing good work there. I'm a bit surprised that the maintainers of both didn't work out a transfer; who else better to take over the project than a active fork?
Makes me wonder if something else was the issue, such as disagreeing over security practices or the like.
> I persisted with the work-around of `pass -c <path>` from the run command prompt for a while to paste into the browser, but its not ideal.
I actually do this on purpose. The last time I checked into the plugin, it looked like it unlocked your gpg key at Firefox launch rather than at password prompt time. Also, I didn't like the fact that the plugin creator could simply send my passwords to themselves without my knowledge. Firefox and pass are big/trusted enough to not do this. But some random guy? That was outside my risk tolerance.
How has it been working for you so far?
I'm in a similar situation and considering doing the same thing as you, for the same reasons, but I'm curious about how the offline experience is.
I'm often facing periods of bad to no connectivity, and I find the ability to lookup or even update a credential offline very useful. Not sure how much of it is possible with Vaulwarden and I couldn't find the time to try it yet.
Happy pass user for ~8 years now, have ~1300 passwords stored. No issues whatsoever. Use git to sync it across devices, totally awesome.
How do you have 1300 passwords? Sounds like a lot. Come to think of it though, I have no idea how many I have.
I have ~1300 items in my 1password vault too. Seems normal
Another anecdote: Started using a password manager in 2017 (8 years) and today I have 520 credentials, using it for everything from my normal accounts to environment variables, configuration and a bunch of other stuff. Only thing I handle myself outside of it is ssh and GPG keys.
I checked, also just over a thousand. So it seems normal, in the same order.
Interesting. I have 165 total. Could be because I use Google oAuth whenever it's available.
I like pass and use it a lot, especially as it provides a good and safe backup for the case my vaultwarden instance goes up in smokes.
There is also a drop-in replacement with has some extra features and a bit better UX in some parts, personally I only really use it for the better support for handling multiple GPG keys, as I got some physical backup keys and it can be also nice teams for a shared vault.
https://www.gopass.pw/
https://github.com/gopasspw/gopass
Pass is still amazing after all these years. Shameless self plug: I wrote a gnome search provider for it so you can lookup passwords from the overview. Supports OTP as well. https://github.com/Fingel/ripasso-gnome-search-provider
I have heavily used Pass over the years. Here are some of its pros (an update to my comment several years ago):
* Your secret key can be stored in Yubikey, handled by a dedicated OpenPGP agent. This allows deriving a strong key from a weak one. Your password is basically a short PIN with max 3 tries. Every password retrieval can require a physical touch. This is convenient and secure!
Pass makes sense if you use it with a hardware key, with touch enabled. With this setup, it’s hard to beat its security.
* It uses public key cryptography, and comes with its advantages. You don’t need your master password to add/encrypt passwords. You only need that for decryption. Less exposure of master key, and more convenience.
For that reason, it’s well suited to share passwords with other people or devices. You can encrypt to multiple public keys. This adds multi user and device support.
You can easily add a backup offline public key (which you may print) if you lose your Yubikey.
* You can decrypt a single password without decrypting and exposing other passwords. The passwords are isolated, if you use Yubikey.
* Searching passwords is quick and transparent. You easily see what is in your store.
* You can use it programmatically, eg, your backup script can grab a password from the store.
* It’s a short bash script that you can verify, and delegates encryption to a dedicated well-audited cryptographic tool.
* PGP is a standard, and GPG and git are widely available. There is no database to break or migrate. You can read your passwords anywhere and in the future.
* The script is written by the creator of the acclaimed Wireguard!
There are also cons.
* Some people don’t like that it leaks metadata (filenames, and password tree), though there are versions of pass that fix it.
* Lately gpg is causing some troubles with Debian Trixie. GPG agent frequently locks the Yubikey and requires restarting pcscd (probably due to conflicts with pcscd). There is a similar tool Passage using Age, maybe that solves it.
* There are mobile apps, but they are not as frequently updated as something like Bitwarden apps (which has client for every OS, and frequently fixes bugs and adds functionality).
* I haven’t used and not sure how good browser support is.
Here is a post on a similar password management with GPG replaced with Age
https://words.filippo.io/passage/
About mobile app, I never used pass until today, but it seems great, and so far I only tested it by installing it on my phone in Termux. Can't think of a reason for me to use a special app when running it in Termux works so well. Was happily surprised that even pass show -g worked out of the box, copying output to Android clipboard.
That is also nice since I have ssh already set up so syncing to my computer from the phone will be easy.
Any recs for yubikey setup guides with pass?
Nothing specific to pass. It’s just Yubikey setup with GPG; that’s part of the appeal!
https://github.com/drduh/YubiKey-Guide
This guide covers many adjacent topics; the relevant part is generating the secret key inside Yubikey, or in an airgapped system and doing “key-to-card” in gpg.
I used pass for many years and loved it. I sync'd my password store between 3+ devices including my Android phone using a git remote. I don't recall the exact reason - maybe the pass android client I had used for years went away? I decided to find the next best option and settled on keepassxc and KeePassDX. The backing store is a binary blob but it does surprisingly well via syncthing: autoupdate works and in the event of a conflict the db merge feature hasn't yet failed me.
Granted on the desktop I find using a (qt especially) GUI more invasive than a terminal but at least on the Android side the app is quite good.
I have a different approach I’ve used for about 10 years that I like a lot. All password metadata is stored in a plain JSON file indexed by name (usually site name). Each entry contains at the minimum a username. Optionally it has a version number and some password rules like the length (20 if absent) and the character classes that are allowed, along with how many of each character class are required. None of this data is sensitive, so if you look at the file you see my list of sites. The actual passwords are not stored, because my tool is actually a deterministic password generator, which prompts me for a passphrase and generates a password from the passphrase and a hash of all the metadata. One nice feature is that if I just change the version number I get a whole new password, and the “history” is still available by changing the version back.
The one major downside to it is that it is absolutely unusable for sharing passwords because obviously that would require sharing my passphrase, and there is no way to “store” a password that someone else set. I’ve thought about writing a mode that would encrypt a string (eg a shared password) with the metadata-generated password and store it in a separate piece of metadata for that purpose, but the number of times I’ve needed that has been extremely small.
I found the idea of a password generator appealing, mainly due to vault anxiety. I didn't (and still don't) like the idea that I can't access a resource without this precious vault. If I'm home with my tools, great. Otherwise, give me the right hash function, and I can MacGyver my way to PBKDF2 and generate my password.
However, once you introduce metadata (e.g., to deal with password rules), the idea loses most of its appeal. I wouldn't feel any more comfortable posting such a thing publicly than I would a vault.
The metadata doesn’t bother me at all. Anyone who wants to can read that I have a Seattle City Light account, that it’s password is v6, and that the password rules say it can have all alphanumeric characters and must have at least one of a weirdly narrow set of “special” characters. That information alone isn’t enough to get anywhere.
What could be considered more sensitive, if you cared, is usernames. Someone looking at my metadata would learn my hn username, for example. But I don’t really consider that “secret” info.
I've just discovered this two days ago from the SECUSO password generator: https://secuso.aifb.kit.edu/english/105.php
Initially I didn't get it, then I realized that it was using the deterministic password generation approach.
Offtopic: SECUSO has a really nice collection of open source apps.
Sharing passphrase becomes even bigger risk as now your surface area is larger as comprise will lead to many credentials bei g leaked.
Of course. This is absolutely never used for sharing. That’s why it’s called out as a drawback. When I need a shared credential, I’m forced to use a completely different mechanism. But this is pretty rare with good practices (which discourage shared credentials).
I've been doing basically this for many years now.
Each password file is AES-encrypted with my master password.
I copy the whole vault around between machines with rsync.
When I run 'password bank' a shell script searches ~/private/Passwords for files that contain ‘bank’ and offers a menu, then gpg-decrypts the file I selected.
I also use this for scans of my passport, recording my bank account numbers, and anything else I want to keep around.
I thought I was the only one, and now I've found out there are thousands of us!
I love it. It is so simple and flexible.
But a life saver is using it with <https://github.com/skeeto/passphrase2pgp>.
This means we don't need to move gpg/ssh keys we can just recreate them by remembering their passphrase (and other stuff like the date if we want).
I read a blog post for the above but can't remember what it was, but it's amazing now It's very easy to download and access the password-store from any devices, I use it in window, linux and termux.Funnily enough I never used `pass generate` once, even tough I have more than 3700 passwords. I always used the `pwgen` command, I don't know if there really is a big difference between the 2 (except pass generate being already in pass).
As for how to structure, here are some example of how I do it :
They are all only one line except some backup codes which use multiline.Then it's very easy to get the password or the otp, just bind `passmenu`, `passmenu-otp` in your window manager or directly use the command line for multiline stuff.
I recently did a deep dive on cli password management in an attempt to harden my bash scripts. (yes, I love bash, despite HN always loving to talk crap about it)
Pass is just a shell wrapper around gnupg, when you run pass some/secret/path, what actually happens is pass constructs and executes a gpg command (e.g., gpg --decrypt ~/.password-store/some/secret/path.gpg) and the output of gpg (the plaintext secret) is piped to pass's stdout.
Most people know this though. What I learned I didn't know before though was this:
Memory Zeroing: after it's used (e.g., copied to a pipe or stdout), GPG's internal memory management aims to zero out those memory regions used as soon as they are no longer needed
Memory Locking: GnuPG also uses mlock() (or equivalent OS-specific calls) to lock sensitive memory pages into RAM. This prevents the plaintext keys and decrypted data from being swapped out to disk, protecting against swap-file forensics or cold boot attacks.
I had been banging my head against bash trying to do those things manually, and ended up with the conclusion it was best to use pass/gpg with the following addendums (from my notes in my skeleton secure bash template):
1. Minimize secret lifetime: Use subshells, functions with local variables, and unset, disable bash history
2. Pipe secrets directly: Pass secrets via stdin or process substitution directly to the consuming program without intermediate variables if possible.
3. Rely on the tools: Use pass, gpg, or KMS CLIs that are themselves implemented in lower-level languages and can (and should) implement these memory protection techniques internally.
ps: keepassxc is the other favorite to use
Pass is great, but GPG keys are complicated and add a lot of extra overhead if you don't have one already. Frankly I cannot recommend anyone use GPG today for any purpose. I wrote a much simpler CLI password manager instead that meets explicit security models.
https://codeberg.org/jwgarber/napa/src/branch/main/database....
From the linked page:
> Notably, pass fails both of these requirements, ... , and the files themselves do not use authenticated encryption.
With pass you can turn authentication on by setting an option to sign the files by default. That comes at the cost of requiring an extra entry of the passphrase so most do not turn this on. Few people are concerned with the idea that an attacker might modify their passwords so they don't work. There is no real benefit to an attacker. They could just delete the files.
Even if signatures are not turned on the regular PGP integrity protection would still be in effect so in the unlikely event that an attacker changed the file an error would be generated and presumably passed on to the user.
This article goes into some of the deficiencies of using GPG with pass. In particular, GPG uses asymmetric keys, so someone could encrypt a new password file with your public key and you wouldn't know.
https://rot256.dev/post/pass/
Yes, that is specifically what enabling signatures prevents. You would know when the stored password stopped working and the content of the rest of the file changed.
That article is fairly rough. For one thing it references "The PGP Problem":
* https://articles.59.ca/doku.php?id=pgpfan:tpp
For another thing it references "the quantum threat against cryptography" as an actual argument against password store.
Yes signatures would prevent that, but as you noted it isn't enabled by default so most people don't use it. Optional security features don't count in my book :)
For the rebuttal you posted, I'll respond to one thing:
> The entire rant is basically about how OpenPGP is old and therefore bad and how new things, sometimes only vaguely defined, are good. So let's address this first.
> If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument. You would be unlikely to demand a newer design. Normally old designs that have stood the test of time are valued. Cryptography is based on mathematical/logical principles. Such principles don't age out on any sort of a schedule and are valued in some cases for thousands of years.
The "unbreached for the last 20 years" conclusion about mechanical security systems does not immediately apply to mathematical ones, and we can indeed see that it is empirically incorrect. The cryptographic world is littered with the corpses of cryptographic algorithms that were secure for decades and are now broken (MD5, SHA1, DES, small RSA keys, TLS 1.0), and their C implementations that had horrible vulnerabilities (HeartBleed, etc). Mathematical proofs will not help us here either, since e.g. there is no proof that GPG is IND-CCA. (Which is unlike new systems, which do have proofs!) GPG had its day, and now it should be retired.
Also, the quantum threat is a reasonable one in the "store now, decrypt later" model. A lot of people presumably use git to store their password store online and would be vulnerable to this. The passwords in the files would probably not be important anymore once quantum computers are created, but any other long term data or other personal information that people store in there could be decrypted.
Well yes but this is also a feature: you can store passwords without having the private key available. That can be handy.
I don't really see the value in an attacker being able to store new passwords anyway. Besides, in order to do that they'd already have to have breached my private git server too.
This is interesting. But does this program have some model or approach for using it in several devices? Is the database syncable in some way, or would you need to remote in to the master location to run it?
For use with multiple devices you can copy the database file to each of them, a smarter approach using syncing is very complicated and not one I considered here.
I love this one. I use it every day.
What i love in particular is the combination with OpenPGP keys on a yubikey. Because of this you have two factor and more importantly, you unlock each password individually. This way an attacker can't steal your entire database of passwords even if they have full control over your computer. They can only see the passwords you unlocked. Because each password requires a physical touch on the yubikey.
With some other community favourites like keepass and bitwarden, once your database is unlocked, all the data is open..
If only chip makers and computer manufacturers could agree on some useful common interface for managing keys so we could get more people to use these solutions.
No please, I don't want my keys locked into Google or Apple. They can block your account on a whim with no recourse. At least bit warden can do it now but the fido association seems to have beef with them because it's possible to extract the private key. This is exactly what I want though, to store it somewhere safe.
But for now I simply don't use passkeys. It needs to be 100% open and cloud independent.
I was talking about availability of hardware capabilities. And having a common interface to them so they are actually useful. Several of the machines I work on have a SAM, TPM, HSM chip or similar. But they’re not always present and they don’t necessarily have nice interfaces that makes writing software that works everywhere easy.
These are all running proprietary software that you can't upgrade. As an example, Yubikey had a bug a while ago where they were generating weak keys, which could be recreated from a bunch of signatures.
How would you build a dead man’s switch for pass? I’d like my family to be able to access my store if I disappear, but not before. The obvious problem: to re-encrypt for their keys I’d need my private GPG key running somewhere, which defeats the point. Has anyone solved this cleanly without leaving a hot key around?
The beauty of pass is that there's a distinction between giving access to the encrypted vault vs giving access to decryption, and you can leverage this.
How I've been doing this is that I have 2 (sets of) backup people. The first set has access to the repo, but can't decrypt. The second set can decrypt (i.e. I have their pubkeys imported), but don't have access to the repo. I've chosen the people such that it's unlikely they collude against me, but in case something happens it's likely they'll be able to get in touch with each other.
There's also other possible approaches: e.g. instead of building a dead man's switch based on the encryption, you can build a dead man's switch based on the data. I.e. you'll use their pubkeys for encryption, but the repo itself is behind a dead man's switch.
Thanks, I totally forgot about both sides; I only looked on the side of the key.
key sharding with a trusted third party? computer systems can't know of your death, or even true time, so you have to trust something like a company holding the secrets for you, or your lawyer...
Huh, I thought pass wasn't developed anymore for some reason. Glad to see it still is!
Related: https://github.com/gopasspw/gopass
I haven't used pass in a long time, but I used gopass for a while in a small team and it was pretty great.
On MacOS, I tried using the Password App for passwords, but there is no cli to access it in scripts.
The keychain is accessible with a cli, but is not very nice to work with. Which is a bit sad, because being able to use touchid when running a script or signing commits would be nice.
There is still no just-download clients for pass on mobile which I think is why it's not a good option
There’s one for Android, though it has been looking for a new maintainer for a while now: https://github.com/android-password-store/Android-Password-S...
Edit: looks like there’s a community fork now! https://github.com/agrahn/Android-Password-Store
Life saver! New version lacks OpenKeychain integration (they discuss in issues that it is also no longer maintained). Abandoned version of Android Password Store had some issues with embedded PGP manager and was not working for me. But this fork works!
I use it inside termux on android. There is a termux pass package. But it might be hard to input a complex decryption password on the phone keyboard.
I ssh in from my phone, which works pretty well.
Same
there is for iOS - passforios - https://apps.apple.com/us/app/pass-password-store/id12058205...
works great.
Best practice question for syncing pass across devices: Since exporting and re-importing the private key to a phone seems risky, is the recommended approach to generate a separate GPG key pair on the mobile device and re-encrypt secrets to it?
I have a different pubkey per device. I store all the pubkeys in the pass repo, and have a shell script to re-encrypt everything with those keys. So when I add a new device, I just need to add its pubkey, and then re-encrypt on an existing device.
I use yubikey over nfc with my phone. This way the private key material never reaches the phone.
Using the openkeychain app and password store.
I have multiple yubikeys as target for each password of course.
I have twelve ISBNs that I encrypt for passwords.
Depending on which genre, managing key-rings has element of physical security to encrypt signatures in terminal and bash shell.
For full disk encryption, genfstab and /boot/grub/grub.cfg should contain sigs for partitions.
GPG is a big detractor, at least for me. Working with the GPG agent is usually a subpar, if not outright confusing, experience. I’d happily take a version that uses ssh-agent instead to achieve the same.
Pass might work if you really like terminals and only use computers with a Unix-like OS. But if you use a phone, or Windows, pass is just too clunky to use.
I'm using pass on a phone with Termux.
Sure it's a bit clunky but it's been working since 2014 without any interrution or privacy leak. I can't say the same about most password manager.
The android "Password Store" app is okay'ish, integrates with accessibility API to offer auto fill in many apps.
It's perfect for me. And on windows and Linux I use QtPass and the browserpass plugin
I love Jason Donenfeld’s work, but I don’t really see the point of pass compared to using an encrypted text file, the latter being far more ergonomic.
pass is easier for me - it enforces some reasonable structure, works well with other Unix tools, and has a built-in git support. You don't have to use "pass" command for everything, for example for getting passwords interactively I just combine fzf and gpg directly.
If encrypted file works for you, that's great! But thinks like syncing it across devices, accessing entries programmatically, a mobile app all require rolling something on your own - pass solves this for you (while still being very simple).
This is very similar to the way my own jury-rigged password manager works. I didn't know there was an existing tool.
This is the wirgeuard dude. Jason is one of the GOATs
Growing tired of Bitwarden in the browser, so this is pretty intriguing. But its hard to forgo mobile compatibility.
Bitwarden has a desktop GUI app as well as an official CLI. If you're comfortable with it, there are also community ones like https://github.com/doy/rbw
No need to forego mobile if you're on iOS [1].
1. https://apps.apple.com/us/app/pass-password-store/id12058205...
This app wasn't working for me last time I tried it. Granted that was a few years ago.
For me it's working very well, now even using my own git remote in tailscale.
This app is keeping me on iOS as there is no single-app replacement on Android afaik.
If I were to go back to Android, I'd have to built the app first. Although I would built it with age support :)
Holy shit... this is dope as hell. Thank you
Try KeePassXC on desktop, KeePass2Android on mobile (there's something on iOS too).
There are some pass apps for Android, but they're a pain to use.
Combine pass with qtpass on osx and pass on iPhone and you’re golden
I use pass a good amount, but I wish there were better OS/mobile integrations.
What kind of mobile functionality were you looking for? The (unofficial) iOS app is pretty good IMHO and integrates with iOS’s OS-level password filling, and also supports the pass-otp plugin’s format for 2fa codes if you use that plugin. There was a decent Android client I used a while back as well, though I don’t recall the name.
[1]: https://apps.apple.com/us/app/pass-password-store/id12058205...
Not the parent, but dwindling yubikey support (for gpg key storage) is an issue, had to pull out a legacy version on Android for it to keep working (they changed the underlying crypto library and lost the support there)
No ipad version I've found supports yubikey either
Another great software contribution to the world by Jason Donenfeld, creator of WireGuard!
[dead]
Why would you want to store arbitrary individual passwords instead of deriving them with on demand from the service name/domain and a common secret?
If you are doing that,
- what if some site has weird password requirements and the derived password doesn’t work
- what if a site gets hacked and you need to rotate one password.
If you have to store data per-site anyway because of those cases, may as well just store passwords. You can (and should) still generate extremely high entropy passwords.
Additionally, you can store other data for example one could have scans of important documents that are stored in Pass which means they are GPG encrypted and backed by a git repository so they are versioned and shared across multiple machines.
indeed. Additionally:
- if your secret leaks and you don't know it (or you do know, but you need some time to change it), the attacker not only gets the snapshot of your password manager but also can derive all future passwords you'll generate, or past ones you long forgot about
- there's no way to know what you've entered before, since it's stateless. With data stored in a manager, I know what username I used and can associate other data. If your uniqueifying input is the domain, and let's say HN would become hn.yc or whatever and you visit it again in ten years, you'd have to remember that hn.yc accepts the password of what you entered as news.ycombinator.com
I have to admit though, hash(name+secret)=password is so simple and beautiful that it draws IT people like a fine artwork draws visitors. But for me, that doesn't outweigh the practical issues
Because the former works with any site and circumstance and the latter does not.
Not all sites are safe, either by design or by people running them. Having a common secret+service name as password AND having at least one of those sites leaking your plaintext password could mean that your derivation may go public and all your other passwords and services fall because of that.
presumably the derivation would involve a cryptographically secure, non-reversible function so as to not compromise the secret should one of them be leaked.
"deriving them" != op<+>