[dljsjr]

Others have already mentioned that you shouldn't be sharing a master password, and that's definitely true. I'll try to answer the question more holistically:

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.

[arghwhat]

Even without SSO, a bitwarden team subscription let's you administratively revoke organization access at negligible business cost.

Note that revocation is insufficient to protect current passwords: The user may have made a copy. For that you need password rotation and second factors like a hardware token.

Regardless, shared credentials should be reserved for when there no other solution is technically possible. At the very least when shared credentials cannot be avoided, try to split it into multiple domains - read-only vs "production open heart surgery", devs vs prod admins, automation vs humans, etc. For automation, always make new tokens for each use - and never store them, as you can always make more. Consider only issuing credentials to people upon request, and revoking them after the fact. There are many mechanisms to reduce risk.

[ameliaquining]

Re: root account password in a password manager vault. The problem with this from an enterprise-security perspective is that, once the password has been shared with somebody, it's difficult to prevent them from later using it in a way that's not authorized, or accidentally disclosing it to someone who shouldn't have it (e.g., by having their machine compromised). I suppose that a TOTP secret or FIDO/U2F dongle doesn't necessarily have this problem, though, so you could maybe rely on that rather than the password as the primary security factor.

[dljsjr]

If you're not using an MFA mechanism attached to your SSO (Google Authenticator or Okta or something) then that's a completely separate issue. There shouldn't be that much risk in letting all of your SRE's have access to the root credentials; you can lock down who can see what in your vault based on roles for any PW manager worth anything.

You could also rotate the root password every time there's a departure from the teams that have visiblity if it's that big of a deal.

[ThePowerOfFuet]

Very well put together.