Strange password policies¶
We all have passwords, and the volume of passwords we need to manage is not slowing down. Most of the sites we interact with have some sort of a password policy that forces you to go through a process of trying to create them. I have written about this before.
While I wish these sites would adopt some sort of federation, many of them don't. The ones that don't would sometimes create some strange password policies. Here's my curated list of strange password policies I have experienced.
The common issues I have encountered are
Maximum password length¶
Passwords are typically encoded in a one-way hash, so regardless of how long your password is, the hashing algorithm is perfectly capable of taking that hugely long password and smashing it down to a handful of byes. What it boils down to is the website owner will never need to keep your actual password. They simply store the salted hash of that password.
When a password policy forces a maximum password length, it begs the question - why? Many vendors have been caught out through breaches that passwords were stored unencrypted, and a maximum password length is typically an indicator that the password field in their backend database may be a certain length.
I'm not saying the password length can be unlimited - even the hashing algorithm will start to work much harder if someone were to upload a few gigabytes of password. Let's be generous, and say your password cannot be longer than 10k (if you're concerned about overwhelming the resources of the inbound server).
Specific Special characters¶
SQL Injection is probably still the most prevalent web vulnerability in existence. One way for developers to deal with a SQL injection attack is to restrict the type of special characters that can be sent to a database. The single quote (') is usually one to trick the website into passing code to the backend end database.
When a password policy starts to restrict the type of special characters you are allowed to use in a password, it implies there is some mechanism they're using in the backend to either scan the passwords, or they are afraid some downstream system may break as a result of the password you have selected. Either way, it is not a good sign for the stability and engineering of the backend systems.
I will lump unicode and high ASCII characters in here too. Regardless of what the characters are, the hashing algorithm should simply handle it.
Sites I have encountered¶
Disclaimer : I am not implying that any of these vendors or solutions listed are any less secure. Password security is very much a joint responsibility between the vendor and the user. The sites are listed in an attempt to raise awareness for them to address their policies.
Translink.com.au¶
2024-02-23
I need to get a Go Card, and like most Queenslanders, I head on over to Translink's site to register an account. Being the security aware person that I am, I used Bitwarden to generate a very long and secure password, unique to this site, only to be met by this error message.
- A maximum of 26 character password
I did not test any other password policies.
VMWare Cloud¶
2023-11-18
Head on over to VMWare Cloud to create an account. The items that caught my attention are
- A maximum of 20 characters only
- A very prescriptive list of special characters
- An absolutely no high ASCII characters
