One of the many things I’ve had to do as part of transitioning to my new job is move my retirement savings (401k) over to a new provider. In this case I’ve been moving over to the Fidelity site. The security of financial web sites never fails to disappoint.
No I didn’t try some crazy SQL injection, CSS, or XSRF attack on the site (that would be illegal!). I just read their password policy:
- Use 6 to 12 letters and/or numbers
- Do not use one entire piece of personally identifiable information such as your Social Security number, telephone number, or date of birth. Instead, alter or disguise it (e.g., Jane212Smith)
- Do not use more than 5 instances of a single number or letter, or easily recognized sequences (e.g., 12345 or 11111)
- Do not use symbols, punctuation marks, or spaces (e.g., #,@, /, *, -.)
::Sigh:: 12 character max and only letters and numbers? Come on seriously? According to Microsoft [1] 14 characters is the recommended minimum for a password. But length isn’t the only factor. By excluding all special characters they effectively cut the character space in half.
Let’s think about this technically for a second though. Why would they need to place these restrictions on their customers security? Let’s assume the password is just another field in the Fidelity database because that’s exactly what it is. Typically there are two reasons to limit field length and content in a database:
- efficiency: variable string length fields are very expensive
- special characters can be a bit dangerous in that a scripting language or the SQL engine fronting the database might interpret the characters as commands
If however, Fidelity follows best practices for storing passwords in their database neither of these concerns apply because YOU SHOULD NEVER STORE THE PASSWORD DIRECTLY IN THE DATABASE! A hash of the password is what should be stored and the process of hashing addresses both of these concerns because it:
- normalizes the password length
- sanitizes any special characters
This last point can also be mitigated by using the proper and safe SQL commands available in any modern database engine.
So what these restrictions make me think is that the Fidelity site may actually be storing my password in plain text. That, or they’re just placing restrictions on my password strength arbitrarily which makes little sense.
Unfortunately this Fidelity site isn’t the worst offender that I’ve seen, and I don’t even analyze website security for a living. My experiences are limited only to the sites I’ve had to use over the years. Some time back around 2005 I had an account with a bank once that didn’t even let me change my password for their website if I wanted to. They set my password for their website when I established my pin for my ATM card! That’s right, my password for their website was a four digit number. I wrote them a letter pointing out the weakness in their password policy and I got back a form letter basically telling me to go away … so I did, and I took my money (totaling a whopping $2500) with me.
These are the people we trust with our life savings … Most of the web forums I have an account on fixed these problems back around 2007. Fixing something like this isn’t rocket science, just best practice.
UPDATE
After dialing into the phone system for Fidelity it became apparent that special characters are prohibited in passwords because their phone system authenticates users against the same database. It’s convenient, but touch-tone key pads just haven’t kept pace with keyboards 🙂 This also means that their passwords are probably case-insensitive too which nearly cuts the character space in half yet again. ::sigh:: balancing backward compatibility against security is an age old problem. You can look to Microsoft for a few of the biggest examples: the bazillion Windows users still surfing on IE6, the upcoming EOL for Windows XP etc. The Fidelity password strength issue isn’t anywhere near the scale of these examples but the principle holds.
[1]: http://www.microsoft.com/security/online-privacy/passwords-create.aspx
technomasochism 
I realize this article is old, but it validated the ranting e-mail I sent to Fidelity just a minute ago. I went to update my password today, which I should have done a long time ago, and I had to dial down my password generating utility to make something that worked. I use long, complicated, absurd passwords for important stuff like credit cards, banking, and… oh I don’t know, my life savings! If they want customers to be able to dial-in to their accounts by telephone, then they should create a separate authentication system for that with a telephone PIN or something. This is inexcusable.
LikeLike
Seriously it’s just your life savings. No big deal. Really I’m curious to know how many customers actually dial into their bank account on a touch-tone phone? Comparing the number of people that use their website with those that use touch-tone access and the relative loss of security because of the existence of the latter system would be interesting. People in the infosec biz are always talking about “security metrics” and how they don’t exist but in situations like this it’s pretty easy to get numbers that actually mean something.
LikeLike
I just went through a very similar experience, starting exactly the same way – moving my retirement accounts to Fidelity. I was annoyed by the password restrictions, but used a randomly-generated 12 character string and felt ok about it. Then I ran into the fact that their web site accepts passwords by touch-tone keyboard and I was floored. It’s actually a little worse than you stated in your post – the touchtone “character space” is only ten characters (when you press the “5” key, it can’t tell whether you meant “5”, “j”, “k”, or “l”)!
Good grief…
LikeLike
Fidelity now offers two factor authentication via Symantec Validation and ID Protection tokens. Thats an improvement.
LikeLike