Strange Password Restrictions

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:

Password SHA1
abc123 6367c48dd193d56ea7b0baad25b19455e529f5ee
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]

This entry was posted in technology and tagged , . Bookmark the permalink.



12 Responses to Strange Password Restrictions

  1. vacri AUSTRALIA Mozilla Firefox Debian GNU/Linux says:

    If you want really weird, the Travian forums have a captcha on their search function. That’s right, if you’re merely looking for information to prevent reposting, you have to solve a captcha. Let me also add that the captcha sometimes has it’s letters aligned vertically, so you can’t tell which one comes first.

    Oh, and you can’t search if any term is less than three letters… which is great for a game with plenty of three- and two-letter acronyms.

    Combine this all with a forum community that is fairly hostile to reposts (they will post mocking/incorrect info quite often), and it’s quite an unpleasant forum experience. Out of six forums searches, I failed three – one due to word length, two to vertical letters. Never used it since.

    Captcha on a search function. Bizarre. Game is slow but fun, though.

    Reply  |  Quote
  2. gooli ISRAEL Mozilla Firefox Windows says:

    You are basing your entire analysis on the premise the people store the hash of a password in the database. While that is the best practice from the security stand point, it’s not the best way to make your site usable for people with week memories. If you don’t know the password, you can never send it to your user if he forgets it. You’ll have to generate a new one. And that isn’t always a pleasant experience for the user.

    Many sites, including Google I think store their passwords using some sort of encryption, or maybe even as clear text.

    I still don’t think there should be any limits on a password’s length or contents and you can always use base64 to encode it. But I guess not everybody knows that.

    Reply  |  Quote
  3. Ricardo INDIA Mozilla Firefox Windows says:

    Well, in my experience, I’ve seen a lot of web sites/programs that actually don’t hash their password. Maybe it’s only the lack of experience in Brazil but I don’t think so. Also, these “programmers” that don’t use hash, limit the size in the database to store the password. Varchar from 10 to 20 is common in the cases I’ve seen

    People (I mean companies) do all kinds of weird stuff with the password. It is sent by e-mail when requested, it appears in a change password page, etc. Even if in these cases the password is being hashed, I wouldn’t recommend a two-way hash either.

    Reply  |  Quote
  4. Luke Maciak UNITED STATES Mozilla Firefox Windows says:

    @vacri – I actually saw the restriction on the 3 letter searches on two other forums that I sometimes visit. It’s bizarre because there are tons of acronyms and 3 letter words one might want to search for.

    @Ricardo – I guess tats true. But not hashing, using a two way hash and sending passwords via email is just not very secure. I’m at least hoping that companies like Verizon have better security policies in place. The way you should handle restoring lost password should by by generating a one time URL, sending it to the user via his registered email, and then asking him to respond to the security question to reset the password.

    Reply  |  Quote
  5. Luke Maciak UNITED STATES Mozilla Firefox Windows says:

    @gooli – ok, good point. Still, even if your password must be recoverable, you can use a 2 way hash, or some form of encryption. Or as you said, base64. :)

    Reply  |  Quote
  6. tummblr UNITED STATES Mozilla Firefox Windows says:

    The issue of password restrictions that force us to use *weak* passwords has always bugged me. It’s quite disturbing that there doesn’t seem to be any logical reason even after you gave it so much thought. /boggle

    It also baffles me why bank and credit card sites, which are supposed to be the most secure (right?), are the ones most likely to have silly restrictions that disallow long passwords or special character passwords or passphrases. What is it that these financial institutes are doing that gives rise to these restrictions? Maybe the same person/team is responsible for the user authentication implementation on all these financial sites?

    Reply  |  Quote
  7. Luke Maciak UNITED STATES Mozilla Firefox Windows says:

    I always say that banks should have two factor authentication. Or at least offer it as an option for the customers who are willing to pay the cost of the fucking dongle.

    How many banks actually implement two factor? Precious few. I actually can’t name one that would do it off the top of my head.

    Reply  |  Quote
  8. Ricardo INDIA Mozilla Firefox Windows says:

    Well, the case of banks is actually an exception in Brazil. All of the big ones use two factors, usually two different passwords.

    Mine have a password protection access that can’t be typed using the keyboard. You must click the virtual keys and the password can have any character.

    Then, for all important transactions, you must have a card that matches numbers to letters. So the bank web site will show a random number and you must type the correspondent letters contained in your card.

    Reply  |  Quote
  9. jambarama UNITED STATES Epiphany Linux Terminalist says:

    HSBC has two factor authentication. I haven’t asked about a dongle, but by default you have a password you type and a password you click onto a visual keyboard. That way key loggers can’t get you. The passwords must be different, and they have some requirements that the password isn’t too weak, but they do cap the length at something unreasonably low.

    Reply  |  Quote
  10. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux says:

    Oh, I forget at the “almost two factor” methods. Usually two factor is defined as something you know, and something you have. It’s more secure because the attacker now has to steal or social-engineer the dongle/card/fingerprint whatever out of the victim. And it works on psychological level too – a clueless user may think nothing of telling someone their password over the phone, but letting someone borrow their RSA dongle, Employee ID, Smart Card or something like that is a different matter.

    People tend to be protective of security “items” such as keys and key cards, but wantonly reckless with passwords. This is one of the reasons why two factor works – especially if it’s in a form of a dongle that generates random codes every few seconds.

    I don’t really consider that “type the second password on the on-screen keyboard” as a two factor, because it’s still “something you know”.

    Reply  |  Quote
  11. jambarama UNITED STATES K-Meleon Windows Terminalist says:

    Luke – good call you’re right. I read two factor and thought two password. I do think that the HSBC two password idea isn’t a bad one. Like you said, it isn’t as good as some kind of always changing number on a keycard or a dongle or something, but it does defeat keyloggers from spyware/trojans even if it doesn’t protect you from idiot users.

    Reply  |  Quote
  12. Luke Maciak UNITED STATES Mozilla Firefox Ubuntu Linux says:

    Yeah, it’s better than nothing.

    Still, the on-screen keyboard can be easily defeated by the easy-to-perform “look the user over the shoulder” hack. ;) So I’d say it’s kinda double edged sword, and does not compare to he proper two factor which defeats both key-logers, over the shoulder snoopers.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>