Live data from Hacker News

Pass: A standard Unix password manager

passwordstore.org

151–160 of 212 posts

Re: Pass: A standard Unix password manager

#151

Alright guys, I tried using this as I was curious, and miserably failed. Found out I needed GPG, and some encryption key or ID and whatnot. I have no clue what these things are and would like to know. How can I learn about this encryption stuff like keys and RAS and whatnot? (Books n Articles)

Archlinux wiki typically have very good guides:

https://wiki.archlinux.org/index.php/GnuPG https://wiki.archlinux.org/index.php/Pass

The simplest way to create your gpg-id is with:

$ gpg --gen-key

Fill in your name and email in the prompts. When it tells you it needs to generate a lot of random bytes, you'll probably want to do something like

$ find /

to generate disk entropy for gpg to pull enough random bytes from /dev/random to create your keys.

You can use the email you provided as the gpg-id you give to pass

$ pass init $email

Re: Pass: A standard Unix password manager

#152

If you're using XMonad, you definitely want to use the pass addon in the xmonad-contrib package: https://hackage.haskell.org/package/xmonad-contrib-0.13/docs... I would claim that there isn't a more convenient password management solution than this.

If you're not using XMonad, 'passmenu' is a really handy way to get your passwords. I bind it to ctrl-alt-p and rarely run pass manually now.

Re: Pass: A standard Unix password manager

#153
post #67
post #64

Earlier quoted context omitted.

Yep. Or saves the plaintext of the password elsewhere after using it once for a "legit" use. Rule zero of security is that you can't ask people to forget things. If they had knowledge of a shared secret and they're not supposed to going forward, then that shared secret needs to be changed.

Thats the whole point of audit logs. You lookup the passwords he accessed and only rotate those (vs rotating all of team's shared secrets because you dont know which ones he used/saved/etc).

No it actually is not the whole point. Security is never convenient. If you do not have an active password rotation automated for all accounts, even shared, then you should be more worried about an employee reporting you to compliance officers. #justsaying

Re: Pass: A standard Unix password manager

#154

I don't like the fact someone with access to my hard-drive can figure out all the services I'm using just by looking at the filenames. It's convenient yes, but I prefer one encrypted file that contains it all.

Check out pw, my alternative to pass, designed because of the reason you mentioned: I don't want my password manager to leak the list of services I use.

https://github.com/gioele/pw

In pw each password database is a single file, the internal indexes are random IDs. Each line in a database is a serialized GPG file with a password and associated metadata.

The file format is git-compatible and everything can be managed with standard command line tools.

Re: Pass: A standard Unix password manager

#155
I use pass on all my devices. IOS, chromebook and cli. I freaking love it! passforios is still on testflight but so good. Only a few issues with passforios:

- It forgets my github password everytime i upgrade - I honestly don't like the fact that I can't turn off the pin. 4 digits with unlimited retries. - It can't merge sometimes. I think they should be more aggressive about git rebase

Re: Pass: A standard Unix password manager

#156
post #135

Earlier quoted context omitted.

> Where many other password managers use convoluted constructions with (e.g.) AES and PBKDF2, this is very straightforward GPG. That's a bonus until you need to demonstrate FIPS 140-2 validation.

GPG is FIPS 140-2 compliant (though pass itself might not be, depending on the specific way it's used). Most likely pass would have to use GPG in a specific FIPS-compliant mode to pursue validation.

GPG has a FIPS mode that will use FIPS 140-2 primitives.

But you'll have a finding an audit in some circumstances as it hasn't been validated. I've seen cases where they'll miss that if it's running on RHEL, but it's a risk.

Re: Pass: A standard Unix password manager

#157
post #101
post #95

Earlier quoted context omitted.

the nonexistent browser support makes it even more troublesome to setup. there is some support on linux systems, but windows is plain out of luck i Really like the idea of pass, but ill never accept copy pasting logins/passwords again. they'll need to be automatically inserted on a matching website. everything else is too much manual overhead for my taste.

In Windows or in general, because pass has a ton of browser extensions. https://addons.mozilla.org/en-US/firefox/addon/passff/ https://addons.mozilla.org/en-US/firefox/addon/pass-manager/

yes, as i said before. there is some support for linux systems. i'm using both linux and windows as well as android. my password manager will need to support and autofill on all environments with at least firefox and chrome.

pass got linux covered (both chrome and firefox), but doesn't really work for winndows.

android is really tiresome as well, as there is no way to skip my long masterpassword in favour of a fingerprint. I know, its not easy to implement that feature securely.

Re: Pass: A standard Unix password manager

#158
I recommend using Pass or Keepass, because we can see the source code. But like all these password managers, you need to synchronize your password vault.

If you do not want to synchronize your vault among all your devices, but still want to have a unique password per site, try LessPass[1]. LessPass is a stateless open source password manager.

Disclaimer I am the creator of LessPass

[1] https://lesspass.com/

Re: Pass: A standard Unix password manager

#159

I use pass on all my devices. IOS, chromebook and cli. I freaking love it! passforios is still on testflight but so good. Only a few issues with passforios: - It forgets my github password everytime i upgrade - I honestly don't like the fact that I can't turn off the pin. 4 digits with unlimited retries. - It can't merge sometimes. I think they should be more aggressive about git rebase

You should be able to generate an SSH key that you can use in your application, right?

If you can't that's definitely gotta be an issue in their backlog. Seems more robust to have a key for an application to connect with that you can simply revoke.

Post reply on HN