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.
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.
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.
> 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.
* 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.
> 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.
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.
I use pass for exporting secrets to environment variables. I have a multi-line password called "envvars" that contains a script like this:
#!/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.
very nice. ive been setting up a post install script the last while and something like this would be very useful for logging into some desktop apps automatically
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.
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 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).
I use pass as my general purpose personal secret management system. It synergizes very well with direnv, another one of my favorite tools. Using bash substitution, you can set a per-directory environment variable to the output of a pass command. This way you never have to have unencrypted secrets sitting on your dev machine.
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.
Great tool. For those of you who want to set up `pass` on your Android phone, here are my rough notes on how I did it. Apologies, they are rough:
- 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!
Used KeePass and pass in the past. KeePass is nice, but has much more features than I really need. I wanted something lighter and simpler, so I migrated to pass in 2015. Even though it is nice that it relies on tools like gpg and git, it complicated things more than not. It is (was?) hard to use on every OS except Linux. And in addition to backing up the database, the gpg key now needs to be backed up, too. Password management is messy.
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.
If you can stomach some more features, KeePassXC is well-maintained and has an excellent browser extension as well as FDO secret service integration on Linux for CLI access via secret-tool.
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.
I've been using this with a modified version of the example passmenu script, enhanced with:
* 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.
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 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 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).
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.
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?
To backup the passwords a copy of ~/.password-store/ is enough, but to completely recover, a backup of the gpg keys is also required. What's your strategy for this? Do you just backup the entire ~/.gnupg/ directory?
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.
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 "---").
[+] [-] PureParadigm|5 years ago|reply
- 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
[+] [-] iudqnolq|5 years ago|reply
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.
[+] [-] mattacular|5 years ago|reply
[+] [-] encryptluks2|5 years ago|reply
https://github.com/gopasspw/gopass
[+] [-] spicybright|5 years ago|reply
[+] [-] SamuelAdams|5 years ago|reply
[+] [-] RcouF1uZ4gsC|5 years ago|reply
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.
[+] [-] hk1337|5 years ago|reply
[1] https://keybase.io/
[+] [-] fouuler|5 years ago|reply
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.
[+] [-] GekkePrutser|5 years ago|reply
[+] [-] aborsy|5 years ago|reply
* 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.
[+] [-] KMag|5 years ago|reply
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.
[+] [-] TeddyDD|5 years ago|reply
There is also POSIX sh implementation available that is even shorter: https://github.com/dylanaraps/pash
[+] [-] smegcicle|5 years ago|reply
That's sad- could we include a hash to detect stuff like this?
[+] [-] taeric|5 years ago|reply
[+] [-] cycomanic|5 years ago|reply
> 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.
[+] [-] bobbylarrybobby|5 years ago|reply
[+] [-] teawrecks|5 years ago|reply
[+] [-] redsparrow|5 years ago|reply
[+] [-] mackrevinack|5 years ago|reply
[+] [-] tlackemann|5 years ago|reply
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.
[+] [-] mumblemumble|5 years ago|reply
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.
[+] [-] iudqnolq|5 years ago|reply
[+] [-] woodruffw|5 years ago|reply
[1]: https://github.com/woodruffw/kbs2
[2]: https://git.zx2c4.com/password-store/about/
[+] [-] rkeene2|5 years ago|reply
[0] https://chiselapp.com/user/rkeene/repository/hunter2/
[+] [-] dejj|5 years ago|reply
Symmetric encryption with an actually comprehensible CLI; thank you!
[1]: https://github.com/str4d/rage
[2]: https://github.com/FiloSottile/age
[+] [-] ruiseal|5 years ago|reply
[+] [-] vinceguidry|5 years ago|reply
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.
[+] [-] frobisher|5 years ago|reply
- install Password Store on Android phone
- import remote repo using ssh
- 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
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!
[+] [-] adrium|5 years ago|reply
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.
[+] [-] hpfr|5 years ago|reply
[+] [-] philips|5 years ago|reply
[+] [-] NullUsr|5 years ago|reply
- 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...
[+] [-] kingo55|5 years ago|reply
[+] [-] Liskni_si|5 years ago|reply
* 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
[+] [-] oritsnile|5 years ago|reply
[+] [-] b1476|5 years ago|reply
[+] [-] timvisee|5 years ago|reply
Some might find it useful.
https://github.com/timvisee/prs
[+] [-] yakubin|5 years ago|reply
[1]: Keys and Git history are not encrypted.
[+] [-] gmuslera|5 years ago|reply
[+] [-] fullstop|5 years ago|reply
[+] [-] JadoJodo|5 years ago|reply
[+] [-] rhardih|5 years ago|reply
Wrote a bit about it here: https://rhardih.io/2021/03/migrating-from-lastpass-to-pass/
[+] [-] efiecho|5 years ago|reply
[+] [-] johnklos|5 years ago|reply
[+] [-] mewse|5 years ago|reply
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.
[+] [-] remram|5 years ago|reply
[+] [-] NullUsr|5 years ago|reply
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...
[+] [-] dbmikus|5 years ago|reply
Regardless, cool little set of programs you have!
[+] [-] GekkePrutser|5 years ago|reply