I fail to understand why ANY institution would limit any character from appearing in a password, but it happens all the time. When I first registered to do online banking at US Bank six years ago, they limited passwords to eight to twelve characters, and only letters and numbers. This only allows for 8^52 - 12^52 possible passwords. Yes, those numbers are big, but computers are getting faster, and such limits can be prohibitive, particularly if they’re stored unsalted, and thus vulnerable to a rainbow attack.

They’ve since changed this, allowing up to 24 characters, and symbols. Ignoring special ASCII characters, like linefeeds, this probably allows about 200 characters, opening the password space to 8^200 - 24^200, a lot harder to attack (this could still be susceptible to a Rainbow Attack though, I don’t know if US Bank salts their passwords before hashing them). Even if you only add in the symbols people are actually likely to use, there are still ~80 characters that could consist of the password (ie, the ones easily typed on an US English keyboard), and that exponent is a powerful thing.

So, imagine my surpise when I go to TIAA-CREF’s website, and find that my password must be 8 - 12 characters long, and can only consist of letters and numbers. Amazingly, I know I’ve seen this sort of requirement still in effect at other major financial institutions, and I’ve yet to be able to figure out where in the hell it’s coming from. Password schemes are easy to implement in a safe manner. They should use a cryptographically secure hashing algorithm (I’ve used MD5 and SHA-256, but lately I’ve migrated to bcrypt), users should be encouraged to use a long password with a variety of characters to prevent it from being cracked if an attacker can get the hashes, and the password should be properly salted before hashing to prevent rainbow attacks.

I just doesn’t make sense. Computers are fast, and hashing algorithms are designed to be fast. To a certain degree, this speed is a problem, as a fast hash on the server, means a fast hash on the client. As Ptacek explains in the post linked, an adaptive system like bcrypt is great, because it will likely keep pace with advances in computing technology.

So, if the technology and procedures are out there to create good passwords, why don’t more people use them? Plain and simple ignorance is the only explanation. Which is unfortunate, because ignorance costs a lot of money in this day and age. As I said, I’ve used MD5 and SHA-256 for passwords before, and in the places where I can, I’m trying to correct that error. Ultimately, though, as long as a password isn’t thousands of characters, it’s not going to create a bottlneck in transfer or processing. Minimum password lengths are far, far more important than maximum lengths, as short passwords will always be brute-forceable. Put a maximum length on a password, for sanity’s sake, but set it as high as you reasonable can given the storage requirements and constraints of your system. I’ve used a maximum length of 1024 characters before, which was far more space than anyone needed, and didn’t put any strain on the database.

In short, when designing new systems, use established mechanisms like bcrypt, or Kerberos if you’re in an environment you can trust it. If you don’t you’re likely to end 30 years behind the times, and in a world of hurt because of your poor security. And if you’re a financial institution, fix your lousy schemes immediately. There is no excuse for poor security when you handle people’s money.