Multi-factor authentication or MFA, also sometimes (slightly incorrectly) referred to as 2-factor authentication, is a security mechanism in which an entity has to provide two or more pieces of information to prove authentication for the entity. If two proofs are required to be provided (the most common/popular choice), it is termed as 2-factor authentication, which would be a subset of multi-factor authentication. These proofs can be of various forms, the first of which in most cases is a username and password combination coupled with one additional authentication credential.
Multi-factor authentication is fairly common today. Depending on the company/organisation we are talking about, it could be an optional feature, a mandatory setting, or a forced mechanism.
Some of the most common examples for multi-factor authentication are:
AWS Identity and Access Management (IAM) services allow one to create IAM users, which can have access to resources in the AWS account via the web console and/or CLI credentials. Along with these credentials, AWS provides the ability to add MFA to enhance security for IAM users. The MFA can be in the form of a TOPT (time-based OTP generated typically on a mobile device in an app or password managers) or a hardware key (for example, Yubikey). These keys are then required every time the user signs in through the console along with the username/password combination.
We will look at how to add software and hardware MFA tokens to our IAM users.
Setting up software MFA for an IAM user using the web console can be done by following these steps:
Log in to the AWS management console
Navigate to the IAM services page
Click on the “Users” section on the IAM page
Either click on an existing user or create a new user to add software MFA token to
Click on the “Security Credentials” tab on the user details page, it should currently say “Assigned MFA device: Not assigned”
Click on “Manage” for the “Assigned MFA device” section
Select the “Virtual MFA device” option and click on the continue button
You can use a mobile application like Google Authenticator, Microsoft Authenticator to scan the QR code and set up the OTP or get the secret key to use with a Desktop tool like KeePassXC
Next, use the application that was used to set up MFA in the previous step to enter two consecutive MFA codes and click on the “Assign MFA” button
The “Assigned MFA device” section now shows the ARN of the virtual device added
The software MFA token is set up for the user and will be asked from the next sign-in to the console.
Setting up hardware MFA for an IAM user using the web console can be done by following these steps:
Log in to the AWS management console
Navigate to the IAM services page
Click on the “Users” section on the IAM page
Either click on an existing user or create a new user to add software MFA token to
Click on the “Security Credentials” tab on the user details page
Click on “Manage” for the “Assigned MFA device” section
Select the “U2F security key” option and click on continue
Insert the hardware key and tap the button to assign it to MFA
You might get a browser pop-up asking you to allow AWS to access information about your hardware key, click on “allow”
You should get the following message on successfully adding the hardware token, click on the “Close” button
Now we can see that the ARN of the hardware token added in the “Assigned MFA device” section
The hardware MFA token is set up for the user and the user will be asked to insert the hardware key from the next sign-in to the console.
AWS CLI, by default, does not enforce MFA for executing actions on AWS resources. Additionally, AWS only supports virtual MFA devices for CLI and not U2F security keys.
However, we can create an IAM policy that enforces IAM users to use MFA even while using AWS CLI. The premise of how this works is as follows:
To create this policy and for a more detailed explanation, use this documentation from AWS as a reference. Once the policy is created, it could be attached to the users on whom we want to enforce MFA for CLI operations, ideally, this applies to all users. A better approach, from a management point of view, would be to add all users to a group and attach the policy to a group instead of individually attaching the policy to each user.
Now that the policy is created and attached to the relevant IAM users, we will use the MFA token to generate temporary sessions with STS to work on AWS resources through the CLI. To create a new STS session with AWS CLI with MFA, follow these steps:
aws iam list-mfa-devices –user-name <username>
aws sts get-session-token --serial-number <arn-of-the-mfa-device> --token-code <token>Alongside IAM, AWS also provides the ability to use an SSO (single sign-on) service, which can be used with a 3rd party federation tool/organization, like Okta, to provision IAM resources. Taking Okta as an example, once set up, users can sign in to an AWS account via Okta using AWS SSO without having to create IAM users explicitly.
Setting up MFA for accounts created with AWS SSO differs from how we set it up for IAM users in the previous sections. This documentation from AWS can be used to enable MFA with AWS SSO. While setting up MFA, there are three configurations to choose from:
Multi-factor authentication is an incredible mechanism that allows us to add additional layers of security to our various accounts without (for the most part) having to remember an additional credential or password. This makes our accounts robust to accidental leakage of our credentials, which in most cases are passwords. For an account that has MFA enabled, in case the password to the account is stolen, the attackers cannot log into the account because they do not have all the proofs to authenticate themselves thus keeping our account secure.
Multi-factor authentication can usually go up to 4 separate pieces of information that are required before an entity is authenticated, and with the addition of each layer, it becomes increasingly difficult to break into an account with MFA configured. That being said, it does not mean we should add 10-factor authentication, even if it makes breaking into one’s account virtually impossible because for most purposes 2-factor authentication mechanisms are good enough and it also hampers the user experience of having a tedious sign-in process which could lead to the exact opposite effect as intended when users rebel and stop enabling and using MFA altogether!
While MFA is most certainly a great security control, it does come with one big risk. The risk is what happens if the user loses the MFA device - the phone that had the authenticator app, the Yubikey with the hardware token. Some sites provide you with a list of recovery codes/phrases to allow you back into your accounts in the event of losing access to your MFA device, for example, GitHub. While some accounts would require an administrator to reset/remove the MFA device from your account, AWS is one such entity. This is not to be treated as an excuse to not use MFA, just something to keep in mind. Safely storing these recovery codes is no different from safely storing your password in a password manager and in the case where you need an administrator to reset your account, that is even easier. This is just to ensure that you understand MFA is not a magic bullet to solve all sign-in problems but a great security solution that also has some risks involved.
In this article, we covered what multi-factor authentication is with some common examples, and then we ventured into how MFA can be used with AWS by enabling hardware or software tokens for IAM users to be used along with the regular credentials. Though AWS CLI currently does not support it, we saw how we can still enforce MFA with a combination of IAM policies and STS sessions to work on our AWS resources. Even with services like AWS SSO being used in conjunction with Okta (and other identity federation providers), we can enable MFA with various settings with the recommended setting obviously being to enforce entering MFA information on every sign-in attempt.
Lastly, we talked about how MFA is an increasingly important security control to implement without adding a lot of hindrances (depending on how many layers of authentication we add) makes our cloud accounts and resources exponentially safer. So while we know nothing should be treated as “unhackable”, if you have not implemented it yet, it might be a good time to start enforcing MFA for your cloud accounts and resources as it does increase the overall security of the target system.
This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. If you wish to give your feedback on this article, you can write to us here.