Hacker News Reader

Comment by liaukovv | Hacker News Reader

What is the right way store credentials to something like this?

Hardware keys?

The root account credentials should be used to create a privileged IAM user and then physically locked away in a box after setting up a hardware MFA device (plus a backup MFA) for the root account: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi...

The privileged IAM user should then be used to administer other IAM users and roles. All IAM users should be required to have hardware security keys like Yubikey.

> (plus a backup MFA)

IAM doesn't even let you register more than 1 MFA device.

I have accounts for personal use and what I did was set up TOTP for the root account(s) and a U2F (YubiKey) device for the admin account(s). I use 2 YubiKeys; one primary, one spare. The YubiKey has limited TOTP space, but they're perfect for those types of high value accounts. You store the TOTP on both, so if you lose one you can use the root account to fix the admin account.

If I were a CISO solving this problem today, I would just use TOTP instead of U2F, and store the secret in two places.

Longer term I expect AWS will add this capability.

AWS SSO does now, thankfully.

But how fast a determined attacker will be able to utilize acquired physical key?

Is something like kidnapping in the threat model for companies like ubiquiti?

> Is something like kidnapping in the threat model for companies like ubiquiti?

I doubt it. That's going to raise some blinking red flags on the radar of organizations you don't want to be on the radar of. Not just three-letter federal organizations, but three-letter news organizations too. The current situation is Yet Another Security Breach that will be forgotten about in 15 minutes. But a kidnapping is interesting! People will be making documentaries and shit about that.

It's so much easier and cheaper to bribe people than it is to kidnap them.

Those kinds of fanciful things are not commonly in threat models because they don't happen. The threat models address things that are likely to happen, which are all variations of someone's device getting compromised.

For AWS root account?

Generate a long random password, print it out and then lock it in a safe without allowing anyone to see it.

Turn on 2FA and then lock the second factor in a different safe.

There’s virtually never a need for the root account and it’s impossible to attenuate (by design).

Printing out the AWS root password and putting in a safe is almost useless. Root password can be easily reset without MFA by having access to the email associated to the root AWS account.

MFA is the important one to keep it safe for AWS root accounts, set for the master AWS account and lock root access for all member accounts via SCPs.

This is a lot harder to do if you have lots of AWS accounts and create new ones over time on-demand (e.g. AWS account per team).

Use Organizations. If you’re creating new standalone independent accounts for teams you’re just seeking yourself up for some kind of billing/security/governance catastrophe down the road.

I was referring to the root accounts in your organization. The blast radius is more limited, but still a root account that has access to everything within that AWS account.

You can restrict what the root account can do in a member account using SCPs as an additional safeguard as well.

AWS root user accounts are kind of an achillis heel in every enterprise setup using AWS. What you typically do is MFA (bare minimum) + sharded secrets. This means you need multiple people to use the root user account. You can also hook in additional audit controls eg by automating cloud watch and sending notifications about any root user login. Alternative is that you throw away the password and vow to never use it, or set up an account recovery process (all of this may not be a great idea as it can fail when you need it most).

The situation is somewhat more relaxed with GCP Billing Accounts and Azure EA Accounts, though they have better separation of concerns than AWS (billing vs. workload access). Nonetheless, never give these passwords to finance department lest they store it in an excel sheet on a SharePoint. Access to these credentials allows anyone to suspend billing for an entire enterprise... not sure what controls the providers have in place to verify any of this before initiating automated shutdown of all workloads.

I use a Yubikey, personally.

Hardware keys should be used to store stuff like:

- private keys for ssh, gpg, vpn auth

- 2fa for sudo access, password manager access, etc

Reply on news.ycombinator.com