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.
Not if you want to access it on multiple devices, in which case the built-in solution is to use git. In that case your git server sees all the metadata.
I think this is outside of the threat model of most password managers -- your desktop search history (whether in your shell, Spotlight, or whatever) is leaking equivalent and probably more detailed information.
It can be a problem if you want to back up the password database to the cloud.
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.
I don't actually use pass, but as an idle thought: if you're concerned about this sort of metadata when syncing your `pass` store to a cloud provider, why not take advantage of the GPG key you already have and encrypt everything as a single blob in one shot? You pay a little more with each synchronization, but probably not enough to worry about for reasonably sized stores.
I've used pass for a while, but I switch to bitwarden, since it has official apps for all platforms. Also with bitwarde I only have to trust them, with pass I have to trust all the different app developers.
I've been using pass for several years now and I recommend it to my friends, but I usually get weird looks when I say I store my passwords in a git repo (it's not as bad as it sounds!). Here's why:
- 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.
git push. The Android app works with git repos from SSH. I also use Wireguard since I run my SSH server behind the VPN, but this is obviously optional since you can just expose your SSH server to the internet.
Ah, there is an Android app [1] which you sync the passwords to and it basically presents a list of all your websites. To use a password: tap on the website name, unlock your GPG key, and then see your password and put it in your phone's copy/paste buffer.
This is correct. Pass can only copy it in the paste buffer for 45s.
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.
The Password Store app delegates key management to another app. I use OpenKeychain [1] for this. I believe OpenKeychain supports Yubikeys, but I haven't used that feature myself so I can't speak about how well it works.
It supports PGP keys stored on yubikeys via OpenKeychain. There's talks of removing support for OpenKeychain in lieu of a homegrown implementation since OKC develoent has lost velocity. And their library interface can be a bit cumbersome.
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:
Slightly OT but this is yet another example of why Termux is the killer app for Android. I didn't use to think there was much difference between iOS and Android until I discovered Termux.
The android app allows one to use OprnKeychain, so I can use my gpg key on my yubikey to both authenticate the SSH session to do git pulls and decrypt individual secrets.
It's worth mentioning though that your repo could leak metadata about what accounts you have, and your username, depending on how you name your pass entries (ie. you can mitigate it by adopting a more cryptic naming scheme for sensitive entries). Just something to be aware of, it may not matter for your use case. Bitbucket still offers free private repos, which I use for my password store.
> I used a browser extension for awhile, but I haven't gotten around to reinstalling since the copy/paste works fine for me.
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.
We made an extension for encpass.sh (similar in some ways to pass) that stores secrets in Keybase (https://github.com/plyint/encpass.sh/blob/master/extensions/...) if that sort of thing is of interest to you. Outside of personal secrets, it can be used as a sort of low cost stand in for shared secrets that you might use something like Vault for in a team environment.
That's interesting. I started storing my dotfiles repository in Keybase. There's not any secrets in there really other than how my home directory is setup but I figured there's no reason I couldn't keep my AWS keys and ssh key pairs in there too.
I'm glad it's working well for you. I used to use pass, but when I lost my gpg key I was able to recover most of my passwords through a mistake I'd made. After that I decided to switch to something where I wouldn't be able to screw up as easily, and bought 1password.
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.
Really good point that you can’t change a password on something if backups exist - because they backups still have the old password. Would apply to 1Password vaults backed up by TimeMachine too.
Yubikeys that can do gpg are $40 or so and have lots of other uses.
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)
> I usually use the -c option to copy/paste my passwords
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.
Thanks. There wasn't any manual page or --help output, so I gave up on it, but now this may be the best option I know of. But, yeah, I could have just `cat /bin/passmenu`.
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.
> If someone types "pass" in your terminal it will show a list of sites that you've stored.
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.
But that's not the concern, anyone who gets their hand on your passwordstore (encrypted) gets the same information. That is not the case with a format that stores your password in one big database.
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.
What people mean by leaking metadata is if you sync over git or dropbox you also leak the metadata to them. Whereas with 1password or something like it the sync server only sees an opaque blob.
I love the idea of Pass, but from what I've seen of the UX (not talking looks) it doesn't really compare to the ease of use of products like 1Password (which I suspect was the catalyst for this being reposted). Does anyone have any contrary experiences when shared across iOS, Linux, and macOS devices + browsers?
I really like pass, but I switched to Bitwarden for this reason. Bitwarden has first party support everywhere I need it. Pass has clients everywhere, but other than the CLI I have not been impressed.
QtPass was descent last time I tried it but I'm not sure if it has been updated recently. Not really much need to have a separate GUI though when there are browser extensions like Browserpass.
I don't use Windows, but I very easily use pass across multiple Linux, Mac, and Android devices. Sometimes I forget to git push something, but that's pretty rarely an issue for me. Set up requires a bit more work than 1Password, etc. but I still think it's pretty easy to set up.
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.
My almost 70 years old dad uses Pass for iOS in his everyday life. He does not have a clue about what's going on under the hood (gpg, git, my instance of gitea where it pushes to, me being able to intervene or fix stuff from somewhere else than his phone, etc.), but thats fine for both of us. He even complained, when I suggested to try Nextcloud Passwords because he might understand better what's going on there. So I guess in terms of UX this is a positive example.
I wrote a pass-like password manager that's built using a layered architecture and one of the lower layers basically fits your exact use-case! The three layers that make up the password manager are:
- 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.
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.
I used to use this, and then I moved to a real password manager. Like seriously, this doesn’t hold a candle to an actual well-engineered password manager. I use Keepass right now, with MacPass and Keepassium; both excellent apps.
I've only used keypassx on windows, but the auto fill feature was amazing.
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.
That's how I use pass on Linux. A key shortcut is bind to script that calls "xdotool getwindowfocus getwindowname", selects credentials set based on it, asks for master password with pinentry-qt if needed, then types with "xdotool type --file -".
It works and is better than placing password in clipboard and than "xdotool type $pass". Likely worse than proper integration with password consumer.
Interesting. I just have a keyboard shortcut in i3 that uses dmenu to let you select a credential. Very handy as I have multiple accounts for some sites/apps. Plus, the browser extension has its own keyboard shortcut.
- 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.
Not sure what any of the above have to do with this app...
"- 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.
I'm saying the tool works for a subset of uses for generated encrypted password stores. Unless I misunderstand and this is entirely for secret sharing between servers, in which case I retract everything I said.
If your team has GPG keys (they should if they're signing Git commits) then pass works great for teams as well. You can encrypt to multiple GPG key IDs so many users and decrypt passwords from a shared git repo.
Tangential question: why doesnt keepass or keepassx autosave?
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.
>The password store does not impose any particular schema or type of organization of your data, as it is simply a flat text file, which can contain arbitrary data.
That whole section, the options (or lack thereof) is a mess...
Not really.. Gopass which is compatible supports YAML-based key/values. I find having to conform to a particular password management solution for extended entries to be more messy.
It is a file-based key-value store, where only the values are encrypted[1], with GPG to make it worse. For these reasons, I moved to KeePassXC. It is cross-platform, has a nice Qt GUI and you don't have to resort to hacks to have several values associated with a single key (i.e. not just password, but also username and others).
Because you still need to manage your GPG keys with an obscure CLI. When I last switched computers, I tried just copying my "~/.gpg" directory. Didn't work. GPG was confused, produced even more confusing messages, which didn't really help me understand what the problem was. I needed to google for the right incantation of commands to export my keys from one computer and import them on another. Compare that to what you have with KeePassXC: switching computers? Just copy this single file and everything will just work.
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.
Unless you need multiple concurrent writers or some kind of RBAC it's going to be really hard for anything to beat the KP database just because it already takes into things like that into account, along with optional entry history, arbitrary associated values, etc.
Been using it both with computers/phones and via programmatic access on cloud storage for years.
> resort to hacks to have several values associated with a single key (i.e. not just password, but also username and others).
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"
* 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.
It makes me slightly weary, as those sorts of things can have unintended consequences. For example, there was a soc
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
Password managers that use authenticated encryption are not vulnerable to such attacks. Well, it's more a hypothetical attack, in practice you're more likely to get a keylogger.
I'm not sure what you mean by authenticated encryption. I'm assuming you just meant single key encryption.
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?
Pass uses public key to encrypt files, an attacker needs to know only the public key to forge pass files, and that public key isn't secret, it's stored in plain, unencrypted, that's why you can create pass files without entering master password that protects private key which is not used to create pass files. That's the catch with asymmetric encryption.
It's not a certainty of abuse, only uneasiness about technical feasibility. Historically abuse of forgery was clever and unpredictable, as a result design of cryptographic systems tries to prevent forgery when possible. A hypothesis: pass prints text from decrypted file to terminal, terminals have rich functionality, legacy features and wide attack surface, so text printed to terminal is an attack vector.
And convenient. The only minor road block I sometimes encounter is when a website has dumb rules for password. I have to generate a auto one. Then edit it manually to make it comply to « no @ in password » or whatever dumb stuff like that
What you probably want is a signature. Since pass can be a git repo, you could use git to sign your commits [1]. But you'll have to remember to check the git commit signatures or automate checking it somehow.
Restricting to a git repo and making sure to check that the commit is signed and there's no diff to current would work, but it's easier to just put the login URL (or at least the domain) as the second line of the encrypted file (Pass allows arbitrary metadata).
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.
> 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.
A common way to use `pass` is to store things like `organization/domain/username` so for example it might be `goldmansachs/github.com/alphacoder` which is telling us that you do some work for Goldman Sachs who store stuff on Github and your username is alphacoder.
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.
I haven't used this app, but if the issue is a binary file where the app is expecting plain text, you could base64 encode your file. Maybe with some dummy password data. Then your arbitrary encrypted file is just another line in the plain text file.
I don’t really see the implication.
Also, it’s would be trivial ( or not too hard ) to wrap the whole thing in another layer of encryption. Like a Vera crypt.
But wait, actually I don’t really see what’s leaking. The name of the file that store the encrypted password ?
Many password managers allow most of things, so I'm not convinced. I'm using keepassxc, which surprisingly does not get much publicity here on HN.
> 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.
> 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!
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.
I don't use pass myself (I have severe NIH[1]), but its design has inspired me many times over: very, very few tools rise to the challenge of adhering to the Unix philosophy without cargo-culting it, and pass is one of them. I highly recommend that people looking to write engineer-friendly tools study its manpage[2].
Similarly, I wrote "hunter2" [0] to manage my passwords, for places where I'm still forced to use passwords. Although I didn't know of "pass" when I wrote it, it accomplishes the same goals. One difference is that it doesn't rely on PGP keys but just uses bare RSA keys from a smartcard. This is because the vast majority of authentication systems I work with use an X.509 certificate with an RSA key pair, hardly anything uses a password any more (since doing so requires a lot of paperwork).
It's simple file format let to build different interfaces to access the same files. I prefer gopass (https://www.gopass.pw/) as user interface as it have a few extra features that makes it a bit more confortable.
Interesting to see this come up. I wrote about using pass to authenticate to Docker inside of an alpine linux docker container last summer[1]. It was quite the undertaking to get it all working. The premise was to figure out how to securely log authenticate to docker, potentially in a CI type system.
# 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.png
I love the simplicity of Pass, but I wanted just a few more features, like being able to store (and retrieve) extra data easily. Unstructured data below the initial password wasn't really enough for me.
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.
In my pass files, I put the password as the first line, optional username as second line, then I format the rest of the file as a YAML doc. So you can decrypt the file, scan for the first "---" and then everything after that is YAML (or multiple YAML docs if you have more "---").
I've developed `prs` as `pass` alternative. It fixes many annoyances for daily use. It provides automatic syncing between multiple devices through git, supports multiple keys and many other things. It simply uses your existing `pass` store.
It's an amusing reference to the cheeky line from the historic Unix man page for `ed`; "the standard Unix editor".
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.
They at least offer local network syncing, instead of requiring a cloud account (which is a deal breaker for me). This lets you keep your passwords in sync between your Computer (master) and mobile devices without them ever leaving your home.
All that does of course still require trust in the company, but at least not in their cloud infrastructure and, well, the internet...
I love pass but I have been having very weird issues lately with gpg agent taking ages to ask me my password to decrypt the database. Really annoying and googling has not yielded fixes. Worse the dev doesn’t use GitHub so getting in touch is a giant pain in the ass.
212 comments
[ 0.21 ms ] story [ 244 ms ] threadpass 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:
https://github.com/roddhjav/pass-tomb
- 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.
[1] https://github.com/mbos/Pass4Win#readme
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.
[1] https://www.openkeychain.org/
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):
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.
[1] https://keybase.io/
https://github.com/gopasspw/gopass
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?
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.
there 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.
- 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...
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.
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.
- 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.
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.
That whole section, the options (or lack thereof) is a mess...
[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:
* 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.
[0]: https://github.com/Evidlo/passhole/
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.
[1]: https://github.com/woodruffw/kbs2
[2]: https://git.zx2c4.com/password-store/about/
[0] https://chiselapp.com/user/rkeene/repository/hunter2/
Symmetric encryption with an actually comprehensible CLI; thank you!
[1]: https://github.com/str4d/rage
[2]: https://github.com/FiloSottile/age
[1] - https://jer-k.github.io/apline-linux-docker-authentication-w...
Is there a comfortable way to store+access arbitrary files and/or attachments with pass?
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!
Some might find it useful.
https://github.com/timvisee/prs
https://pubs.opengroup.org/onlinepubs/9699919799/
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...
- 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...
Ideally there would be a better solution.