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

Which password manager are you using? There shouldn’t be any sharing of a master password; each individual should have their own account and own master password.

> And what if that person gets fired or decides to become a malevolent actor

Some of that is covered from a legal angle; they might be able to technically pull it off, but they'd also go to jail for doing so

There might be some open source tools that use https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing, which allows you to set a threshold for a number of people in a group with distinct keys that have to coordinate to unlock them. eg 5 shares and 3 of 5 have to combine their keys to unlock.

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

> but ultimately doesn't there have to be someone who solely controls the changing and sharing of the password, and granting privileges?

Not necessarily. You can set up things so that that requires two persons (https://en.wikipedia.org/wiki/Two-man_rule), or any 3 out of a group of 5, etc (https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing)

The way I'd in principle want to solve this problem (controlling access to root-level resources that don't support delegation) would be with some kind of "escorted remote access" system, wherein an authorized set of people can remotely log into a special browser session that's able to act as the root user, but only with another authorized party watching and monitoring the session and able to kill it, so that no one can act unilaterally. Unfortunately, I'm presently unaware of any off-the-shelf software that does this; I've been vaguely thinking about doing it as an open source side project.

Use 1password (or similar) so there is no master password?

You can have 2 trusted people be administrators of the 1P account. Then you create a shared vault for anyone who needs access to the master credentials and store them all in said shared vault. You can have multiple vaults with multiple different sets of credentials and access (Ex a vault for HR is going to have different creds and people than a vault for DevOps). Note: The list of administrators and the list of people with access to the shared vault doesn't need to be the same people.

If someone who's in the trust circle quits or gets fired, you have someone else remove their access (just like any other offboarding) and go change the applicable credentials.

As for insider threat, there isn't a lot you can do if you give someone access to the credentials. For the admin, that should be easy - certainly, you can find 2 people in an organization who can be trusted implicitly (even if one of them is required to be the CEO/founder). If you're worried that someone is going to go rogue, then don't give them access to the information in the first place.

There is some stuff that just doesn't need to be broadly shared...lets say master passwords for AWS accounts. Really very very very few people will ever need those - mostly for "Break glass in case of emergency" purposes, right? So your Director of DevOps has access and maybe one other person. If you can't trust that Director of DevOps to have those credentials.... well honestly your organization has bigger issues.

To add on with another question, are there systems (like password managers, or others) which have "double password" as a first-class feature? For instance, a hacky way could be if personA knows passwordA only, and personB knows passwordB, and the literal password for a system is the concatenation "passwordA + passwordB" - you could get that if both people sat at the same keyboard (or did something else annoying), but a password manager for instance would need first-class support for that feature to be able to have the two individuals launch a shared session to enter both passwords. Or I would even love a system where if at least 2 out of 3 people entered their passwords it launched a shared session: no one single point of failure either for compromising a person or for that person getting hit by a bus.

You give a few people at the top the master password. Typically it would be a director, a VP, maybe a CTO or CIO, in addition to whatever "low level grunt" has to actually carry out actions using the passwords.

For larger companies, you'd use CyberArk, so you can grant roles, get audit logs, use a HSM, etc.

Having one password that unlocks all the other passwords means one password hack lays everything bare.

What I've seen in most companies of that size is that the CEO or founder holds the master passwords and everyone else uses IAM or OAuth or equivalent.

AWS recommends actually throwing away the root key after you grant full access to an IAM user. In the rare case you need it, you can recover it via support.

But generally speaking a password manager with built in credential sharing is your best bet. In most cases the CEO would own that account, or in a good org ownership is shared and/or split amongst a few top execs.

But if you want a model to not follow, don't just share the AWS root key with all devs. That's what we did at reddit when we first started, before any best practices existed (And before IAM existed).

Shamirs secret sharing?

Split the secret into 5 pieces and require any 2 pieces to recreate the master key. Give the five pieces to senior managers or technical resources.

Regenerate the secrets whenever someone leaves.

Store the encrypted secret in a folder where only the five users can access it, and access is logged to cybersecurity.

Or, print it and store it in a safe in an access controlled room.

Don't share a password between people directly. Separate identity and authorization. Keep an audit log. Use a password manager to share passwords that you absolutely have to share for some reason. Avoid this as much as possible and use OAuth/SAML everywhere you can for humans and something like Vault for machines.

At my organization, to protect a private key, we split it into three where any 2 of the 3 founders can decrypt the key if they combine their own passwords, there are tools everywhere to do this, but we rolled our own (basically do all the encrypt_a_b, encrypt_a_c, encrypt_b_c which encrypts with both passwords, and use that to decrypt for each pair)

We rely on game theory and tamper proof audit logs.

100% of the things done to access/modify our secrets & infrastructure are logged in our cloud ecosystem in a manner completely outside our control (AWS or Azure hold the log). We cannot delete or edit these. All we can do is read them and receive reports or alerts.

If someone with global admin decides they want to become DBA over a highly-sensitive SQL Server instance, nothing would actually stop them from acquiring this access. We aren't protecting nuclear material or other defense/life-safety-critical items. If someone wants to risk their career to do the wrong thing with our data (or our customers' data), then I say go for it. I will lose exactly zero sleep terminating someone who does something that stupid. Our policy isn't even explicit. This is one of those "if you have to ask, you shouldn't be working here" kinds of things.

Fear is a much more efficient tool than key splitting schemes, physical vaults, armed guards, etc.

The Qubes OS team stores their Master Signing Key on an offline machine (running Qubes of course) and use it to sign the keys of the team members: https://www.qubes-os.org/security/verifying-signatures/#how-...

The developer signing keys are set to expire after one year, while the QMSK [Qubes Master Signing Key] and RSKs [Release Signing Keys] have no expiration date. The QMSK was generated on and is kept only on a dedicated, air-gapped “vault” machine, and the private portion will (hopefully) never leave this isolated machine.

Alternatively one could use split-gpg, but it's probably a tiny bit less secure: https://www.qubes-os.org/doc/split-gpg/.

See also: https://github.com/QubesOS/qubes-issues/issues/2818

Use secret vaulting, never a shared password manager.

For ultimate offline secrets like HSM, CA, or crypto private keys, buy new printers, print the secrets as QR codes and keep them in safety deposit boxes at 2-3 different banks.

For passwords you don't want any one exec to have, use N-person keying by splitting 1 or multiple keys into pieces such that a quorum of 2,3, etc. are needed to utilize the secret.

The only password I know by heart is Bitwarden master password, and if MacOS would let me skip it typing it for weeks (say with some kind of biometric authentication) I'd be toasted by now...

(Ok to be honest is related to a book I have in my room, so I feel like I'd at some point remember it when desperate...)