Best practice on AWS is to not use the root user account. This post will talk about how to avoid using it, and how to manage the credentials (password and MFA) for the root user effectively.

Why not use the root user for everything?

One of the main reasons why avoiding the root account is listed as a best practice, is to avoid the situation where an account has not created any IAM users or roles, and they are just using the root credentials for everything, including having all employees login with the same password to the root account. This makes it hard to understand who has done what in the account, or to rotate the password, and lot’s of other bad things.

So let’s assume then that they’ve created IAM users for the different employees, but they all need to do lots of things so they’ve been given * privileges. Best practice is to use least privilege, but everyone has at least some users that need to be able to do lots of tasks. So let’s assume 3 employees have IAM users with full admin privileges, and one user is using the root account as their daily driver.

This has helped with accountability somewhat, but when compared against an IAM user with * privileges, a root user still has a couple of extra privileges that are listed by AWS on the page AWS Tasks That Require AWS Account Root User. Access to the root account in this situation is most important for rare tasks, so having a single user using that account, results in a SPOF (single point of failure). So other users need access to that person’s credentials, which again has reduced accountability.

It is better to have all of these employees using IAM users or roles, and then have alerts whenever the root credentials are used, as this should be a rare event. The actions of the root user can then be audited more easily. These alerts could be made more critical if the root user ever steps outside the limited use cases that only the root user should be used for. For example, if the root user ever lists S3 buckets or starts an EC2 instance, you might start paging people.

The root user also has certain limitations which result in reasons to avoid it. One limitation is the root user cannot use the Secure Token Service, which means it can’t assume roles. This means if you have multiple AWS accounts, you can’t assume roles into the other accounts from the root user. Additionally, one great practice is to make your users have read-only privileges until they assume a role that grants more privileges. Ryan McGeehan has a great post on this technique title Securing Local AWS Credentials. Using that technique is not possible with the root user.

Another reason not to use the root user is that you should use SSO for your users so you have a central place to create or deactivate employee accounts and roll passwords. You should ideally not have any IAM users in your accounts. One reason for this is IAM users have access keys that don’t expire, and access keys end up on github. Evan Johnson at Segment wrote a great article explaining this in Secure access to 100 AWS accounts. The root user can’t be connected to SSO, so that’s another reason not to use it.

So hopefully I’ve convinced you why you shouldn’t be using the root user, but now you’re wondering how you can still give users access to it for the rare situations they might need it, including Disaster Recovery reasons.

How to secure access to the root credentials

You want to setup MFA (multi-factor authentication) for the root user. You have two options:

1. A hardware token.
2. A QR code you can scan on your phone and use with an app like Google Authenticator.

Hardware tokens

The hardware token route ensures someone needs to physically go to your building and open a locked cabinet or safe in order to log into the root account. Some people view this as the most secure route, but it also has problems:

1. If it’s a holiday and the site breaks somehow such that access to the root account is needed, someone has to rush to the office to get the hardware token to login, resulting in added downtime.
2. If you have remote employees, they can never get access (not without flying in at least).
3. You can only have one hardware token so for some disaster recovery plans, this becomes a SPOF if your office burns down or is otherwise not accessible.

QR codes

The QR code on the other hand has the danger that it can printed off and copied around or leaked on the Internet, or stored as a screenshot alongside your root password somewhere, turning your two-factor auth into one-factor auth (ie. access to the location storing both the password and QR code).

Some people don’t realize that the QR code can be captured by multiple phones, or printed off and stored in a safe so that it can be converted to an MFA code by anyone at any time. It doesn’t require you to capture it only a single phone. The QR code also is just a representation of a string, called the seed value, that can be saved in a text file instead.

To get the string representation, when you create the QR code in the web browser, you’ll see this screen:

By clicking on that link highlighted in red, you’ll see the text representation of that QR code:

You can then store that string somewhere and to get the MFA code, use the following python code (replacing the string value with your own):

#!/usr/bin/python
# https://github.com/pyotp/pyotp

import pyotp
totp = pyotp.TOTP("MW7RZK6UJ3FMC7IOSV7NEIC3HJH2K2CS3MVZEYYLJWDKPVVIWDAZM3QYPONT4COJ")
print(totp.now())

Running that, it uses the string as the seed value along with the current time, in order to generate the 6-digit string, such as 927593.

Sharing the MFA effectively

The MFA code solves two problems:

1. Ensures that the password has no value unless you also have the MFA code.
2. Ensures that access is only being granted for the limited time that the MFA code is valid for.

Therefore, ideally you’d have a service that people can access to get only the MFA code and not share the seed. So you might store the root password in a password sharing service such as LastPass, and then to get the MFA code they might access some service. This ensures an audit trail of access and ensures they can only use the MFA code provided for a limited amount of time.

Least privilege

Once the root account has been secured, you should begin looking into reducing the number of admins you have in your account. CloudMapper’s find_admins command can be used to identify all of the users and roles that have admin privileges either directly or through possible privilege escalation paths (read more here).

To identify the minimum set of privileges your users are actually using, you can then use CloudTracker, described here.

Account recovery on AWS

I’ve seen a lot of people plan out intricate processes for access to the root password and an MFA device, without considering the other ways the root account can be accessed.

If you have access to the email associated with the AWS root account and the phone number, you can remove the MFA requirement on the account and reset the password within a minute.

Let me restate that: access to the root email and phone number is equivalent, if not more powerful, than the root password and MFA!

Most companies associate the root email with some sort of group alias for their devops teams, because AWS communicates to AWS account owners through that email. So if the email of anyone on your devops team is compromised and an attacker can get access to the phone, they can takeover your AWS account. They can change the password so that you can no longer login with the password and now worthless MFA device that you have, such that you then need to try to perform the same account recovery process.

This is important to understand because your AWS credentials are under your control, but this account recovery process steps outside of things you directly control. For example, does AWS use TLS for your emails? Depending on how your email is setup, AWS may send this account recovery email as plain-text across the Internet. Phone numbers can also be hijacked. This may be outside your perceived set of threats, but is important to realize (and to yell at AWS about improving!).

For cases where the email or phone cannot be accessed, there is process for account recovery involving faxing a notarized document (this document). Getting things notarized and faxed is easy in the US, with every FedEx and UPS store offering those services for a few dollars, along with many other places where this can be done.

I’ve also heard reports that accounts can also be recovered by TAMs, which opens up social engineering attack vectors.

None of these account recovery paths can be disabled. This is one of the biggest security weaknesses with AWS, and I hate to discuss it publicly like this, but hopefully this will result in more customers contacting AWS and motivate AWS to do something better.