[allerhellsten]

Pass is pretty awesome, but nowadays I've switched to gopass: https://github.com/justwatchcom/gopass - much better support for teams, structured secrets, binary secrets and quite a few other improvements. Oh, and it's (mostly) drop-in compatible.

[crypt1d]

Looks nice. Unfortunately I would never use it for teams as it doesn't have audit logs. These are very useful in case a user is compromised - you can lookup which passwords he accessed and only change those. Same goes if the user left the team and u want to make sure all accesses are revoked.

[mi100hael]

For teams, I almost always go with Vault (http://vaultproject.io/)

[joekrill]

My impression of Vault is that it is more useful for automated situations. How useful is it as a shared password manager? Do you have non-technical folks using it? And if so, how are they interacting with the vault?

[mi100hael]

No purely non-technical individuals as far as I know, but there are a number of non-developer analysts using it who wouldn't otherwise have much exposure to a console. The flexibility of the access policies and the ability for users to easily/securely share secrets under a path with only their team and be able to have multiple policies for multiple teams all under one roof far outweighs any minor struggle during initial adoption.

[moondev]

Sounds like a great idea for a side project. Build a user friendly interface that leverages a remote vault server on the backend. It's primary use case if definitely for applications.

[joekrill]

There are a handful of web-based UIs that have been built. And I believe Hashicorp offers one with their enterprise product. But from what I can gather they all still have a bit more of a learning curve than your average password manager.

[zamber]

Wouldn't Keybase's secret shares be better?

[kkirsche]

I really like the idea of vault I just haven't been able to figure out how to setup consul ACLs correctly to use vault on top of it

[jbg_]

"you can lookup which passwords he accessed"

Really? What if s/he just decrypted the file themselves and had a look at the content, rather than using the convenient wrapper that a password manager provides?

[koolba]

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.

[crypt1d]

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).

[benchaney]

You're missing the point. The software has no way to tell if a compromised user looked at certain passwords out of band. The audit logs aren't guaranteed to be complete, so you should rotate every key they could have accessed anyway.

[raides]

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

[crypt1d]

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.

[crypt1d]

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.

[jbg_]

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 auditing, which is exactly the model I believe that most users of `pass` are trying to avoid.

[crypt1d]

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.