https://apps.apple.com/us/app/pass-password-store/id12058205...
But from "paranoid" point of view you can't verify is this is the same code used in app and all of currently available stores lacks in reproducible builds department. So it's always a tradeoff between ease of use and hassle.
In particular, I don't see how 2FA is possible with this, so shoulder surfing is a bigger issue.
I definitely trust Google or BitWarden more than a password I can memorize plus my own constant vigilance.
You can use anything that integrates with GPG ... eg: you can do it with a Yubikey [0]
[0] https://support.yubico.com/hc/en-us/articles/360013790259-Us...
Still, it doesn't allow SMS or email based 2FA as far as I can tell, since that involves a trusted server and doesn't mean anything in a trustless model where the server owner could just add a bypass.
Umm, why not?
First, you can use a different app (like aegis) to generate OTPs.
Second, pass has an extension (https://github.com/tadfisher/pass-otp) that can be used to generate OTPs.
Third, you can use something like oathtool to generate your otp using your totp secret
oathtool -b --totp "your-totp-secret"
With keepassxc, 1password, or even chrome's password manager, if a phisher links you to "gmail.scammersite.info", even if it looks exactly like the real gmail login page, browser-integration will not fill in the password field.
With pass, the default flow is to copy the password to your clipboard, and paste it into the password field manually. That allows the above phishing attack to succeed.
For that reason, I would not rely on password store. If you want to control your own database, use keepassxc, and sync the kdbx file with either git, dropbox, or anything else you like.
As a bonus reason, password-store also leaks filenames (entry names), while keepassxc and most other options do not leak the entry name.
I am aware password-store technically has browser extensions, but few people use them in practice, and since password-store doesn't have an idiomatic "URI" field for a password, it doesn't actually auto-fill by default in a way that stops the above attack.
Passwords are per file. Grabbing a password by a Yubikey touch doesn’t expose other passwords. Per password sandboxing. With keepass, you open the vault most of the time to expose a less important password, and the entire vault is at risk.
Beyond Pass, you should be careful with the browser extensions (and browser in general ). There are a lot of them, never audited.
The entire vault is at risk only if the attacker has a zero-day in the browser extension, or already has local code execution.
In your threat model, which is more likely:
1. you get sent a phishing link and click on it, and then copy+paste into a password field
2. An attacker compromises your browser extension with a zero-day
3. An attacker manages to get local privileges on your computer, is competent enough to exfiltrate your keepassxc database from memory after you unlock it with your hardware token, but is not competent enough to exfiltrate your 'password-store' passwords, or browser session cookies, or whatever