How to manage IAM user passwords
What controls an AWS account admin has over user passwords
As an AWS account administrator, how IAM users manage their passwords is a black box. You can not see if they use secure practices to make sure an attacker can not impersonate them. AWS offers a few tools to gain insight into this process and allows some control over what is allowed as a password and how long each one can be used before setting a new one.
In this article, we'll look into these reports and controls that help enforce secure practices.
Logging in
When you, the administrator, create users you'll see the IAM users sign-in link on the IAM page:
This is a URL that contains the account ID:
https://<account-ID-or-alias>.signin.aws.amazon.com/console
When IAM users sign in, they need to know which account to sign in to, and using the above link fills that part automatically. When you create users you need to communicate this link.
Reporting
First, let's see what information you can get for how users use their passwords! This can give some insight into how to tweak the policies.
When you list the users on the IAM page you can see how old their password is. This is a good starting point if you want to check password rotation.
Apart from the password age, you can see when it was used last time:
For a better overview, you can download the Credential report, which lists all users, when they used and rotated their passwords, among a few other things.
It downloads a CSV file, containing several columns for the users. Apart from clicking a button on the console, you can automate this using the CLI also.
Password policy
The Password policy is the primary control over what passwords the users can set. You can find in under the Account settings, and as you can guess this is a global setting for the account. You can't enforce different rules for different users.
There are a bunch of settings here, all serious-looking that limit what users can set as their passwords.
The form starts with requirements for the password itself, such as size restrictions and required character classes (lowercase, uppercase, number, special character).
This seems reasonable, but none of this prevents the common corporate passwords, such as Pa$$word12 that ticks all the boxes yet it's a weak one.
The second part of the form specifies password expiration. You can use this to enforce rotation. The most interesting option is the "Password expiration requires administrator reset" option. This can be useful when someone leaves the company but somehow the account is not deleted then it will be inactivated after a set amount of time. Also note that access keys are not affected by password expiration, so that a key created will be usable even after the user is unable to log in.
These are the possible options, let's see what are the recommendations! The NIST is the official body that looks into what service providers should allow helping users manage their passwords securely, and it has these recommendations:
Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets.
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).
According to the NIST, all but the length restriction should not be used. To be fair, password strength is more important for offline cracking which is unlikely to happen with AWS IAM. But I'd love to see an option to disallow known leaked password, for example those contained in the Pwned passwords database. The NIST recommends this too:
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
Another problem with the password policy is that users don't see what it is. The UI only tells that your password does not comply, but it does not help you how to make it work:
The password policy enforces the rules when the password is set, so if you change the composition rules they will be effective the next time the users change their passwords. You can enforce a password reset though.
IAM permission to manage own password
As usual, users need IAM policies to manage their passwords. The iam:ChangePassword is the Action that allows changing the password.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:GetAccountPasswordPolicy",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:ChangePassword",
"Resource": "arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
}
]
}
The ChangePassword allows setting the user's own password. To allow setting passwords for other users, you need the iam:ChangeLoginProfile permission.
Force password change
As the NIST guideline states:
verifiers SHALL force a change if there is evidence of compromise of the authenticator.
AWS provides this on the IAM console for each user:
It is effective on the next login.
Create passwords for new users securely
When you create a new IAM user and allow Console access you need to set the initial password. You can choose between an autogenerated or a custom password. The more important bit it the "Require password reset" checkbox. When the new users log in the first time, they need to change their passwords.
The best practice for new users is to use an autogenerated password and require a reset on the first login:
With this process, if you send the initial password in, for example, an email, after the first login it won't be a secret anymore and only the user will know the password.
Conclusion
AWS allows some insight into how users manage their passwords. The most detailed is the Credential report, which lists all users and gives information about when they last changed and last used their passwords.
On the enforcement side, the Password policy allows account-wide settings that require character classes, length, and rotation. These are the only controls you have over IAM users' passwords.
Also, you want to make sure only the users know their passwords. To achieve this for new users, enforce a reset on the first login.
