Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I thought How can a system enforce a minimum number of changed characters... would answer my question, but it seems this is a different case.

When I sign on to my online banking account, I'm prompted for three random digits from a four digit PIN, and three random characters from my (long, random) password.

From my limited understanding of all this, the bank is unable to create my password hash from this login because they don't have my whole password. So are they storing my password in cleartext and comparing individual characters? Is it a decent balance of convenience/security?

Prompted to ask this question by this blog post: Who cares about password security? NatWest don't

share|improve this question
7  
You're making an assumption, that they're NOT storing it as plaintext ;) –  AviD Jul 4 '11 at 11:23
    
AviD makes a good point. I found a banking system that was obviously storing passwords as plaintext: when you go through the "reset password" routine, they mail your password back to you in plaintext via email! –  bstpierre Oct 11 '11 at 17:26
1  
@bstpierre - What bank is that? I want to avoid them!!! –  Peter Anselmo Oct 12 '11 at 20:12

5 Answers 5

up vote 18 down vote accepted

Whilst I don't know explicitly how banks handle this requirement, an alternate process to the one that @rakhi mentions would be to use an HSM and reversible encryption.

The idea is that the full password would be stored in the database encrypted using a symmetric cipher (eg, AES). Then when the password characters are passed to the application they are fed into the HSM along with the encrypted password.

The HSM could then decrypt the password and confirm that the 3 characters are as expected, returning a pass/fail response to the application. So at no point is the password held in the clear (apart from in the HSM which is considered secure).

This would tie up with the way that PIN encryption can be handled by ATM networks (eg, symmetric encryption and HSMs)

share|improve this answer
1  
Or, do it without an HSM - in fact, this is the way (reversible encryption by the application) that I've seen several big-name banks do it. Not best practice, but compliant with most regulations (e.g. PCI). And, in fairness, protects against most (but definitely not ALL) threats that would be of interest and priority to them. –  AviD Jul 4 '11 at 11:18

Any time you encounter a case where knowing something about your password other than the hash of the full password is needed, you can assume that the password is not hashed. While PCI-DSS was mentioned, there is no regulation that I'm aware of which applies to banks encrypting or hashing password information. PCI-DSS doesn't cover your bank account information, including logging in with your PIN or some variation of it.

If they're being good, the password is stored using encryption. If they're not so good, it could indeed be stored in plaintext.

I admit I rather like the trade-off here. The whole password database may exposed to a greater risk of attack if it's compromised, but I'd counter that security at banks should at the higher end. If a compromise of the database was suspected, everything would have to be changed whether hashed or encrypted anyway. Either instance With this particular method, it takes a lot longer and a greater degree of complexity for an attacker to gain enough useful information to make an attack with a keylogger.

Something tangentially related: http://projecteuler.net/index.php?section=problems&id=79

share|improve this answer
4  
ferland PCI-DSS v2 p47 "8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography." –  Rakkhi Jun 27 '11 at 16:21
    
ferland. One thing to consider in relation to a lot of consumer banking systems is that they take may hold card details (debit or credit) or take them for payments (eg, credit card sites). As such (IMO) they'd fall in-scope of PCI, so DSS would apply –  Rоry McCune Jun 27 '11 at 16:45
    
I should reword: PCI-DSS doesn't typically apply to your bank. It has no bearing on your checking or savings account. It doesn't apply to your online access to your account. Though your PIN is linked to it, that system doesn't relate to a credit card transaction. –  Jeff Ferland Jun 27 '11 at 17:59
    
Even if security is higher at banks, they are much bigger targets, so you can expect a compromise, either from outside or inside. If you compromise an encrypted database of passwords, where the app needs to be able to decrypt it, you typically also get the encryption key, and thus the passwords, which are often reusable are lost and your customers are at yet more risk. So it is bad to do anything but a good hash (or an HSM, as Rory notes) for passwords. With a strong password and good hashing, users really aren't at much password risk even given a DB compromise. –  nealmcb Jun 27 '11 at 22:31
    
Conversely, the most pervasive threat that banks most encounter comes from compromised clients or phishing. A big compromise at a bank can be a big event, but a lot of small events from bank customers can add up to be a greater cost. –  Jeff Ferland Jun 27 '11 at 23:19

NatWest's scheme strikes me as of dubious value. In NatWest's scheme, a phishing attack can probably steal your entire PIN and all or most of your password. Here's how the phishing attack would work.

  1. The phishing site would present a fake login screen, asking for 3 digits of the PIN and 3 characters of the password.

  2. The user would type their answer in.

  3. The phishing site would now present a response indicating that the entry was incorrect, and prompt the user again.

  4. Many users would probably assume they entered something in wrong, and try again.

If the phisher is clever, the second prompt from the phishing site will ask for a different set of digits and characters. If the user tries a second time, then the phishing site can learn all 4 digits of the PIN and 6 characters of the user's password. (Note that NatWest requires users to choose a password containing 6-8 characters, so 6 characters of the password is guaranteed to be all or almost all of it.) At that point, it is game over.

Consequently, it is not clear to me that NatWest's scheme buys you anything.

share|improve this answer
5  
NatWest doesn't ask for your ATM pin, it's a separate online banking pin. –  Polynomial Oct 12 '11 at 10:26
    
