Hacker News Reader

Comment by meepmorp | Hacker News Reader

> Adam says the attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee, and gained root administrator access to all Ubiquiti AWS accounts, including all S3 data buckets, all application logs, all databases, all user database credentials, and secrets required to forge single sign-on (SSO) cookies.

A root user user breach, seemingly on the organization main account. Ouch.

I wonder if MFA was set up, with the TOTP creds also kept in LastPass.

View on HN

This boggles me when I see this option in any password manager (and I think every single one has this 'option').

Why do password managers let people store TOTP next to the password, this completely invalidates the 2FA of TOTP if your password manager get broken into.

> this completely invalidates the 2FA of TOTP if your password manager get broken into

I think that's the big "if". If you assume the password manager is secure (which something clearly wasn't in this case, but that seems like an outlier), TOTP secret in the password manager still secures the account.

Is such a setup as protective as a separate storage method? No, but it's leagues more convenient. A cloud-based PW manager also solves the problem of a lost/broken/new phone causing you to lose all of your 2FA setups. Some 2FA apps do as well (Authy, iirc), but trust me when I say people lose 2FA codes _all the time_. And then 2FA needs to be disabled by support, which is its own can of worms.

The best security measures are the ones people actually use. If not having to use a separate app is the convenience people need, then I think it's totally worth it.

You know what's also convenient? 1FA.

Which, incidentally, when you store you TOTP secrets with your passwords, is what you have.

I mean, if the password manager’s store is compromised, then sure, okay. But if only the application password is compromised then it’s still 2FA since the attacker cannot authenticate with just the password.

I see what you're saying, but I disagree.

The F in 2FA is factor. Satisfying one login request from one factor (password vault) is 1FA. This is why the second factor is normally something that isn't your password vault (historically your head, now a piece of software): a hardware key, a recovery code, etc.

A slightly more generous interpretation is 1.49A (rounds down), because someone with a reused username/password combination. But if you're using a vault with a sophisticated factor, the venn diagram of "people who have your password," and "people who also have your master password," are pretty tight, except for cases where the provide has been breached (all bets are off).

Don't dispose of the second factor for convenience.

And the A in 2FA is authentication, not storage. The password vault is not a factor because it is not what is provided for authentication, the individual password is the factor. The fact that the vault being compromised reveals both factors does not make it no longer 2FA.

Colocating the storage factors definitely makes certain attack vectors possible that aren’t otherwise possible, but it’s still 2FA. Are hardware keys best? Likely, but still many probably have their password vault and TOTP application and storage on the same device (e.g. both Bitwarden and Authy on their mobile device) which is a middle-ground convenience vs. security between TOTP in the password vault and hardware keys—but I doubt many would say that it’s not 2FA.

Because I already use MFA to access my password manager in the first place, and don't want to deal with managing backups for each flavor of MFA app that is pushed on me.

How do you manage MFA for encryption-at-rest? None of the common TOTP systems do this. LastPass and 1Pass have built-in "local encryption keys", but they're stored in the same place as the store and only protected by your password. I think theoretically you could set this up with Keepass using a Composite Master Key (combining a password-protected key and a certificate-protected key, storing the certificate separately, ideally in an HKM), but I don't know anyone who does this.

> Why do password managers let people store TOTP next to the password

One absolutely invaluable use-case is that it lets multiple employees share access to an account with 2FA enabled.

Many systems don’t have appropriate role/permission systems to allow for 2FA otherwise.

The alternative is to navigate 100 separate token reset processes if you ever lose your phone and all of its TOTP tokens.

Or just keep them somewhere that isn’t directly beside the password?

I have my password in a password database, and my TOTP tokens on my phone and a Yubikey.

I have a second “break glass in case of emergency” password database that contains TOTP secrets for all my most essential accounts and a backup of the key loaded on my Yubikey.

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