Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 53 posts

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

#31

Post by aerojoe23 »

redder23 wrote: post #27
ShakataGaNai wrote: post #14

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 DevO…

Why would you suggest 1password on any other shitty proprietary crap. Use Bitwarden, its Open Source you can self host it inside the company if you want ... and if they every do something (shady) you do not like you can switch to a fork that will instantly pop up as soon as that happens.

Good point about Bitwarden, and the more we can convert the better. I think we can catch more fly's with honey than vinegar.

What do you think about trying something like, "Good points about using a password manager. I think Bitwarden is better than 1password becuase it: is open source, it can be self hosted, and you could switch to a fork if they get shady."

Because you wouldn't be implicitly calling them ignorant this way, they're more likely to hear your message.

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

#32

Post by ahar083 »

solardev wrote: post #30
ShakataGaNai wrote: post #14

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 DevO…

> Use 1password (or similar) so there is no master password? Isn't there still a "Secret Key" that you have to keep somewhere? It's a long random string, too, so you can't easily memorize it. I always lose this and have to keep it somewhere super-unsafe... it's the weakest part of my security, ironically. https://support.1password.com/secret-key-security/

Each user has their own secret key, so the above still applies (2 trusted users who are admins, each with their own unique 1Password enterprise login + password + secret key)

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

#33

Post by adbachman »

_trampeltier wrote: post #22
yjftsjthsd-h wrote: post #3

> 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

I couldn't find it just now, but there was at least one case, where the admin did throw away the all keys when he left the company. Sometimes strange things can happen if you start having personal trouble, like the boss slept with admins wife ...

There's a thin line between by-the-books malicious compliance "throw away all the keys" and "intentionally destroyed company property". You'd sure want "please delete all our information from your personal devices" in writing.

I can imagine a company whose business is impacted by intentional deletion of data by an aggrieved ex-employee could make a convincing case in a civil suit, even if criminal charges don't stick.

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

#34

Post by jedberg »

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

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

#35

Post by ThePowerOfFuet »

dljsjr wrote: post #6

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 mo…

Very well put together.

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

#36

Post by unethical_ban »

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.

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

#37

Post by jupp0r »

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.

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

#38

Post by thinkmassive »

lsedgwick wrote: post #26
fragmede wrote: post #15

Earlier quoted context omitted.

With advanced/power user AWS IAM roles, it's feasible to eliminate it for day to day uses, meaning that you can have it so only one or two people you trust actually have access to the root creds, and everyone else can go about their business. Shamir's Secret Sharing software, ssss, will let you encrypt a file and split it into pieces so that 3 of 5 people are needed to decrypt. http://point-at-infinity.org/ssss/

Either the site really doesn't support https (odd, since it is the very page that supplies the verification hashes!) or something more scary is actually happening and it's getting universally man-in-the-middled, which feels plausible for a site that offers cryptographic tools for download.

What tools are you seeing offered for download there?

Yeah it’d be better to use https since it lists some checksums, but it was last updated in 2018, and Debian packages are verified anyway.

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

#39

Post by oulipo »

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)

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

#40

Post by bob1029 »

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.

Post reply on HN