Thanks for the correction, @Polynomial! I didn't know that. I've revised my answer accordingly. –  D.W. Oct 13 '11 at 6:15
1  
They've actually moved away from this "online pin" idea now, and are using special card readers that produce a hash of certain information on the card and encrypt it using asymmetric cryptography. You still provide your account login details, but the card expands authentication to "something that you know and something that you have". I'm pretty sure they still do the "enter three characters of your secret code" thing, too. –  Polynomial Oct 13 '11 at 7:42
    
For Natwest in particular at least, a vigilant user would not be fooled by this. If you enter your details incorrectly, Natwest always ask for the exact same details again - they don't ask for different ones until your next log in. (Which also mitigates threats like keyloggers and shoulder surfing) –  ZoFreX Jul 31 '12 at 14:21
2  
@ZoFreX, the overwhelming majority of users don't behave that way. I've done user studies to test this sort of thing, and users don't act or think like that. Generally, they don't notice these details; they just enter in their credentials. And if they do happen to notice something unusual, they don't get suspicious or assume they're under attack; instead, they usually just chalk it up to the Internet being flaky. It's really remarkable. For better or worse, your assumptions about how a "vigilant user" will behave are pretty much a pipe dream. –  D.W. Jul 31 '12 at 18:14

In a similar question, a comment by @captaincomic has linked to this article: Partial Passwords - How? It explains how to allow this functionality without storing the password in a recoverable form or hashing each character separately - using Shamir secret sharing scheme.

share|improve this answer

No what they are doing is hashing each character and storing that or storing the password in clear in hopefully a secure device e.g. HSM.

It is not a bad approach; the bank requests the user enter a number of characters (e.g. HSBC is 3 from random positions). It does mean that if a trojan, key logger or phishing site captured those 3 characters they do not have the full password.

It also allows the bank to use the partial password for authenticating users over the phone etc without relying on secret questions or a different password, again without the call center person knowing the full password

A few problems which is probably why it is not more widely used:

  • The main one is that you do not want to store the password in the clear (in fact regulations like PCI-DSS forbid it). So the approach is to create a one way hash of the password and store that. When the user enters the password, this is hashed and compared to the stored hash, if they match the user is authenticated. With a partial password you either have to store the password with reversible encryption which is not best practice or store a large number of hashes e.g. for HSBC with a birthday plus every character of the password requires a separate hash. You have to also impose a maximum password length so that you can allocate the fields in the database to store all the hashes (although there are probably smarter database and application technologies now that would get around this)

  • It encourages users to select weak passwords e.g. if I have a 8 character complex password: tpEz%e2S . Trying to remember what the 2nd, 4th and 5th character of that is difficult, which encourages users to select a simple dictionary word.

  • Also if there is no account lockout type features it is exponentially easier to guess or brute force 3 characters than 8 characters.

  • Confidence that the full password is not known could be misplaced e.g. if the password is Fulham and you know F, l, h, you maybe able to make a decent guess at the full password

  • A phishing site that simply asked for the 1st, 3rd, 5th then said password incorrect and changed to ask for 2nd, 4th, 6th could also get the full password as user would probably enter it before they thought twice

  • From a user convenience perspective it means they cannot use the browsers remember password or a password manager like Lastpass or 1Password

Most banks are moving away from relying on a username and password e.g. HSBC offers an RSA token for business customers, Barclays have EMV smart card reader, almost all of them use detection technology like RSA adaptive authentication to establish a baseline of browser, location, usage profile, velocity etc for passive authentication and unauthorized use detection.

share|improve this answer
1  
Is hashing each character more secure than cleartext? I mean there are just a handful possible characters to test with the hash function and you'll know the character!? Even if they are using salts, if some attackers got access to the site they might/will also have access to the salt!? –  binfalse Jun 27 '11 at 11:34
8  
@binfalse no it isn't, regardless of whether you use a salt or a slow hash function or a combination, since if you know you've only got one character to reverse, brute force is trivial. I sincerely hope this is not what my bank is doing. –  user2213 Jun 27 '11 at 12:14
2  
Got to say I doubt that they're doing it with hashing. Remember they have to do the operation each time a user logs in. So if they stretched it out with bcrypt or the like to mitigate brute-forcing it would have a really bad effect on performance of the application. –  Rоry McCune Jun 27 '11 at 14:28
2  
@Rakkhi, how do you know they are hashing each character separately? You provide no citation. I don't see how you'd know. If you are hypothesizing/speculating, you should say so. (And I don't find it a very convincing speculation. If that's what they are doing, it is silly.) Hashing each character separately has no security benefits; it is equivalent to not hashing -- it is security theater. –  D.W. Jun 27 '11 at 17:34
2  
@Rakkhi, I disagree with your statement that "it is not a bad approach". If you have a trojan on your computer, and if you log in several times, then the trojan probably has your entire password (or enough to guess the rest). Probably the only possible advantage is that if you log on once from a public computer, your security is not totally compromised. However, a malicious public computer could easily prompt you to log in several times (making you think that on your first try, you must have entered your password incorrectly), which means that even this goal is probably not attained. –  D.W. Jun 27 '11 at 17:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.