The AWS Password Policy dictates the security standards and management of AWS IAM User passwords used for access to the AWS Console. We extend the default policy to increase security and minimise additional processes providing the most efficient password management configuration we can design.
AWS provides identity management services to uniquely identify both human users and system users that need access to AWS resources. For human users accessing the AWS web console or using the SDKs & AWS CLI, AWS provides IAM User entities. Each IAM User requires a unique username and password associated which is used as login credentials for accessing the Web Console.
As AWS Users exist are attached to a singular AWS Account, the AWS IAM service provides an account-wide password policy configuration that manages the security requirements and management of IAM User passwords, affecting all IAM Users in that account. If not explicitly configured then the default AWS Password Policy is used as a stand-in. Whilst the AWS default Password Policy is suitable for most use cases we tend to replace it with an upgraded policy that we believe better protects the security of the account, encourages and aligns better with user behaviour and reflects the sensitivity and risk profile of AWS accounts.
The default AWS Password Policy sets the following requirements:
Our standard password policy implements the following:
The basis for this enhanced policy is as follows:
We recommend increasing the minimum password length to 15 characters. This adjustment significantly improves security against brute-force and targeted attacks that leverage easily guessable passwords - such as short company names combined with predictable sequences like dates or number sequences.
By mandating longer passwords, users can be coached to create passphrases instead of simple words, making them both inherently more secure and usually easier to remember. Short passwords can also encourage lazy password generation such as Company2024 whereas a longer password requirement will guide users to a passphrase of which lazy version are by default more complex, such as IworkatCompanyNamein2024.
We remove the mandatory requirement for special characters. While special characters can still be used, making special characters optional reduces friction for users who may struggle to incorporate them into their passwords and who consequently default to tick-box exercises to satisfy the password requirements such as ending a password with a full-stop, an exclamation mark or a question mark. Special characters often break the flow of a pass phrase reducing the memorability of the phrase and limiting the creativity for users in generating a secure yet memorable password.
Additionally, special characters can be the source of technical issues that can be difficult to diagnose, as special characters can break the interpretation context for technical environments and cause issues when parsed. While this shouldn’t affect AWS IAM User passwords in their regular use case, we don’t like passwords with special characters as a general rule as they can introduce numerous interpretation issues for technical systems should the passwords need to be managed programmatically.
In environments which we freely operate we also don’t require any specific characters to be included. This is for the same reasons but can become more pronounced depending on the character sets. For example, when required to include a digit in a password users responded in an expectedly counter productive yet obedient manner with 77.46% of users simply appending a digit to the end of their initial attempt.
This policy is not often allowed in corporate environments due to policy requirements from internal compliance or external stakeholders such as insurers, but for environments looking to optimise user contribution to security it is best to increase the minimum password requirement to longer length passwords and to remove the requirement to include arbitrary characters that would break the flow of secure password generation.
A key change based on guidance from NIST is to no longer require users to change passwords periodically. Regular expirations may lead users to create weak, predictable passwords that simply consist of incremental changes to their passwords or to utilise chronologically based references such as the year, month or date in their password.
Instead, administrators should have the capability to expire passwords based on specific events requiring resets, making password changes more meaningful and encouraging better compliance from users. We find that users provide more effort in generating new passwords when their passwords are expired in response to a security event rather than stemming from routine policy.
Empowering users with the ability to reset their own passwords provides the fastest route to password resets in case of compromise with the minimal amount of additional systems and communication. Therefore we always allow users to reset passwords as this self-service capability allows users to act swiftly if they suspect their account has been compromised. Without self-service options, users will need to engage with an alternative process which can be slow and unresponsive and will ultimately lead back to activity in AWS that the user could otherwise action themselves.
We advise against requiring hard password resets, where an administrator must intervene to reset a user’s expired password. This process requires an additional workflow outside of AWS’ self service capabilities which complicates workflows and increase the chances of sensitive information spreading via alternative communication channels. Allowing users to reset their passwords independently encourages user autonomy and allows users to rapidly respond to perceived suspicious activity rather than engaging with a separate system.
To ensure users create distinct and secure passwords, we recommend utilising previous password storage to ensure that users do not reuse passwords whether intentionally or not. We find that this engages and guides users to generate unique passwords and stops accidental usage that would otherwise occur. At a minimum we recommend remembering the last three passwords, however, AWS has the option for remembering up to twenty-four previous passwords which allows for a longer protective window. There’s little reason to not utilise this full window so we tend to remember the largest number of passwords as standard.
For both Project Teams and for Organisations we’ve found considerable success in clearly outlining the password policy so that users are aware of what they have access to, what is expected of them and the reasons behind the above password policy decisions. We find that this encourages users to adopt more secure passwords knowing that they’re not needlessly restricted in choosing a password and that their passwords are not regularly discarded as part of a general policy. As users understand the processes and the shared responsibility we’ve experienced better engagement from users during security incidents which require user action.
Making the password policy available for users to review alongside clear actions and instructions has lead to users actively managing their own accounts in a protective manner, responding brilliantly to suspicious activity and maintaining ownership of their responsibilities.
For organisations with multiple AWS accounts, we generally implement a central account for user provisioning. This account consolidates IAM User entities to a single account providing centralised management and ensuring consistent security standards across the organisation. Access to other accounts in the organisation is done via assumed IAM Roles as required for each user. This design pattern simplifies user management by centralising IAM User access, enforcing a single strong password policy and enforcing multi-factor authentication (MFA) at a single entry point.
By limiting users to single IAM User in a single account, monitoring and auditing becomes more straightforward with legitimate login events and other activity originating in the one account. Additionally the number of IAM User credentials is minimised to the smallest possible number, often just one IAM User and one set of Access Keys per team member.
Additionally, this method also allows for standardized roles across accounts, such as read-only or developer roles which are then assumed as per each account’s access requirements by the centralised IAM Users. This also standardises role distribution and eliminates account-specific configurations. Once an account is established, ongoing maintenance primarily involves updating the trust relationships for account IAM Roles rather than managing disparate IAM Users.
A final benefit can be found in the ease of onboarding and offboarding users to the organisation. Removing a user from the central user account effectively revokes their access to all associated AWS accounts. This simplifies tasks such as rotating passwords, managing access keys, and performing general account maintenance.
Once implemented we are able to expand on this architecture to build and offer standardised tooling. This has included a self-service web interface that automatically generates AWS credential and configuration files for technical staff, removing the need to provision their own files. This streamlines the onboarding process by providing users with ready-to-use access configurations, enhancing productivity and ensuring consistency across organisation-wide environments.
We encourage multifactor authentication for all IAM Users but we make it a mandatory requirement for IAM Users that have cross account access via IAM Role assumption. For organisations that follow the above single user account pattern this means that MFA is only required at the initial login prior to being trusted across the rest of the assumed roles.
Additionally, for environments that require additional layers of security we enforce Source IP restrictions which ensure that access to the User or assumption of IAM Roles in the organisation is not possible outside of a select range of IP addresses, such as those on a company VPN or similar.
Our general Password Policy works well for most organisations although it can be expanded on where needed to provide additional levels of security. Outside of the password policy itself is the documentation and the self-service tooling that allows for organisation users to maximise their productivity and engagement resulting in a more secure and efficient security and process posture for your cloud account.
For assistance in deploying this policy, including our custom built self-service tools, feel free to reach out. Our tools are ready-to-deploy and come alongside our SkySiege Cloud Assessment which can scan your organisation’s Cloud accounts to identify any weak password policies.
Additionally, our SkySiege Cloud Assessment tool evaluates trust relationships, ensuring there is no unnecessary lateral movement between IAM Users and IAM Roles across your organization, providing direct visibility as to who has access to what, helping you visualize and secure your AWS environment.
If you are hosting applications on Amazon Web Services (AWS), it is important to consider the impact to AWS from your penetration testing. A key aspect of this consideration is determining whether what penetration testing can be safely conducted on the AWS platform without advanced permission and which testing should be abstained from without prior agreement.
penetration testing cloud aws
