Is there any good reason not to salt/hash passwords you store?

Question

Two organisations I frequently deal with (including my bank) ask me my password to authenticate myself with them... well... they ask for "random" characters from my password.

As I understand it, this means that the password cannot be being stored salted and hashed? It has to be being stored in a retrievable format. Whether that's plaintext or some way of reversible encryption.

My question is whether this can be justified? Is this really a better idea?

In my mind the benefits are:

• replay attacks are "harder" (hah!)
• customer hopefully realises phishing requesting entire password is phishing

But is that really good enough to offset the big disadvantage that it is technically very, very possible for your entire password store to be obtained?

Answer 1

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):

1. 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.
2. 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.
3. 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.

Answer 2

My question is whether this can be justified?

Sure.

Hashing passwords is not a security fundamental. It is a very specific mitigation for the case where your database gets compromised. Even in that case all it does is give you a time buffer for you to detect and analyse the compromise, communicate to users and allow them to change passwords.

A database leak is still a disastrous case for most systems, but at least with strong hashing other systems where the user has re-used the password are less likely to get hurt by your disaster.

So you can certainly justify encrypted-but-recoverable passwords if you have alternative measures that make that database leak less likely or less damaging.

That could include splitting of the sensitive data/encryption keys so that multiple systems have to be compromised to recover the passwords; putting password checking on its own server with locked down access and strong auditing against unauthorised use and detection of unusual volumes that might indicate a compromised front-end server; password format rules that make re-use on other systems unlikely... and so on.

Is this really a better idea?

There isn't an easy answer to that.

The benefit isn't readily quantifiable at the moment as there's not much accepted data out there to analyse, and benefits would certainly depend on other aspects of an organisation's security profile. (Plus it's easy to make mistakes in implementation of partial password that can scupper the potential benefits, and usually partial passwords are combined with some other form of credential as on they're own they are susceptible to brute force.)

Similarly the cost to the organisation is dependent on what other factors are employed to deter or mitigate the database leak case, and how well they fit within existing practices.

To summarise: It Depends. :-)

Answer 3

It can be justified, but it isn't necessarily better.

That said, imagine a service that log's into another service on your behalf--for example: Mint.com. It logs into your bank account and pulls your data.

Unless your bank implements OAuth, or another delegation service, Mint.com will have to store your bank credentials encrypted, so that it can act on your behalf. Prior to Twitter implementing OAuth, this was how legacy twitter apps worked with your twitter account.

This notion of storing someone's passwords on your system is a security smell, which gave rise to the trust delegation that occurs with an OAuth type system.

Also, making a generalized statement such as "hashing is better than encryption", in a vacuum, wrt security doesn't make a lot of sense given how nuanced security actually is. A poor implementation of password hashing (for example using MD5) with no-salt can be worse for your systems security than storing customer's passwords encrypted, so "better" is subjective.

Answer 4

While it is possible that the password could be stored with an encrypted HSM that restricts attempts to verify the data presented with a high degree of security, I still think the claims of what security are added are dubious compared to the information leakage presented by checking only a subset of a password. Since the gains seem dubious to me, I'd say there is no good reason to store a password in a recoverable format for authentication purposes. There is also no good way to verify if proper HSM procedures are being followed as we've seen boneheaded security decisions by large companies (and even major banks) in the past. If an HSM isn't being properly used it is a huge risk as any compromise in the database will result in leaking of all the account credentials. Passwords for authentication should always be stored in a one-way format to prevent recovery by attackers.

Note that if weak hashes are a concern, you could also always encrypt the hash to get the best of both worlds since storing it recoverable is critically dependent on key protection. Because of this, even if you have "reliable" key protection, hashing still offers more security for preventing a single point of failure.

When a password needs to be stored for use with a third party service, the password should be encrypted symmetrically with a key derived from the user's password. In this way, the passwords that are stored are unrecoverable in the event of a database breach since the stored passwords are only accessible when a password (which only the user has) is entered.

Answer 5

To ask for a part of a password is a mean to avoid it from "wearing out" too early (extreme case is OTP (One Time Password)).

I cannot be sure on how the password is stored, but it may be quite secure. The best I can think in 2 minutes is this (I am sure this can be improved):

• salt+hash each part of the password, add some random data [to each part of the password] and encrypt the bundle with a symmetric key. Store the result.
• when you get user's password piece, you decrypt the stored item, disregard the random data and compare the salt+hash

IMHO, this way of authentication may be ok as a part of the authentication process, but not the whole authentication process. If the authentication process to access my bank account is just "put letter 4 and 6 of your password" (and if your password is alphanumeric) I would be scared.