How are passwords stored in systems that require the user to enter specific digits of their password?

January 31, 2011 7:38 AM

How are passwords stored in systems that require the user to enter specific digits of their password? I am familiar with encryption techniques such as MD5 hashes, but I can't see a way in which a system would store the entire encrypted password, and still be able to authenticate individual characters, unless the password is stored in plain text, which seems unlikely for a bank.

An example, would be, on most bank systems they may request three randomly chosen digits from your password, in an effort to counter keyloggers.

posted by InsaneRhino to computers & internet (20 answers total)

Which "most bank systems" are you talking about? I've never heard of such a thing.
posted by devbrain at 7:41 AM on January 31, 2011

Natwest in the UK, I also believe Halifax use such a system. It is also common practice in the UK over the phone so you don't have to give the operator your entire password, but specific letters of that password.
posted by InsaneRhino at 7:43 AM on January 31, 2011

as a datapoint HSBC HK also does the same thing.
posted by jannw at 7:47 AM on January 31, 2011

The don't have to store it in plain text - it can still by encrypted, just in a way that can be decrypted if you have the right key. Anywhere that stores credit card details have to do the same thing - they can't store the data in plain text but they need to be able to retrieve the original data to charge your card.
posted by missmagenta at 7:50 AM on January 31, 2011

It also depends on architecture -- if an attacker has sufficient access to the authentication database, it's possible (and in some systems very likely) that they've got access to everything, so encrypting the passwords only prevents further breaches for people who use the same password everywhere.

There's a lot more incentive for a bank to have their data segmented and at different levels of access than, say, Twitter, so in those cases it's more likely that they're using encryption rather than hashing (as missmagenta points out), but applying that question to the internet at large: hashing passwords generally provides more protection for other services than the one doing the hashing.
posted by toomuchpete at 7:56 AM on January 31, 2011

Do they ask, say, "Please tell me the third, sixth, and eighth digits of your password"? Or is it "Please tell me any three digits of your password"? If it's the former, they can store a separate hash for every subset of digits. If there are 8 digits in a password, then that's 255 hashes -- more, but not too many. They can do the same even in the latter case, but they'd have to check against all the hashes that correspond to, say, three digit subsets.
posted by mhum at 7:57 AM on January 31, 2011

I don't know for sure, but I would image they would encrypt your whole password, and using the same technique encrypt the partial password you can use with CSRs only.
posted by pyro979 at 7:58 AM on January 31, 2011

I think almost all banks in the UK do this. I can think of at least 3 that do.

mhum: "Do they ask, say, "Please tell me the third, sixth, and eighth digits of your password"? Or is it "Please tell me any three digits of your password"?"

It's always specific characters (usually three) of an alphanumeric password. Passwords can usually be much longer than 8 characters but some banks seem to use case-insensitive passwords.
posted by turkeyphant at 8:14 AM on January 31, 2011

turkeyphant: It's always specific characters (usually three) of an alphanumeric password.

In that case, I'd wager that there's a separate hash for every three-letter subset of the password. If there's a maximum length of, say, 30 characters, then that's still only 4046 hashes.
posted by mhum at 8:20 AM on January 31, 2011

In that case, I'd wager that there's a separate hash for every three-letter subset of the password. If there's a maximum length of, say, 30 characters, then that's still only 4046 hashes.

At that point there isn't much point in hashing the password. If we assume that each character can be any ASCII character then you can brute force a 3-character hash in only 128^3 = 2M combinations. Multiply by 10 to cover a 30 character password. You'd weaken your security by a factor of (10* (128^3)) / (128^30) = 10^-56
posted by atrazine at 10:16 AM on January 31, 2011

(for context, a commodity GPU running CUDA can do that in a fraction of a second)
posted by atrazine at 10:19 AM on January 31, 2011

atrazine: At that point there isn't much point in hashing the password. [...] Multiply by 10 to cover a 30 character password.

Technically, you'd multiply by 30 choose 3 = 4060 (I had a typo in my previous comment) since every 3-character subset would be possible, not just consecutive subsets, but your overall point is valid. Going this route cuts the key-space down by a ridiculous amount. It would only make sense in contexts where brute-force can't quite work -- like, say, over the telephone.

