7 ms·
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 decrypti
by aborsy 6y ago
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.
* 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.
- taeric 6y agoThe asymmetric point is surprisingly useful.
- jedimastert 6y agoIt 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
- taeric 6y agoNot clear how that has any relevance here. If the encryption is broken, pretty sure most encryption is busted.
- GoblinSlayer 6y agoEncryption is broken, just not in all scenarios, that's why security without threat model is meaningless.
- taeric 6y agoMy point was that if this model is broken, I'm not sure I would trust any other for storing data at rest, either. Specifically, why would you still trust any other password manager?
- GoblinSlayer 6y agoPassword 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.
- taeric 6y agoI'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?
- GoblinSlayer 6y agoPass 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.
- dopidopHN 6y agoAnd 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
- smegcicle 6y ago> For example, if you store your database on a cloud, say, Dropbox, Dropbox could switch your Dropbox.com file with google.com file That's sad- could we include a hash to detect stuff like this?
- deleted 6y ago[deleted]
- PureParadigm 6y agoWhat 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. [1] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
- KMag 6y agoRestricting 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.
- KMag 6y agoMake the login URL (or at least the domain) the second line of the encrypted file. Pass supports arbitrary metadata.
- teawrecks 6y agoI want a tool like this, but I don't think I can ever be ok with leaking meta data.
- kame3d 6y agoThere's the pass-code extension for that: https://github.com/alpernebbi/pass-code 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.
- nyolfen 6y agopass-tomb as well: https://github.com/roddhjav/pass-tomb https://github.com/roddhjav/pass-tomb
- progval 6y agoIt only leaks metadata to people/systems with read access to your password folder, which is very limited. Unless you share it with someone else or publicly (eg. Dropbox or Github), but then you're leaking a lot more metadata anyway.
- Evidlo 6y agoI wrote a pass equivalent for KeePass for this very reason [0]. 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/ https://github.com/Evidlo/passhole/
- dopidopHN 6y agoHi, 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 ?
- bobbylarrybobby 6y agoCan you use it on mobile?
- jari_mustonen 6y agoYes. There’s an iPhone app for Pass. Setting it up is a hassle but it works.
- deleted 6y ago[deleted]
- zaik 6y agoOn Android you can access your passwords using https://f-droid.org/packages/dev.msfjarvis.aps https://f-droid.org/packages/dev.msfjarvis.aps .
- chriswarbo 6y agoI use it for 2FA (via https://github.com/tadfisher/pass-otp https://github.com/tadfisher/pass-otp ) on my OpenMoko (QtMoko). I installed it via apt-get from the normal Debian repos.
- TeddyDD 6y ago> It’s secure, because it’s a short bash script There is also POSIX sh implementation available that is even shorter: https://github.com/dylanaraps/pash https://github.com/dylanaraps/pash
- cycomanic 6y agoMany 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.
- KMag 6y ago> 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.