Ask HN: Best practices for safeguarding master password in organization?

RE: Sharing.

Nobody should be sharing a password manager account. If this is happening it usually means somebody doesn't want to pay for the seats to have individual accounts. You give each user their own account, and if you need more than one admin, you have more than one admin, but you shouldn't be sharing an admin account.

This would also apply if you're not talking about the pw manager's master password but something more like an AWS root account. That root account needs to exist, but its credentials should be a secret in the password manager vault that is shared with anyone who needs it (based on roles/access rules/principle of least privelege), and you should create additional administrative roles within the system you're securing instead of leveraging those root credentials (as much as possible) operationally.

RE: Bad actors

SSO is the answer here. You use a password manager with SSO integration, and you cancel the person's account the second they depart. At previous orgs they literally cancel the account while the person is still in the building and being walked down the hall to be informed that they're being asked to leave. It's definitely on the cruel side but if you're concerned or wanting to emphasize the security of the data first and foremost, that's what you do.

Both parts of the answer above involve $$$. Most services require paying for a higher tier if you want SSO integration (both on the side of the provider like Google Workspaces and the tool like 1Password), and both require paying for head count.

But this is the answer to "best practices". If there's a financial impediment that prevents you from doing these two things, then you can't use the "best practices". That's the unfortunate nature of the beast, and why there are so many online disagreements about the concept of an "SSO Tax".

EDIT: Lots of comments about sharing the root passwords in general. I made a few assumptions here that I thought were implied but outside of the direct scope of the question, so I'm going to add them here.

- MFA should be required, full-stop, and it should be provided by something connected to your SSO. Okta or Google Authenticator, or even better if you use hardware keys like a Yubikey. There's still risk in having shared access to the root account credentials but this helps mitigate it, as even if the person takes the password with them it'll be much much harder for them to use it.

- Password rotation. That's an obvious one. Just change the paswords every time there's a departure.

- Clarification on role-based access. With shared vaults on enterprise/team plans you can restrict who is able to actually see the items once dropped in to the password manager. You shouldn't expose the AWS Root Account to the whole org. You should expose it to whoever actually needs it, and you should use it as little as possible, that's what was meant by this statement:

> you should create additional administrative roles within the system you're securing instead of leveraging those root credentials (as much as possible) operationally.

As an example, here are AWS's guidelinesn for securing the root account:

https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user_s...

Most of them get distilled down to "don't actually use the root account for anything unless absolutely necessary, and share it with as few people as possible", with nuggets such as:

1. Don't create access keys for the root user

and

2. Never share your root user password or access keys with anyone

The idea being that even though this account needs to exist, you should be providing access at the individual level with the necessary permissions instead of relying on the root credentials at all.

I don't think a solution like this works directly for the specific situation that OP describes, but I do think it's a good solution for an AWS root account at an organization of the size he is talking about.