For anyone wondering why the joke is funny – it’s an ancient graybeard unix joke and longstanding meme, stemming from the first line of the man page for ‘ed’ (http://man.cat-v.org/unix-6th/1/ed). You may have had to have been there.
I really like how simple it is to manage, you can hook it up with git and sync it across all your computers really easily. I’ve also found that it integrates pretty well with dmenu.
I dislike how this leaks metadata by storing the site names in plaintext. I’d care more about people finding out I had a Neopets account than I would about the password to that (entirely hypothetical) account.
Also, is it possible to store a username for a site as well as a password? It doesn’t look like it from the examples. Sometimes remembering what username you used for a site is harder than the password.
You can name the files whatever you like. You could create an encrypted file that was a map of random filenames to the account name if wanted. I’ve thought about creating a patch that would do that storing and lookup for you.
You can store any data you want. However I do agree I don’t like storing the site names in plaintext, but in general I find pass a really handy tool. I have just migrated from keepassx2 to pass.
I’m nowhere near an expert on password security, but isn’t it better practice to store passwords through hash-and-salt? Surely you’d compare the stored hash to the hash of the user’s submission.
Is this considered secure because it is local? Alternatively, are there design reasons why encryption was chosen over hashing?
EDIT: I now see that I misunderstood the distinction between password storage & management and password verification by a third party.
The original plaintext needs to remain accessible so that, eg, your password for Neopets can be retrieved and submitted to them when you log in.
In cases where the plaintext is not needed (for example, managing the passwords of users accessing your web app), hash-and-salt is a far better approach.
snort
For anyone wondering why the joke is funny – it’s an ancient graybeard unix joke and longstanding meme, stemming from the first line of the man page for ‘ed’ (http://man.cat-v.org/unix-6th/1/ed). You may have had to have been there.
I really like how simple it is to manage, you can hook it up with git and sync it across all your computers really easily. I’ve also found that it integrates pretty well with dmenu.
I dislike how this leaks metadata by storing the site names in plaintext. I’d care more about people finding out I had a Neopets account than I would about the password to that (entirely hypothetical) account.
Also, is it possible to store a username for a site as well as a password? It doesn’t look like it from the examples. Sometimes remembering what username you used for a site is harder than the password.
[Comment from banned user removed]
A coworker who used crypt used a wrapper that passed everything through
Crypt::Scrypt. Worked really well.Yes, you can store a username or any arbitrary data. See the section titled Usernames, Passwords, PINs, Websites, Metadata, et cetera.
Oh, duh. I searched the man page for “username” but not the website.
Sounds like they need to patch their man page.
You can name the files whatever you like. You could create an encrypted file that was a map of random filenames to the account name if wanted. I’ve thought about creating a patch that would do that storing and lookup for you.
I’m not associated with
pass, but I think that would be a much-welcomed optional feature, should you find the time to implement it.You can store any data you want. However I do agree I don’t like storing the site names in plaintext, but in general I find pass a really handy tool. I have just migrated from keepassx2 to pass.
I’m nowhere near an expert on password security, but isn’t it better practice to store passwords through hash-and-salt? Surely you’d compare the stored hash to the hash of the user’s submission.
Is this considered secure because it is local? Alternatively, are there design reasons why encryption was chosen over hashing?
EDIT: I now see that I misunderstood the distinction between password storage & management and password verification by a third party.
The original plaintext needs to remain accessible so that, eg, your password for Neopets can be retrieved and submitted to them when you log in.
In cases where the plaintext is not needed (for example, managing the passwords of users accessing your web app), hash-and-salt is a far better approach.
I use this, it’s pretty good, but not terribly flexible and I haven’t had a great time trying to get multiple databases/identities to work well.
As a result, I have private business stuff in pass and day job stuff in KeePassX. KeePass handles multi-db much better.