Of course, this is brought to you by the same people who can't or won't understand what two-factor authentication really means. So, maybe it's not that surprising.
posted by mhum at 12:32 PM on January 31, 2011

This sounds a lot like a question from a few months ago on Stack Overflow. They didn't have a definitive answer but maybe something will trigger for you.
posted by scalefree at 12:59 PM on January 31, 2011

atrazine: "In that case, I'd wager that there's a separate hash for every three-letter subset of the password. If there's a maximum length of, say, 30 characters, then that's still only 4046 hashes.

At that point there isn't much point in hashing the password. If we assume that each character can be any ASCII character then you can brute force a 3-character hash in only 128^3 = 2M combinations. Multiply by 10 to cover a 30 character password. You'd weaken your security by a factor of (10* (128^3)) / (128^30) = 10^-56"

Except that surely brute force is not possible as you are locked out after a small number of guesses and the three characters you are required to supply are cycled out each time you log on.

So what is our answer here? Are you guessing that the three character combinations are hashed or is something else going on?
posted by turkeyphant at 1:31 PM on January 31, 2011

In the UK I mostly see it for Verified by Visa via my Barclays debit card. I've had a look round the website for some technical details but I couldn't find any. The US also has a 'Verified by Visa' scheme but it seems to be a more traditional password setup.
posted by robertc at 4:01 PM on January 31, 2011

Technically, you'd multiply by 30 choose 3 = 4060 (I had a typo in my previous comment) since every 3-character subset would be possible, not just consecutive subsets, but your overall point is valid.

Sure, but you don't need to crack every combination of 3 digits, just enough to recover the whole password. So you'd pick 10 non-overlapping 3 digit hashes.

Except that surely brute force is not possible as you are locked out after a small number of guesses and the three characters you are required to supply are cycled out each time you log on.

That isn't really relevant. The reason to hash the password is to prevent compromise of the password if someone compromises the database. If they've done that then they have infinite retries, if you assume that they can't compromise the password db then there isn't a point in hashing.
posted by atrazine at 9:27 PM on January 31, 2011

I think the point is that a bank should never have passwords, even hashed passwords, stored on a customer-facing server. The passwords should be stored on a heavily secured system (such as the ones that store confidential bank data) with which the customer-facing servers communicate just to verify, say, a hash of a three-character code. If the secured server with the passwords can be compromised, then the bank has some much bigger problems. The whole point of the three-character thing is to prevent individual passwords from being compromised if the web site is accessed by users on compromised computers. In fact, some bank web sites have you choose the three characters from drop-down menus, presumably to thwart keyloggers.
posted by klausness at 3:23 AM on February 1, 2011

atrazine: Sure, but you don't need to crack every combination of 3 digits, just enough to recover the whole password. So you'd pick 10 non-overlapping 3 digit hashes.

Ah. Point taken. I misinterpreted where you were going with that. This makes it even more catastrophic than I understood. A leak of the hashes is more or less equivalent to a leak of the passwords thus, as you say, there's hardly any point to hashing. This is making me wonder if this is really how it's implemented. On the other hand, I've always said that we shouldn't assume that people know what they're doing just because there's a lot of money at stake.
posted by mhum at 9:04 AM on February 1, 2011

Or, when you create the password, it stores it two different ways, the hash of the entire password and the hash of the last three characters. They want your entire password to sign on but rather than ask you for the entire thing when you call, they ask for just the last three, so the operator doesn't ever get to hear your entire password.
posted by Brian Puccio at 8:08 PM on February 1, 2011

so the operator doesn't ever get to hear your entire password

But then you've just shortened your password to three letters, and anyone who overhears your conversation with the operator can call up and impersonate you after that single conversation. The point of asking for a different subset of letters every time is that someone overhearing (or a keylogger) doesn't get all the vital information in a single transaction.

It may be misguided in terms of overall security, but the whole point of this approach is to decrease the chance of a keylogger stealing all the vital details if you happen to use an infected machine one time to log on to your bank account or make a payment.
posted by robertc at 4:19 PM on February 2, 2011