Have you ever had to enter CHARACTERS from your password to log in?  No? Me either. How would you feel if you entered your credit card number into your credit card provider’s website and instead of the usual password you were given this screen:
This is the second screen of my credit card provider’s authentication workflow. They are asking me to answer my “Personal Identification Question”, and asking me to type 3 random digits of my password instead of my entire password. The ramifications of this set of implementation choices just blows my mind.   Three strikes and you’re out, if you ask me:
1. Downright Terrible Personal Identification Questions
Anyone who reads my blog can probably figure out my favorite hobby, I even mention it on my about page. That question was one of five terrible security questions. Three of the questions are standard web access management fare. They aren’t great, but at least the 8-character minimum character limit keeps away answers like “golf”, “ford”, and “rex”.  The other two questions are in my mind criminal however. No financial institution should give a customer the option to use their mother or father’s name as a method of personal identification. I can’t believe anyone put those questions into production. The worst part: because of the list given, those two questions are the only ones that can be answered in a straightforward way while also fitting the complexity rules.
2. Removing The Guesswork from Password Hacking
Then there is the 8-character password. I could have sworn that one of the variables that make a password tough to brute force is the fact that the length is unknown. If you *know* you’re working with 8 characters, you can seriously narrow down your brute force parameters. Plus the only punctuation allowed is an underscore. Ouch.
3. One-way Hashes are *so* 2008
Since my bank is performing character matches on my password, there is no way that they are using a one-way hash algorythm to store my password.  If they were, they would be able to match the whole thing or nothing at all. Instead, they have chosen to be able to retrieve my password and play with it. I can only hope that it isn’t stored in clear text, but frankly anyone who asks “What is my mother’s name” as a security question can’t be too worried about security. Don’t get me wrong, HSBC is very worried about the appearance of security, in fact I was forced to positively acknowledge a big long page of statements about how firewalls are used, and how they require me to use 128-bit encryption. In spite off all the assurances, it seems to me that I’m at risk in a number of ways now, and all so that the password interface can be turned into a primitive and easily overcome turing test.
So, what am I missing? Is there some brilliant element to this setup that makes up for the sins that appear to have been committed? Something that will make me happy my credit is in the hands of this company? I hope so, because right now I feel like maybe it’s time to do my best ‘rat leaving a sinking ship’ impression.
Wow. How do you suppose something like this even gets deployed? I know that HSBC is a fairly large bank, so do they have some guy in the back room doing their web site? Highly unprofessional, and it speaks volumes about the organization itself. I’d be thinking about jumping ship, too. What are the odds that your password is transmitted to some client-side script in clear to check those characters?
I’ve noticed that lists of security questions seem to be more common these days. I’m not sure why, because they actually lessen security, particularly if the questions are badly chosen (like the ones in this example). My policy has been to give fake answers for things like mother’s maiden name, elementary school attended, and so on. With genealogy sites and classmates.com, this information is not that hard to find on the net. Of course, that means that I have to write the answers down somewhere – but it seems a better idea than trusting the web sites.
I’d be very tempted to enter “hacking bank web sites” for my favorite hobby in this case. :-)
I hate this kind of stupid stuff. Another peve of mine is week-ass password policies… I found a clasic in my own company http://www.bobbobel.com/the-number-one-reason-to-use-sso-password-policies/
Pingback: Daily Digs – 09.15.2009 « Security Stallions Blog
You have raised some good points. Here are a few things to consider. Using one way hash is not a good way to store passwords for e-commerce applications because anyone having access to hashed passwords can easily do a dictionary attack. Hashing algorithms are fast by design and you can hash around a million words on decent CPU. Try openssl speed to see what I mean here. Even a salt would not protect against this attack because the salt has to be stored some where and attacker can get that.
A better way to protect passwords is to use FIPS 140-2 Level 3 or above devices which provide industrial strength encryption. The key never leaves the hardware crypto card and all crypto operations are performed inside the device. That’s what most banks use.
Asking for random characters from your password does protect against key loggers. Seems like a good idea to me.
Great points – I suppose I think of a one-way hash as more of a bare minimum than “the” answer, but then considering that I called one-way hashes an industry best practice, perhaps I was setting the bar too low for banking best practices?