Security is a complex endeavor, and knee-jerk reactions like “plaintext password? never” are just as bad as “passwords must contain special characters” or “my crypto's bigger than yours” or “if I can't understand it nobody can” if you don't consider the full context.
First, let's analyze the assets. There are two subjects: the bank, and the customer. They hold several assets:
- The bank's money. Depending on what the attacker do, the bank may need to spend money fixing problems, to compensate the customer or other parties, and may see its reputation tarnished.
- The customer's money (and his private information).
- The customer's password. If compromised, he will need to change it, perhaps on other sites as well.
- The authentication data sent during one session. This can be different from the password, for example in the case considered here this is (typically) two random characters from the password.
The bank is in full control of the security architecture. It would be unsurprising for it to privilege the security of its own assets over the customer's. This doesn't bode well for the password.
There are many threats around the password, including (numbering for convenience, not to suggest any particular order of importance):
- An attacker gains access to the bank's live system or to backups and is able to access the password the way it is encoded in storage. The attacker would almost certainly be able to obtain a large number of passwords at once this way.
- An attacker gains access to the computer used by the customer (e.g. by installing malware on it) and grabs the authentication data, possibly hijacking the session.
- An attacker obtains the authentication data by shoulder surfing or other method that doesn't give him control over the session.
Hashing the passwords on the bank servers exclusively mitigates threat #1, unauthorized access to the encoded password. This mitigation is limited as it is only effective against sufficiently strong passwords; weak passwords will fall even if protected by a slow hash.
Splitting the authentication data from the password increases the vulnerability to this threat. On the other hand, it mitigates threat #3 and to a small extent threat #2: an attacker in possession of the authentication data for one session cannot easily reproduce it to open another session. If he makes many attempts until he gets a challenge that matches the authentication data he has, his attempts are likely to be blocked by the bank's server. Eventually, if he watches enough successful authentications, he'll get the whole password, but he risks getting noticed.
At this point, the bank needs to weigh the risk and damage from threat #1 with the risk and damage from threat #3, and to consider alternative ways of mitigating threat #3. There are numerous authentication methods and I won't go into details here; I'll concentrate on threat #1.
If threat #1 leads to an attack, the attacker is in possession of a large number of hashed or non-hashed passwords. Keep in mind that hashing only makes a difference from sufficiently strong passwords. The attacker is unlikely to be able to attack all the accounts anyway, because after a while he will be detected (maybe not with 100% accuracy, but enough to slow him down) by the bank's fraud pattern detection. So he's content with focusing on the accounts with the passwords that are easiest to crack; hashing doesn't slow him that much. The mitigation offered by hashing isn't very good in this scenario.
If you're a user with a strong password, you would understandably prefer not to be affected by the attack — let the troubadours bear the brunt. The bank has a different outlook: it doesn't care whose account gets breached, only about the number of breached accounts. If at this point you get huffy about banks not caring about geeks who take their security seriously — do you have a credit card? Merely having one allows anyone to make a purchase charged to your account by rattling off a 16-digit number that's all over the pace, so you have a way to go.
The other part of the assessment of password hashing is to consider alternative mitigations. A bank isn't some service hosted on a $5 VPS, it can afford better security. For example, banks tend to have very tight controls on their employees, which reduces the risk of an insider breach. Against outsiders, storing the passwords in an HSM is a good but awkward defense (in particular, backups are hard). Encrypting the passwords and storing the encryption keys split over several smart cards is another possible mitigation — it doesn't protect the live system but it's effective for backups. Encryption is a very good mitigation of threat #1 (it works even against extremely weak passwords) provided that the key and the password database are sufficiently independent so that they are hard to steal together.
All things considered, password hashing is not a panacea in this scenario. While it isn't a bad idea, a qualitative analysis shows that an alternative approach that requires a reversible password storage may provide better security. It would take a very thorough study of fraud and usability to assess quantatively whether using random characters from passwords for authentication is worth foregoing password hashing.