In the last post we established that password maximum length limits are good if they are set at a reasonable limit. They enable testing to ensure that passwords can not be set to longer than your systems (infrastructure, libraries, hashing algorithms and your own code) allow. Lets look at the restrictions used by some Australian Banks and determine what steps to take to bring them in line with the OWASP recommendations for password length.
To start we need to know what the current rules and limits are. I found the length restriction for 8 banks and have summarized the information below.
Password Length Limits
| Bank | Input Field Limit | Password Limit |
|---|---|---|
| ANZ | 16 | 16 |
| Bankwest | 16 | 16 |
| Bendigo Bank | 8 | 8 |
| BoQ | 255 | 20 |
| Commonwealth Bank | 16 | 16 |
| Macquarie | Unlimited | 256 |
| Suncorp | Unlimited | 8 |
| Westpac | 6 | 6 |
Note: NABs password tips page flexes on the ability to set a 17 character password. As I was unable to find their password rules I have left them out from this list.
Grouping Them
We can split the banks into several groups:
Those that have a low max length and a limited input length:
- Bankwest
- Bendigo Bank
- Commonwealth Bank
- Westpac
Those with a low max length and a higher input length:
- ANZ
- BOQ
- Suncorp
Macquarie Bank, which is already in a good position
Going from Low to Woah!
To increase the length limit we are going to need to make some changes. Our assumptions for doing this are:
- Passwords are currently stored hashed
- Your password is not sent to an ancient mainframe (with a low rate of change and a high cost for change)
- There is no technical limitation preventing a higher password limit
- There is only one system uses the password
Low max length and a limited input length
The first step for working towards a better state is increasing the length of the password that that can be entered on login. If we started with the password set and change screens instead, then users would be able to create passwords longer than they could log in with. This would cause issues. Increasing the login screen limit can also cause issues.
Take, for example, the password: "bankpassword123456" (18 characters)
Imagine that this is my internet banking password.
It is what I typed in when I registered and it is what I type in every time I go to log in.
But my bank only has a 16 character password limit.
When I first set my password, I typed in those 18 characters on my keyboard. The field length limit stopped the last two characters from being entered. Then only 16 characters out of my 18 character password were sent to the server. Their login screen also limits me to 16 characters. I type in 18 characters every time and log in fine though. To me, 18 characters is correct and 16 is not.
What I type: bankpassword123456
What I see: ****************
What the server sees: bankpassword1234
So how do you increase the password field length when users may be typing in characters that your server does not see? Passwords are not stored in plain text so you can not identify the affected users ahead of time. You will need to determine a plan to handle this case.
You might think that this is an edge case. I have seen a poorly handled removal of a password length restriction. It caused chaos. Users were unable to log in and they had no idea why. There were hundreds of calls to the support line from users trying to log in. In the end we had to reinstate the limit to restore some order.
Your options include:
- Attempting to communicate with every customer
- Spend time determining which customers will be impacted
- prepare for an increase in calls from users who are locked out
Once you have chosen your option and spent time planning, then you can get to executing it.
This is a lot of work for no new features, enhancements that users will notice (unless they are somewhat technical) or significant security benefit (given what banks are already doing on top of passwords for security). Banks are revenue driven businesses. Getting changes made requires a legal obligation or benefits that outweigh the costs. Increasing the password length is neither at the present time, so these first group are unlikely to make changes.
Low max length and a higher input length
Any bank that passes the first barrier gets into easier territory with this next group. What users type in is what gets validated. Anyone with the password "bankpassword1234" already fails to log in if they type in "bankpassword123456". To make passwords longer you need to increase the limit on your password change, set and login fields. You also need to ensure that you do not move back in to the first group, where the max input length equals the max password length.
And that is it. You are done. You have made the change. Get to testing and prove that there is not a security appliance in the middle of yoour network that expects short passwords.
Conclusion
There is a lot to think about before making changes to your password rules. Making changes to them is not as easy as increasing the length of your username or name fields. You need to be aware that your users do not count how many characters appear in the password field. You need to know about every system that sees your users passwords. Every system that has it's own login screen will need to go through these changes together. Only once they are all ready can you increase the max length that you allow users to enter.
Next time will be about centralizing your password screens or about why password rules are so bad in the first place. I have not decided which one yet.
Top comments (5)
I might have missed it in the article (or previous one), but could you maybe mention that the maxlength attribute is a client side imposed limitation (which can be bypassed/increased) and might not even match the server side length input validation? So people reading are made aware they shouldn’t depend on this attribute at all? It may be obvious to us, but for other devs starting out, and based on the From/To image at the top, it may not.
I can definitely make that clearer in this post. The last post talked about the max length across systems (including the final server) and doing validation there.
Then divide it by three for password change pages. And then test that it works through every single piece of infra between the edge and your servers. And sure, then you can do that. But is that really adding that much actual security over 256 character passwords?
Did you read the previous post in this series? What's your point?
What would you suggest to be a suitable password max length then?