68

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

Community
  • 1
alexmuller
  • 1,061
  • 1
  • 9
  • 13
  • 15
    You're making an assumption, that they're NOT storing it as plaintext ;) – AviD Jul 04 '11 at 11:23
  • 5
    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
  • 7
    @bstpierre - What bank is that? I want to avoid them!!! – Peter Anselmo Oct 12 '11 at 20:12
  • I can't believe that a decade later most UK banks still operate this way... – Weckar E. Jul 21 '21 at 11:04

6 Answers6

30

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)

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • 8
    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 04 '11 at 11:18
  • Good to know that it exists, but it seems highly unlikely that this was actually being done. – Wildcard Jan 17 '18 at 05:18
  • @Wildcard out of curiousity, what makes you think it's highly unlikely that a bank would use an HSM for password storage? – Rory McCune Jan 17 '18 at 11:41
  • Not unlikely for “a bank,” perhaps, but this bank. Why the 6-8 character restriction if they’re that security savvy? – Wildcard Jan 17 '18 at 12:18
  • A lot of older banks tend to use back-end systems (e.g. mainframes) which have very outdated restrictions on password length. They also make a lot of use of HSMs for key/secret management. I've seen cases where password restrictions on front-end systems related to restrictions on the ultimate storage location of the password. – Rory McCune Jan 17 '18 at 12:22
17

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

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • 7
    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 – Rory 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
  • 1
    @Jeff, @Rory, @Rakkhi - symmetrically encrypting passwords *is compliant* with PCI-DSS. Not necessarily the best of ideas, but it is compliant. – AviD Jul 04 '11 at 11:21
  • The compromise is bull. Plaintext means anyone internal to the bank has the potential to see that password, which is just plain bad all around. – Andy May 09 '15 at 22:34
13

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.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 6
    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 06: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 07:42
  • 3
    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
  • 7
    @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
  • I didn't mean to imply that most or even many users would notice, just that if you are vigilant, this attack has been accounted for in their protocol. I agree that a "vigilant user" is like a unicorn - I've never seen either in the wild! – ZoFreX Aug 01 '12 at 09:25
  • 1
    My NatWest password is over 8 characters long, and was so at the time of the answer. – Josh Gallagher Jul 30 '14 at 12:38
  • 1
    @JoshGallagher Mine too, the 8 character limit is simply not true and hasn't been for at least 7 years now. – biziclop Jul 20 '15 at 11:26
  • Oh, I can see what happened, they are talking about the credit card services, which I've never used as you can access credit card operations through the current account management page too. (Which doesn't impose the ridiculous 8 character limit.) – biziclop Jul 20 '15 at 11:28
8

In a similar question, a comment by @captaincomic has linked to this article: Partial Passwords - How? (From Archive.org) 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.

Kevin Fegan
  • 107
  • 5
Piskvor left the building
  • 1,644
  • 15
  • 14
  • 1
    The link to the "Partial Passwords - How?" article is now broken and showing `404 - Not Found`. I have replaced the link with a link to an archived copy on Archive.org. – Kevin Fegan Oct 07 '17 at 02:45
6

It's only tangentially related, but David Aspinall (University of Edinburgh) and Mike Just (Glasgow Caledonian University) published a paper on partial passwords in 2013: "Give Me Letters 2, 3 and 6!": Partial Password Implementations & Attacks.

Their paper looks at online attacks for which the backend storage mechanism is irrelevant, but it makes a passing remark that is germane to your question:

To support the partial protocol the implementation will need to either store plain-text for the password, or devise a mechanism for performing one-way checks on all combinations that might be queried (which can be a large number for long passwords). We don’t investigate this attack mode here.

sampablokuper
  • 1,961
  • 1
  • 19
  • 33
  • Read the article. It's not related to this question at all. It studies e.g. the impact of requiring too little characters from the original password on the feasibility of replay attacks, and so on. As you have noted yourself, virtually no attention is given to the cryptographic systems that can be employed. – vucalur Mar 17 '17 at 17:39
  • @vucalur, whether something is tangentially related or is, instead, unrelated, is a matter of opinion. We'll have to agree to disagree in this case. But the passing remark *is* germane, is it not? – sampablokuper Mar 18 '17 at 10:01
2

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.

Rakkhi
  • 5,783
  • 1
  • 23
  • 47
  • 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
  • 12
    @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. –  Jun 27 '11 at 12:14
  • Usually this bit, with a hashed 4 digit PIN, for example, is just one piece of information. The others from my bank are username, password and smart card reader (the latter just for creating or authorising payments) which does give sufficient security for purpose. – Rory Alsop Jun 27 '11 at 12:55
  • @ninefingers @binfalse I don't see how else they would be doing it. A full set of 72 characters with 1 million iterations of bcrypt or equivelent would still give some protection if the password was stolen for an offline attack. They would also hash the other secret e.g. dob but this could be easily gained. – Rakkhi Jun 27 '11 at 12:56
  • 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. – Rory McCune Jun 27 '11 at 14:28
  • @rory-mccune yes reversible encryption is the other way as I mentioned and a HSM is a good place to store the clear text password. 3 retail banks though and I have not seen it done that way (2c). Performance on login has never been an issue – Rakkhi Jun 27 '11 at 15:24
  • @rakhi that's v. interesting, so they were/are hashing single characters and storing them that way..? And are they doing large numbers of rounds of bcrypt to mitigate the brute-force risk? othersise whilst a technically compliant sol. it wouldn't be a great mitigation to the brute-force risk... – Rory McCune Jun 27 '11 at 16:04
  • @rory-mccune yeah before my time when design was chosen, don't think was bcrypt, most likely SHA or MD5 but yes compliance is the main objective. Still if anyone got password database bigger problems than worrying about hash. Now with Lulzsec etc hope someone is re-thinking but doubt it. Changing legacy systems is tough (web front end, auth db in Mainframe) – Rakkhi Jun 27 '11 at 16:18
  • @rakhi, yeah I know what you mean, I've worked in a couple of banks and experienced the delights of legacy systems :) – Rory McCune Jun 27 '11 at 16:45
  • 3
    @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
  • @d-w personal experience only, can't provide citation. Don't believe me that's fine, no skin off my nose, just doing my best to answer the question. Agreed about Trojan that's why I said it can provide a false sense of confidence. – Rakkhi Jun 28 '11 at 08:19
  • Your assumption is most commonly mistaken; though I cannot speak specifically for HSBC or NatWest, many bigname banks and systems that I've seen implement this scheme do not store the passwords hashed, but symmetrically encrypted at best, and not hashed. – AviD Jul 04 '11 at 11:25
  • 1
    You need to add 3 words to the start of your answer: `I think that..` – Pacerier Oct 02 '11 at 01:32
  • *"You have to also impose a maximum password length so that you can allocate the fields in the database to store all the hashes"* Not if you have a modicum of knowledge on database design. Instead, you'd be more likely to have a table such as [Customer,Position,Hash] which, for each customer, stores an arbitrary number of position/hash pairs. *Et voilá*, no need to impose any length restrictions, *and* it keeps the main table away from The Daily WTF. With a little bit of clever design, you can also pad to a random length >= the customer's password length, so you also don't disclose the length. – user Oct 07 '17 at 10:24