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

Improve this question
5
  • 16
    You're making an assumption, that they're NOT storing it as plaintext ;)
    – AviD ♦
    Commented Jul 4, 2011 at 11:23
  • 6
    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
    Commented Oct 11, 2011 at 17:26
  • 8
    @bstpierre - What bank is that? I want to avoid them!!!
    – Peter Anselmo
    Commented Oct 12, 2011 at 20:12
  • 1
    I can't believe that a decade later most UK banks still operate this way...
    – Weckar E.
    Commented Jul 21, 2021 at 11:04
  • @WeckarE. Yeah it's so ridiculous, someone could easily brute force a few characters, they SHOULD be asking for the WHOLE password, there's absolutely no good reason for this partial password nonsense 🤬😡
    – olfek
    Commented Apr 20, 2023 at 10:39

6 Answers 6

Reset to default
31

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)

Improve this answer
5
  • 9
    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 ♦
    Commented Jul 4, 2011 at 11:18
  • Good to know that it exists, but it seems highly unlikely that this was actually being done.
    – Wildcard
    Commented Jan 17, 2018 at 5: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
    Commented Jan 17, 2018 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
    Commented Jan 17, 2018 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
    Commented Jan 17, 2018 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

Improve this answer
7
  • 7
    ferland PCI-DSS v2 p47 "8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography."
    – Rakkhi
    Commented Jun 27, 2011 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
    Commented Jun 27, 2011 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 ♦
    Commented Jun 27, 2011 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
    Commented Jun 27, 2011 at 22:31
  • 1
    @Jeff, @Rory, @Rakkhi - symmetrically encrypting passwords is compliant with PCI-DSS. Not necessarily the best of ideas, but it is compliant.
    – AviD ♦
    Commented Jul 4, 2011 at 11:21
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.

Improve this answer
9
  • 7
    NatWest doesn't ask for your ATM pin, it's a separate online banking pin.
    – Polynomial
    Commented Oct 12, 2011 at 10:26
  • 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
    Commented Oct 13, 2011 at 7: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
    Commented Jul 31, 2012 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.
    Commented Jul 31, 2012 at 18:14
  • 1
    My NatWest password is over 8 characters long, and was so at the time of the answer.
    – Josh Gallagher
    Commented Jul 30, 2014 at 12:38
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.

Improve this answer
1
  • 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
    Commented Oct 7, 2017 at 2: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.

Improve this answer
2
  • 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
    Commented Mar 17, 2017 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
    Commented Mar 18, 2017 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.

Improve this answer
15
  • 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
    Commented Jun 27, 2011 at 11:34
  • 13
    @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
    Commented Jun 27, 2011 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.
    – Rory McCune
    Commented Jun 27, 2011 at 14:28
  • 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.
    Commented Jun 27, 2011 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.
    Commented Jun 27, 2011 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .