Pass: A standard Unix password manager
191–200 of 212 posts
Re: Pass: A standard Unix password manager
#192Alright 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)
Re: Pass: A standard Unix password manager
#193I 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/
There is no need to put anything on someone else's computer.
Re: Pass: A standard Unix password manager
#194Earlier 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/
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
#195Earlier 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…
Re: Pass: A standard Unix password manager
#196Earlier 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.
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
#197Earlier 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…
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
#198I 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
#199Earlier 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
Re: Pass: A standard Unix password manager
#200Earlier 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…