Live data from Hacker News

Pass: A standard Unix password manager

passwordstore.org

191–200 of 212 posts

Re: Pass: A standard Unix password manager

#192

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)

This is a great tutorial in setting up pass on multiple accounts: https://medium.com/@davidpiegza/using-pass-in-a-team-1aa7adf...

Re: Pass: A standard Unix password manager

#193

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/

I use KeePass and I only keep the database on my phone. When I need the database on my laptop, I use kdeconnect to share the file. Which basically uses sftp with a temporary key.

There is no need to put anything on someone else's computer.

Re: Pass: A standard Unix password manager

#194
post #181
post #177

Earlier quoted context omitted.

What's the best way to backup the private key on your yubikey? Do you just generate it on your computer instead of on your device, and then back that up?

Generally a good way to do this is via GPG subkeys. You keep your master/certifying key offline, in your safety deposit box, and load a subkey onto your Yubikey. If the Yubikey is lost, you can easily revoke the subkeys and generate new ones. Here's a nice tutorial on it: https://www.jfry.me/articles/2015/gpg-smartcard/

Thanks for the link. I started reading through that, and it is quite involved. I'm still deciding if it's worth it.

I'm not sure I fully understand subkeys. It looks like they can be used in place of my main key, and I can generate new subkeys from my main key. Is this so I can revoke my subkeys if they are ever compromised? Can other subkeys decrypt my 'pass' files or is that limited to the subkey that generated them? It seems like the existing private key would be able to decrypt passwords in the future even after it was revoked, if the user still had the original files.

Re: Pass: A standard Unix password manager

#195
post #194
post #181

Earlier quoted context omitted.

Generally a good way to do this is via GPG subkeys. You keep your master/certifying key offline, in your safety deposit box, and load a subkey onto your Yubikey. If the Yubikey is lost, you can easily revoke the subkeys and generate new ones. Here's a nice tutorial on it: https://www.jfry.me/articles/2015/gpg-smartcard/

Thanks for the link. I started reading through that, and it is quite involved. I'm still deciding if it's worth it. I'm not sure I fully understand subkeys. It looks like they can be used in place of my main key, and I can generate new subkeys from my main key. Is this so I can revoke my subkeys if they are ever compromised? Can other subkeys decrypt my 'pass' files or is that limited to the subkey that generated the…

Yes -- revocation is just an indicator of the subkey's trust going forward. Once revoked, the user would generate a new subkey and re-encrypt their password wallet. While the git features and multi-key capabilities of pass lend well to very lightweight team usage, the model is definitely best suited for use by an individual.

Re: Pass: A standard Unix password manager

#196
post #195
post #194

Earlier quoted context omitted.

Thanks for the link. I started reading through that, and it is quite involved. I'm still deciding if it's worth it. I'm not sure I fully understand subkeys. It looks like they can be used in place of my main key, and I can generate new subkeys from my main key. Is this so I can revoke my subkeys if they are ever compromised? Can other subkeys decrypt my 'pass' files or is that limited to the subkey that generated the…

Yes -- revocation is just an indicator of the subkey's trust going forward. Once revoked, the user would generate a new subkey and re-encrypt their password wallet. While the git features and multi-key capabilities of pass lend well to very lightweight team usage, the model is definitely best suited for use by an individual.

So a subkey is aware of all revocations from before it was generated?

If I generate 2 subkeys, can they both encrypt and decrypt my passwords? The only difference is that I can revoke them independently?

Re: Pass: A standard Unix password manager

#197
post #74
post #63

Earlier quoted context omitted.

Thats why password managers that do support audit logs (normally) do not provide this kind of mechanism of manually decrypting the file. The only way of accessing passwords would be through whatever interface they came up with.

The password manager of course does not "provide" such a mechanism (I imagine providing a "bypass audit logs" button would not be a popular feature). But if you know the key (the master password, or some derivative of it) and you have the ciphertext then you will be able to get the plaintext. The only way this kind of auditing could be trusted is if all the secrets are stored on the server that implements the auditin…

The whole point of the discussion was to highlight a feature that I was missing here - ability to audit who accessed what.

There will always be a person with admin (or master password) access who can edit logs or bypass them entirely, but this is suppose to be a person who has the final responsibility in the team's 'chain of command'. The audit log exists so that this very admin can monitor the logs for suspicious behavior and clean up the passwords after a team member leaves. Hence, having the ability to decrypt the db with a master password is irrelevant as the master password should only be accessible to the admin.

Re: Pass: A standard Unix password manager

#198

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/

This appears to be very similar to MasterPassword. Do you have a minute to explain to me what advantages LessPass offers?

[1] http://masterpasswordapp.com/

Re: Pass: A standard Unix password manager

#199
post #153
post #67

Earlier quoted context omitted.

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

Huh? Its not reasonable to expect automated password rotation for all shared secrets, especially for external services that a team could use. Some passwords will always need to be rotated manually.

Re: Pass: A standard Unix password manager

#200

Earlier quoted context omitted.

They have a counter option that you can increment which allows you to generate a completely different password for the same site.

But once you did that it wouldn't be stateless anymore as you'd need to connect to their server every time to check on the state of that site's password. This makes it not that much different from traditional online managers where you have to connect to the site to retrieve the password. There is still the benefit that the passwords can't be exposed by a compromise of the service. Presumably it doesn't store your mas…

You also have the option save this profile db locally, or store it yourself manually in a txt file if you really care. That's also necessary if a certain site has password restrictions.
Post reply on HN