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.
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 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 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.
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.
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.
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.
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.
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
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.
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.
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 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.
Readit News
- 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
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
What do you mean? I copy my repo to new computers by just copying .password-store and I've never had a problem.
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.
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.
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.
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.
> stored in encrypted sqlite3
you had me at encrypted sqlite3. it would be great if you mention in readme that it uses SQLCipher
https://en.wikipedia.org/wiki/Ward_Cunningham#%22Cunningham'...
but this is not a shell script...
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.
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.
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.
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.
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.
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)
You might already be aware of this, but Bitwarden also has a CLI client that can be used for this purpose, at least casually.
My main issue with pass is that it doesn’t work great on iOS with yubikeys.
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
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).
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 myself and I don't care about mobile. But I really don't know what to recommend family members.
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.
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.
[1]: https://github.com/shikaan/keydex
So, for now, I've settled on Vaultwarden and it has been surprisingly stable so far.
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
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.
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
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.
It uses age and allows you to use multiple keys for encryption
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
https://github.com/agrahn/Android-Password-Store
And no, those apps don't work great, because they involve some clunky GPG app.
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
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.
Deleted Comment
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.
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.
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.
Deleted Comment
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.
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.