I find it very odd when websites put strange restrictions on what your password can be. I keep noticing it because I tend to use long passwords or passphrases with spaces and special characters in them whenever I can. Some sites don’t allow me to use this type of strong password though by putting arbitrary limit on password length and banning non-alphanumeric characters. Good example here is the Verizon Wireless website that I wrote about previously. But I keep seeing it in other places. Most recently I got a very similar restriction it when purchasing a license for Kaspersky AntiVirus. There were few others that I can’t remember of the top of my head.
The thing is – I can’t figure out why do people do this. Who writes these password validation scripts? What possible reason would you have to ban spaces, special characters and set the maximum password length to be less than 10 characters? Lets think about it for a second.
The non-alphanumeric ban can’t be just fear of SQL Injection and XSS attacks. You are supposed to be sanitizing all the user input long before it touches the database, or gets spit out back to the user in any way. Besides, no one stores plaintext passwords in a database anyway. You hash them first, so it doesn’t really matter what the password is. User can type in a';DROP TABLE users; – who cares. Before it even touches the SQL string, it will look more like 9640e4db48d6707da39310bde10d73ab. So this can’t be it.
You are not saving any space by artificially limiting the password length. The size of a hash is fixed so your password field in the db will usually be 32, 64, 128 bits or longer depending on the hashing algorithm. It really doesn’t matter if the password is 8 characters or 37 – it will still has to a fixed size checksum so why would anyone care about the length? There are no savings and optimization to be made here.
It also can’t be speed. The hashing algorithm is supposed to be slow – you really don’t want to use md5 anymore. You want something slower and more secure. Let’s face it, users usually log in to the website only once in a while, and they probably won’t mind waiting a fraction of a second longer for the hash function1 to finish. When hashing a password sized string, the difference between md5, sha1 or something else is negligible. Things only start to ad up if you try hashing things in bulk – which is exactly what you want. Regular users probably won’t see the difference between a 3 second and 4.5 second page load on login so the only one really affected is the potential attacker.
It can’t be laziness, because it actually takes effort to validate these things. You need at least one additional comparison to detect that password length is over the maximum limit, and probably a regexp or a function call of some sort to weed out the non-alphanumerics. I always said that being lazy is a virtue, not a vice when it comes to programming. This is one of the examples where this rule applies fully. If, out of laziness you only validate for minimum password length knowing that sanitizing and hashing the string will take care of the rest, you actually increase the security of the system.
If you follow the best practices for handling passwords and their storage, there is absolutely no reason to impose this kind of restrictions on the users. As long as you use exactly the same hashing and sanitizing procedure for password setup, and regular user log in, you should have no problems.
Let me give you and example – take two passwords, first of which conforms to the crazy 6-8 character, non-alphanumeric restriction, and the second one being passphrase with non-alphanumerics and non-english characters and then hash them:
|W Szczebrzeszynie chrząszcz brzmi \/\/ trzcini3||a8bc6a13716b57549ccfb017ecf001766748b133|
The example above is just a straight SHA1 hash, but you should naturally be adding salt while hashing. But this illustrates my point exactly. The first password is a joke, that can be defeated both by simple dictionary attack, and by rainbow tables. The second one is virtually impervious to both these methods. But once you hash them, they all take the same nice fixed length format that is easy to work with. There is just no excuse for rejecting the second password and favoring the first one.
Can someone enlighten me why some people create those odd validation rules in their systems? Is it just stupidity and ignorance? Is it some sort of fatal over engineering? Some strange flaw by design? Force of habit carried over from, I don’t know, Fortran? There is just no reason why a good password system should not be accepting long passphrases that include non-alphanumeric characters.
[tags]passwords, password lenght, alphanumerics, non-alphanumerics, password restrictions, password policies[/tags]