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

  ~/.password-store # cat .gitattributes
  *.gpg diff=gpg
  ~/.password-store # cat .git/config
  # ...
  [diff "gpg"]
          binary = true
          textconv = gpg2 -d --quiet --yes --compress-algo=none --no-encrypt-to --batch --use-agent

For the structure I "solved" that problem by creating folders with three main files:

    Websites/foo.com/username
    Websites/foo.com/password
    Websites/foo.com/email

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.

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

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

but this is not a shell script...

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.

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.

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.

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.

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

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

Is bitwarden in some way able to protect passwords while still being unlocked?

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.

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.

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.

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.

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

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.

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.

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

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.

"Normies"? Everything is relative, I guess. I use 1Password and just hope for the best.

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

Any particular reason for remote access via wg and not via syncthing? I'm also curious how you access it via wg on Android?

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.

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:

    #!/bin/sh
    
    set -eu
    
    k=$(pass ARG)
    oathtool -b --totp "$k"

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

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

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.

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

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.

I agree

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

How do you have 1300 passwords? Sounds like a lot. Come to think of it though, I have no idea how many I have.

Any recs for yubikey setup guides with pass?

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.

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?

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

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

The android "Password Store" app is okay'ish, integrates with accessibility API to offer auto fill in many apps.

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.

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

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.

No need to forego mobile if you're on iOS [1].

1. https://apps.apple.com/us/app/pass-password-store/id12058205...

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

I ssh in from my phone, which works pretty well.

there is for iOS - passforios - https://apps.apple.com/us/app/pass-password-store/id12058205...

works great.

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.

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

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.

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.