Comment by lucb1e | Hacker News Reader

Comment by lucb1e | Hacker News Reader

Parent Full thread

This is fun if you never leave yourself, but be wary with whom you share it. As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly. (Or none, if you can't be bothered.) (Don't ask.)

Or if someone newly needs access, there's no standard way of re-encrypting the files you're guessing they need. You need to hack something together yourself

It uses git, but the commit messages are autogenerated and useless. It might as well have used Dropbox for all the use you get out of it when wanting to find the version before someone corrupted data with their somehow-broken gopass client

There is no way to ever erase anything you've accidentally pushed, short of rewriting the git history and breaking it for everyone (or for personal use: other client devices)

It looks nice and simple, and I like that I can interface with it with manual tools (e.g. write my own commit messages to have some idea of wtf is going on, e.g. when mass-reencrypting to not have 300 commits), but the simplicity is also the pitfall. Feels a bit similar to using hash(site_name+main_password) as a per-site password: beautiful in simplicity but various practical issues

Does anyone have good experiences with a password manager for a corporate environment? Ideally not having yet-another service to maintain, but also not have a server compromise equal business compromise (so end-to-end encryption between the users; verifying fingerprints or some such). From what I found so far, Bitwarden seems to meet that bill but I don't know if there are also others

> As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly.

You can setup different directories to use different keys, and you don't need to limit yourself to a single key for each password either. You can use multiple. So you can setup structures like:

- admins/.gpg-id "admin\n"

- techs/.gpg-id "admin\ntech\n"

where admin and tech are 2 keys for different groups of people. Admin having more access. Or even better:

- site_foo/.gpg-id "bob\nalice\n"

- site_bar/.gpg-id "bob\nrobert\n"

where each employee has their own key. So you can fine-tune which passwords need changing if an employee leaves, and which passwords an individual employee needs to be able to access.

You can setup git submodules to control which passwords which employees can know to exist.

And given that git is being used, you can know which passwords an individual employee ever had access to, were their access to change over time.

"having access to" is not the same as having opened it, though. A server could log which files were retrieved without knowing what the contents are

By having such audit logging, we could see that we e.g. don't need to call the alarm company to change the phone password. Most people don't work in the office outside of business hours and so never need to call them, but since it's the only way of proving you're an employee if you accidentally set off the alarm, we give everyone access to that password. There's at least a dozen examples like that

My current employer uses 1password and it has a couple of nifty features like "vaults" shared with a group of people, an "op run" command to inject secrets using a .env file, service accounts to fetch passwords in CI, etc.

It has dev environments now too! https://developer.1password.com/docs/environments/

Sounded nice, but I'm not sure what this actually adds. I'm currently using 1Password for doing "environments", but it's all using the existing `op` CLI.

So adding a new collaborator to the project would involve adding them to the vault, then there is a shell script in the project that uses the CLI to write a new `.env` depending on the values from `op`.

Seems like this new environment stuff wouldn't add anything compared to such setup, at least today, is that fair? Seems to be even more manual and require copy-pasting, unless I misunderstand what the feature actually is.

Yeah, I think the idea is instead of writing a .env you would, perhaps eventually, have a command like op that just loads the environment whole cloth. But you probably won't get much value out of that today.

for a complete solution to dev envs and production secret management I use Envie https://github.com/ilmari-h/envie it's like a drop in replacement for traditional env files

I have no practical experience yet, but i evaluated the market for a password sharing solution for a team with similar requirements within an enterprise.

Another option in that area is https://www.passbolt.com/

It uses a public/private key approach, where the plain passwords never leave the local machine and shared passwords are re-encrypted with each users public key.

Bitwarden is pretty usable, we use it at our org, and while still has a rough edge or two for corporate use, gets better all the time.

My and my buddy have been using “pa” for our company with great success: https://git.j3s.sh/pa

It uses age and allows you to use multiple keys for encryption

I think one could build something nice on top of FOKS (https://foks.pub).

I agree

Reply on news.ycombinator.com