Pass: The standard Unix password manager
passwordstore.org
passwordstore.org
- I host my git repo on my desktop computer (through SSH), so it's not exposed anywhere except if you have SSH access to my computer. (A lot of people seem to think git = GitHub which is not true). So if your git repo is not exposed to the public, you don't leak any of the site names/usernames you use.
- The passwords are GPG encrypted so even if it were leaked that would be okay as long as my secret key remains secure.
As far as usability goes, I usually use the -c option to copy/paste my passwords. I used a browser extension for awhile, but I haven't gotten around to reinstalling since the copy/paste works fine for me. Syncing with my phone and Linux devices works perfectly (since it's just git).
The Windows client seems to be no longer maintained [1], so I would like better support here for my Surface. But this is still okay since I can SSH to my desktop computer from Windows and copy/paste the passwords from there.
That is: there are GUI mobile and desktop client apps, compatible with the pass storage schemes.
In this case, the parent refers to one such app that can connect to e.g. your GitHub repo with your passes, and read/manage the passwords from there.
[1] https://play.google.com/store/apps/details?id=dev.msfjarvis....
The command has a nice auto completion and search feature. And calling it without arguing give you a list of all the name of the key you have in a tree view.
I really enjoy using that little utility since I would say 4 or 5 years.
I only use hardware keys now.
Termux[0] does supports gpg and pass but no yubikey by default, but okc-agent[1] is a third party binding of OpenKeyChain, providing barebones gpg via yubikey. I use this to decrypt passwords via NFC:
[0]: https://termux.org [1]: https://github.com/DDoSolitary/OkcAgent
Simple password decrypt: okc-gpg -d ~/.password-store/mypass.gpg
I made a termux shortcut (button on homescreen) to emulate pass-dmenu via this ( store in ~/.shortcuts):
#!/data/data/com.termux/files/usr/bin/env bash
# Lists passwords in termux dialog, decrypting selection to clipboard for 45s
# http://redsymbol.net/articles/unofficial-bash-strict-mode/
set -euo pipefail
# Inspired by https://git.zx2c4.com/password-store/tree/contrib/dmenu/passmenu
shopt -s nullglob globstar
prefix=${PASSWORD_STORE_DIR-~/.password-store}
password_files=( "$prefix"/**/*.gpg )
password_files=( "${password_files[@]#"$prefix"/}" )
password_files=( "${password_files[@]%.gpg}" )
password_files_csv=$(printf '%s,' "${password_files[@]}")
choice_json=$(termux-dialog sheet -t "Select password" -v "$password_files_csv")
choice_exit=$(echo "$choice_json" | jq .code)
[[ "$choice_exit" == 0 ]] || exit
password=$(echo "$choice_json" | jq .text | tr -d '"')
okc-gpg -d ~/.password-store/"$password".gpg 2>/dev/null | head -n 1 | termux-clipboard-set
# pass show -c "$password" 2>/dev/null
termux-toast -s "Password copied to clipboard"
sleep 46
termux-clipboard-set ""
termux-toast -s "Password remove from clipboard"One danger of doing just copy and paste is that you are more exposed to phishing attacks. The browser extension for the password managers check that the site that they are filling in is indeed the site that they stored the password for.
You can use auto type. But you need to make each entry identifiable and sometimes it doesn’t work because page and login titles change.
I still had an earlier gpg key, and had not reset all my passwords when I switched keys. I'd just re-encrypted them. This let me check out an old commit and decrypt all the passwords in it. A dumb mistake, but it showed me I'm not smart enough to use something that doesn't hold my hand more.
Iirc, ssh can now do file encryption with FIDO2 keys; these are $10 or so.
Definitely worth buying a pair if you are worried about security (both Trojans, where local encryption at rest can be defeated, and losing your device where it is not)
In X11 it's also possible to get passwords typed automatically with xdotool, which I call through an xmonad package. The only thing I'm missing is more powerful autocompletion.
... but as far as I can see, passmenu just copies to clipboard and doesn't use xdotool?
* It leaks meta-data. That might sound a con, but in exchange you get the ability to extract a password without decrypting and thus exposing other passwords. There is isolation.
* It’s more convenient than a single file password manager. You type ‘’pass -c goo’’ for your Google account, instead of clicking on your password manager, typing password, searching in data base, finding the right entry, copying password or pressing auto complete and closing the database. The combination of mouse and keyboard can make alternative password managers slower.
* You don’t need your master password to add a new password (it uses asymmetric encryption).
* You can easily program it, eg, write a backup script that grab a password from store.
* It uses GPG which means your secret key can be stored on Yubikey, handled by a dedicated agent. Your password is basically a short PIN with max 3 tries. This is unparalleled convenience and security!
* It’s secure, because it’s a short bash script that you can check, and delegates encryption to a dedicated well-audited cryptographic tool.
* You can encrypt to multiple keys, thus use it similar to LUKS that supports multiple passwords.
* GPG is usually widely available, so you can decrypt a password on another system on which you may not admin rights to install your password manager.
There might be few cons though. For example, if you store your database on a cloud, say, Dropbox, Dropbox could switch your Dropbox.com file with google.com file, and you copy and hand over your Google password to Dropbox. But this is hypothetical for most of us! Also, some people don’t like metadata (filenames) leakage, though apparently there are solutions for that.
Overall it’s very convenient and functional. I highly recommend it.
al engineering exploit where someone would call into Amazon and add a credit card to an account they didn't own. They would then call right back and request a new email added to the account and use the freshly added credit card as authentication.
They could then use your Amazon account, or use the real card associated with the account as authentication for something else
Specifically, why would you still trust any other password manager?
My question is if those are really on a different set of math, as my understanding was that they were not, all told. If you can bust public/private key encryption, you can typically bust all encryption. Is that not necessarily the case?
How does this help an attacker get my passwords?
Thank you.
That's sad- could we include a hash to detect stuff like this?
[1] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
OpenPGP (GPG / etc.) use a MAC on the file, so an attacker can't modify the encrypted file and still get it to decrypt (at least without some flag to ignore broken MAC). An attacker could create a new password file for you for their domain, but then they'd have to make up a random password for you that's not going to match your FriendFace/Congo/Vigintillion password.
https://github.com/alpernebbi/pass-code
> A pass extension that obscures the filenames and folder hierarchy within your password store.
> pass-code generates random filenames for each file in the password store and keeps the mapping in an encrypted file. This way, no valuable information is accessible even if your password store is leaked to the public (unless your GPG private keys were also leaked). Nevertheless, you should always ensure proper protection of your password store.
Unless you share it with someone else or publicly (eg. Dropbox or Github), but then you're leaking a lot more metadata anyway.
It doesn't leak any metadata because everything is contained in a single file and it's compatible with the rest of the KeePass ecosystem.
I keep reading that argument in that thread about the metadata being leaked and I feel left out of the party.
How is it leaking? Why do we have to care and could some mapping of the file name to a encrypted key on map-table solve that ?
You'd have to manually look up the entries in a lookup table to resolve obfuscated names back to readable names... Or upstream support for whatever format is devised. I dunno.
But wait, actually I don’t really see what’s leaking. The name of the file that store the encrypted password ?
How so?
There is also POSIX sh implementation available that is even shorter: https://github.com/dylanaraps/pash
> Here are some of the pros of the Pass:
> * It leaks meta-data. That might sound a con, but in exchange you get the ability to extract a password without decrypting and thus exposing other passwords. There is isolation.
I still consider leaking metadata a more serious potential for issues, than having to decrypt the whole database. Also you say extract the password without decrypting, you still need to decrypt the password.
> * It’s more convenient than a single file password manager. You type ‘’pass -c goo’’ for your Google account, instead of clicking on your password manager, typing password, searching in data base, finding the right entry, copying password or pressing auto complete and closing the database. The combination of mouse and keyboard can make alternative password managers slower.
When I use keepassxc I can easily use the libsecret command line, no gui involved (except for opening the dB). By using the secret store integration I also don't interact with the password manager directly most of the time. It gives me the password for git repositories over https, WiFi passwords, my VPN password and ssh is done via the ssh-agent integration, while för the browser there is the plugin.
> * You don’t need your master password to add a new password (it uses asymmetric encryption).
Except as pointed out by someone else, all your old entries are still only encrypted by the old password.
> * You can easily program it, eg, write a backup script that grab a password from store.
This is easy as well via libsecret integration in other password managers
> * It uses GPG which means your secret key can be stored on Yubikey, handled by a dedicated agent. Your password is basically a short PIN with max 3 tries. This is unparalleled convenience and security!
I admit that can be a an advantage, but I don't think I would use it much. If I need to enter a password on the go, I would always use the phone app.
> * It’s secure, because it’s a short bash script that you can check, and delegates encryption to a dedicated well-audited cryptographic tool.
I don't think this argument is convincing. Security is complex and there have been plenty of cases of some tool using known secure components and still messing things up. I'm not saying this is the case here though.
> * You can encrypt to multiple keys, thus use it similar to LUKS that supports multiple passwords.
What's the use case for this?
> * GPG is usually widely available, so you can decrypt a password on another system on which you may not admin rights to install your password manager.
Many password managers work as static binaries AFAIK, so you could just carry that around on your USB stick.
> There might be few cons though. For example, if you store your database on a cloud, say, Dropbox, Dropbox could switch your Dropbox.com file with google.com file, and you copy and hand over your Google password to Dropbox. But this is hypothetical for most of us! Also, some people don’t like metadata (filenames) leakage, though apparently there are solutions for that.
> Overall it’s very convenient and functional. I highly recommend it.
Before I became aware of Pass, I wrote essentially the same thing, but in Python.
Fast-forward a decade or two, and my wife uses a password manager that got deleted from the Apple AppStore, and iPhone backups just contain pointers to the app to install upon backup, not the actual binaries. So my wife had her password database, but no password app. I did a bunch of research on password database formats, and this is recognized as a pretty common vulnerability.
Pass allows you to add arbitrary metadata, so I suggest adding the domain (or better yet, the login URL) as the second line in the encrypted file. I made this automatic/mandatory in my home-spun Pass-alike.
#!/usr/bin/fish
set -x PASSWORD hunter2
set -x PASSWORD_STG hunter3
set -x LUGGAGE_KEY 12345
set -x TOKEN (curl "https://api.example.com/oauth/token" \
--data-urlencode "username=$USERNAME" \
--data-urlencode "password=$PASSWORD" | jq --raw-output .access_token)
set -x TOKEN_STG (curl "https://api-stg.example.com/oauth/token" \
--data-urlencode "username=$USERNAME_STG" \
--data-urlencode "password=$PASSWORD_STG" | jq --raw-output .access_token)
When I want to set the environment variables I run `pass show envvars | source` and it sets the environment variables for the current shell. It's an easy way to keep the secrets out of my shell history and plaintext files.There are a number of ways to integrate it into rofi too, so with the press of a few keys I can navigate to any site and login instantly.
To squash a few concerns:
- Leaking data - If someone types "pass" in your terminal it will show a list of sites that you've stored. I don't find this any less obvious than if someone had LastPass installed on their machine.
- Trusting different app developers - This can be true, but if you stick with the CLI then there's only one app to trust - and one person! You don't rely on a company to safegaurd your data, you trust yourself.
YMMV, thoughts are my own. I happen to very much enjoy pass and I think others might too if you like owning your own data.
This is not really any different from Keychain on a Mac. I don't really see it as a major downside.
If someone's logged into the computer as you, you're already hosed, and this is hardly the first place they're going to look to get a list of websites you've visited.
The implications can be quite significant, because if I get my hands on your store, I might find out that you are User xx on yy which I can then use to try to compromise via social engineering (or it might has a known exploit) and use that as a springboard for other sites that I know from your pass store.
Symmetric encryption with an actually comprehensible CLI; thank you!
I manage multiple machines, and while ssh-agent forwarding is easy to use, a lot of people don't know about gpg agent forwarding. It's a bit fiddly, but it allows you to store all your secrets encrypted on your remote machines and have your gpg agent sitting on your personal machine.
I sorta wish it had different encryption backends, gpg is a bit long in the tooth. But it works just fine.
- install Password Store on Android phone
- import remote repo using ssh
- in my case, I was able to generate a new ssh key for my Android phone from within the Password Store app
- I “somehow” sent this to myself and added on my github profile settings (from my laptop)
- I was able to import my repo and see all my password names!
- still need my GPG key to unlock the password. For this I needed to install OpenKeychain on my android phone- then somehow need to import my GPG key from my laptop to my phone
- followed this to create the key file, knew most already: https://medium.com/@johnnymatthews/import-a-gpg-key-onto-your-phone-7dbadf16fefa
- couldn’t find a cable to connect to USB! Turns out if you connect to your phone by bluetooth, in Ubuntu it’s pretty easy to send a file from the Bluetooth settings menu. Finding the file on my phone was another challenge! Turns out it’s stored in a “pixel 3a > bluetooth” folder in the files browser
- imported file into OpenKeychain!
I love that using my gpg key still required my passphrase (only in my head!).Don’t forget to delete the gpg key you exported on your laptop and your phone! Security of this? Not sure.
And voila! I can now see my `pass`words on my Android phone!
When searching for alternatives, I found the concept of stateless password managers. Proprietary cloud solutions are off the table for me. Because I travelled a lot in 2018, a new criterion emerged: How does bootstrapping work? How do you get any password from the database on a device that you do not own? This is obviously difficult with a traditional approach. I quickly migrated most important logins and never look back!
Besides storing passwords, a password manager should also help using them. KeePass provides Auto-Type for this. Eventually, most passwords will be used in the browser. Having a compatible browser extension became a must. Copy-pasting is a dealbreaker, because every application can read the clipboard! Most desktops support text drag and drop and on mobile, the application should provide a custom keyboard or accessibility feature.
In the meantime, I am using my own browser extension and wrote a converter plugin for KeePass to occasionally copy them (for convenience only) to my mobile. Typing the master password is cumbersome, so I use a random file (one of the dozens) in the Downloads folder as keyfile. In case of emergency or for bootstrapping, there is a web app.
alias journal='pass edit journal/$(date +%Y-%m-%d)'- securestore - An encrypted file store - vcstore - A version controlled file store - pass - Password manager functionality
Each layer builds on the last, so in your case, you could just use the vcstore layer directly without the password manager functionality. I wrote a blog post on it[1] if it sounds interesting.
[1]: https://vimist.github.io/2020/04/12/A-New-Password-Manager.h...
* ability to store/retrieve additional YAML metadata like username, e-mail, etc.
* pre-selection of entries by looking at URL and focused form field (this needs the add-url-to-window-title browser extension)
So in most cases I press a keybinding which invokes passmenu, and then just press enter as the correct entry and field (password/username) is already selected. Quite handy.
Source here if anyone's interested: https://github.com/liskin/dotfiles/blob/home/bin/passmenu and https://github.com/liskin/dotfiles/blob/home/bin/.passlib
Some might find it useful.
[1]: Keys and Git history are not encrypted.
And I don't want to know if I'm holding GPG right. I just want the tool to work for my specific case. But GPG wasn't designed specifically with this case in mind, so, as usual, it will be terrible. It tries to be too many things.
I'll take a look at keepassxc again someday. I'm assuming it works with yubikeys?
Been using it both with computers/phones and via programmatic access on cloud storage for years.
What hacks? Just add the username/whatever under the password.
Pass only uses the first line in the file as the password when you do `pass -c` to copy to clipboard. So you could write a whole book in there if you want.
Pass for iOS also displays those values in a nice list with titles if you write the extra fields as "key: value"
Example:
<password here>
username: coolguy
whatever: abc123there are also at least two browser addons both of which work very well for filling fields
On my computer, I actually like the UI more than anything else because I use ZSH completion for pass and FZF for history search and thus copying any password is just like 5 keystrokes on average.
Wrote a bit about it here: https://rhardih.io/2021/03/migrating-from-lastpass-to-pass/
If my main key breaks, I can switch to the backup key which gives me a buffer to setup a new key from my backup.
The ArchWiki has a decent guide: https://wiki.archlinux.org/index.php/Paperkey
- passphrase (long sentence, but it's easy to remember) - uid (Name <email> - easy) - timestamp (10 digits - kinda hard to memorize but you can have it noted is plain text since it's not sensitive information)
RE: who decided.. well, the presence of `ed` was a requirement for an OS to be accredited as POSIX-compatible, so that's presumably why `ed` decided to describe itself as 'the standard'. But `ed` fell so far out of favor once screen-based editors (`vim`, `emacs`, etc) became commonly available that the "the standard" line which continued to hang around in ed's documentation became a bit of a Unix in-joke.
The modern GNU version of the `ed` tool describes it as "line-oriented text editor" instead of as "the standard Unix text editor". And only briefly mentions the old phrase in an apologetic explaining why that old phrase was used in the past.
So the short version of the answer: it's not. It's an in-joke which is attempting to draw to mind a comparison of this software against older, simpler Unix tools like `ed`. Which IMHO is totally valid, if you say pass is to lastpass as ed is to vscode. Simpler tool, possibly easier to use for keyboard-focused folks, focuses on doing just one thing and doing it well, etc.
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/e...
I ended up taking huge inspiration from Pass, but writing my own implementation[1] with a few more features that increased it's usefulness for my use cases.
I posted it a while ago on here[2] and Reddit[3], but it basically stores each entry as a Bash script, which gives it so much flexibility: auto-typing, references, multiple fields, executable functions, etc. I also wrote a blog post on it[4].
I'd be interested to hear what people think of if if anyone did/does end up giving it a go.
[1]: https://github.com/vimist/securestore [2]: https://news.ycombinator.com/item?id=22851447 [3]: https://www.reddit.com/r/linux/comments/g0643w/a_new_passwor... [4]: https://vimist.github.io/2020/04/12/A-New-Password-Manager.h...
Regardless, cool little set of programs you have!
I'm currently playing with integrating bitwarden self hosted into my flow, eyeing a switch, but it's way more complicated to understand than pass...it does not make it easier to trust it.
[1] - https://jer-k.github.io/apline-linux-docker-authentication-w...
I let Firefox save a lot of passwords, and for those that require more; I have one encrypted Linux volume on my computer. In that volume, name of file is name of service or website, and login and pass are written however.
To speed things up a tad, I have a custom command that points fzf with preview to it, with a little oath2 script in the preview to handle 2FA.
I've been hearing stuff lately about how I should perhaps be concerned when copy-pasting? But for now, these feels pretty good.
- Amazing support and fast response on their forums from the reps
- Works across Linux (my desktop), Mac and iPhone and Safari and Chrome browsers
- Has CLI
- Syncs instantly (unlike Chrome and iCloud Keychain)
- Supports TOTP (no - it does not completely defeat the purpose of 2FA, there are multiple aspects to it)
I am also aware of the risk I'm taking by trusting a 3rd party commercial company with my credentials.
All that does of course still require trust in the company, but at least not in their cloud infrastructure and, well, the internet...
Is there a comfortable way to store+access arbitrary files and/or attachments with pass?
# pipe an arbitrary file into pass
cat ~/Desktop/test-image.png | pass insert -m test-image
# get the arbitrary file out of pass
pass show test-image > /tmp/test-image.pngQuestion for HN... is there a project that anyone knows of, that is using Age instead of GPG as the encryption for Pass? I’ve seen a few implementations of it, but nothing I’d use for a daily driver yet.
Example, not my project - https://github.com/somasis/passage
Anyway it was the first time I had ever used a password manager that you can call directly in the shell. It’s awesome, and once you memorise a few simple key combos it’s super easy to input stored passwords in the shell.
[0] https://www.akamai.com/us/en/products/security/akamai-mfa.js...
Ideally there would be a better solution.
That whole section, the options (or lack thereof) is a mess...
pass uses normal folders to store your website/username information so in that way it is less protected.
But the exposure is to anyone with access to your encrypted pass data. Which in the normal use case is going to be anyone with access to your user account, which means they could likely already see your shell and browser history.
That's part of the threat model for most other password managers, which use a single encrypted file for the database. Pass is the only popular one I know that stores part of the information in plaintext.
https://wiki.archlinux.org/index.php/Gocryptfs
Or there is an extension called pass-tomb:
You could setup a cron job that polls 1Pass for your password CSV, imports the CSV into to pass, and commits the diff.
Caveat that I don’t know how robust 1Password’s API is, or indeed if they have one. You might need to do the “gimme all my passwords in a CSV” step through a GUI, or a very hacky puppeteer script.
Why does it even have the antiquated save button to begin with?
I have permanently lost access to some things due to this, as other password managers don’t have retro features like that. Usually when I’m using unix or linux, its on an OSX keyboard so even my reflexive shortcut key saving has buttons flipped.
- i generate random passwords for myself (yay)
- i share these random passwords with my team (ugh... git i guess huh!)
- i share some of these random passwords with my family (you try teaching a 6 year old git, and a 37 year old woman who already doesn't want to change her habits)
- i use these passwords on my home computer (windows), work computer (osx), android, ios
Yeah, not going to switch away from 1password any time soon.
All of these have support for GPG, yes? So pass will work fine with them. It's just a wrapper around GPG.
"- i share these random passwords with my team (ugh... git i guess huh!)"
Git doesn't mean you "share" anything. First, you can use a private repo, second your passwords are encrypted. Unless you give the master key, nobody "shares" your passwords, even if they have access to the git repo.
You would push a key shortcut, then based on the window title of whatever window has focus, it would simulate key presses into it. So I could type secure credentials into any program on my computer with one key stroke.
It works and is better than placing password in clipboard and than "xdotool type $pass". Likely worse than proper integration with password consumer.