“passwordrules” is a new attribute on an HTML input tag that allows you to programmatically describe your password policy to password generators. For example, that the minimum length is 20, and it requires a digit and an uppercase character.
While password complexity requirements aren’t the best defense, they are commonplace across many organizations and even enabled by default in some authentication libraries. If you have to use a password policy, you can at least improve the user experience by making password generators aware of your requirements.
In this article, I’m going to show you how to use the passwordrules attribute and a few other attributes that can help make the “perfect” new password field. This includes an on-page example so that you can see if your password manager/generator of choice supports the attribute.
The passwordrules attribute
The passwordrules attribute allows you to describe your password policy to a password generator found in a password manager such as 1Password or a browser such as Safari. This allows the generator to generate the correct password without the need for user interaction.
The passwordrules attribute looks something like this:
<input type="password" autocomplete="new-password"
passwordrules="required: upper; required: lower; required: digit;
minlength: 25; allowed: [-().&@?'#,/"+]; max-consecutive: 2">This configuration tells the password generator that the password:
- requires an uppercase character, a lowercase character, and a digit
- must be at least 25 characters long
- is allowed to contain the -().&@?'#,/"+ characters
- must not contain more than 2 consecutive identical characters.
Other options include maxlength and allowing AsciiPrintable and Unicode character sets.
A proposal to the WHATWG has been kicking around for a couple of years, with some concerns addressed (see “Is it worth it?”), and while nothing is set in stone, it seems like a few password generators have some level of support for the attribute.
Try it yourself
See if your password generator is compatible with passwordrules by using these form inputs.
- Length: 12-15
- Allowed characters: digits and special characters
- Length: 25+
- Requires: digits, uppercase, lowercase, and special characters
If your password generator supports this, then you should see it suggest a password that meets these policies. If it doesn't, then you'll either get one that doesn't or see nothing at all.
Password generator support
Support for the passwordrules attribute is a little patchy. I have had good experiences with it using 1Password, as you can see below. However, Chrome’s suggest password created an incorrect password.
Here are 1Password’s suggestions for the above input fields (using 1Password X in Chrome).
If you find any other password generators that support this or have caveats, feel free to share a screenshot in the comments section below.
Are passwordrules worth the hassle?
The worth of password policies that dictate anything more than minimum password length is debatable, and arbitrary password policy requirements often result in users choosing bad passwords or having your site featured on something like password too strong.
Mozilla has taken quite a strong stance and said the passwordrules attribute is harmful, as it encourages bad practices (max length) without doing enough to encourage good practices (min length). Mozilla instead encourages the use of the pattern attribute, which is good for users manually filling out the password field but bad for password generators. That seems like the wrong way round to me.
However, setting a maximum length on the password field isn’t unheard of. The OWASP password storage cheat sheet does recommend setting a maximum password length based on the password hashing algorithm you are using (for example, a max length of 64 characters when using bcrypt).
Another concern is that the “type” of developer who would know to implement the passwordrules attribute is unlikely to be implementing the type of password policy that would disagree with a password manager. However, I would argue that password policies are still common, and many libraries still enable them by default. While you may think it is obvious that password rules do not improve security, remember that it took Microsoft disabling password expiry in Active Directory for business and IT security teams to finally get the message that password expiry might not work.
Should you use the passwordrules attribute?
Yes, I think you should. From a password manager’s perspective, it is better than the pattern attribute, and from a user experience perspective, it is better than being met with an error message or resorting to coming up with a password yourself.
Rather than worrying about discouraging password policies, I’d much rather we try and move away from passwords. In the meantime, we can do our users a favor and write a little bit of extra HTML.
Despite some of the reservations expressed in the working group proposal, some of the organizations they represent have still implemented support for the passwordrules attribute. And since this is a proposal from Apple, you can find a native implementation in the iOS SDK.
To read more about the passwordrules attribute, check out Apple’s validation tooling.
Other useful attributes
To create the “perfect” password creation field, there a few other attributes on the input tag to consider. I expect some of these to be implied thanks to the input type being set to “password”, but there are no negative effects from being explicit. These can also be useful for username fields.
- autocomplete setting this to “new-password” will allow the browser to understand that it is a “enter new password” or “confirm new password” field. This allows for password generation and prevents password managers from automatically filling in an existing password. For a login page, you can use the “current-password” value
- autocapitalize: setting this to “off” will prevent browsers from automatically capitalizing words either through autocorrect or on a virtual keyboard
- autocorrect (non-standard, Safari only): setting this to “off” will prevent devices from automatically correct spelling mistakes
You can also combine these with the minlength and maxlength attributes for maximum compatibility.
Wow, who knew that so much effort could be spent on a set password field!
For my usual readers, my helper library ScottBrady.IdentityModel has an ASP.NET Core tag helper that will automatically generate the above attributes based on your ASP.NET Identity PasswordOptions.