Is it safe to hash passwords that protect sensitiv

Question

I've been in discussion with this security guy. He's probably the most I can afford for my new project. Anyways, it is a service that saves sensitive data (Password, PINs) that can be requested by the user via phone. The user has a password (4 digits) which he uses to access the sensitive data. The security guy told me he would use MD5 to hash the password that is used to access the sensitive data. Here the discussion started, as I thought, and am quite sure, that MD5 is too vulnerable since it has been cracked/collisions have been caused.

What hashing method should be used to hash passwords that protect sensitive information? I have a feeling that this service might become a high value target for hackers, so I'm really worried about it. I'm starting to worry about the overal quality, and especcialy security of services the security guy is going to deliver, but have no idea where to find others.

Answer 1

Yes, MD5 is severly compromised. I would advice you to use a PBKDF2 functionality, which would provide a much better security.

MD5 security

PBKDF2 Wikipedia article

I would recommend using a stronger password than a 4 digit one, though.

Answer 2

While MD5 is broken, these vulnerabilities don't affect password hashing. So MD5 instead of better hash functions isn't the problem here. Still I generally recommend using a better hash function.

Normally use some method to hash slower and add a salt. Check Wikipedia on Key Deriviation Functions. PBKDF2 and bcrypt are popular choices for KDFs.

But I can think of no way to protect a 4 digit password. There are only 10'000 different passwords. It's trivial to bruteforce. Even salts and KDFs won't help you.

Systems using low entropy PINs rely on the checking server/hardware never getting compromised. So they can lock an attacker out after a few wrong attempts. But you can't do that if the attacker gains access to the password hash.

Answer 3

There is an easy method to figure this out, based on risk.

By definition, Risk is Hazard times probability of the undesired event. In this case, you're concerned about the probability of an MD5 hash being cracked, which is certainly significant. But with a PIN that's only 4 digits long, the probability of a straight out brute force attack succeeding in one try is only 10^-4, so depending on the value of the data, you pretty quickly get to an undesirable risk.

In any case, the probability of cracking an MD5 in one trial is very likely much smaller than 10^-4, so he's probably correct.

Answer 4

Think about it, why are you hashing passwords? Because even if your database is stolen, the intruder won't be able to find a password based on the hash. But: if the space of your passwords is 4 digits (10000 combinations), how long will it take to find a password that matches given MD5 hash? One millisecond? You will hit the same security vulnerability with any modern hash function (MD5 isn't considered secure nowadays).

What you need is salting with a very long salt. For each user create some random data (called salt) and compute hash(password + salt). You aren't obviously storing passwords, but you will store hashes and salts per each user. Second thought: 4-digit password with salt still isn't secure - all you get is that the intruder will have to brute-force password per each user, but with 10K key space this is still trivial. I don't know any other method that will protect such a short password.

Answer 5

I see a number of problems here.

First, if a four-digit passcode is all that is preventing access to your uber-sensitive data, you're in trouble. I hope that there are other security measures in place, since brute-forcing 10,000 combinations by hand is trivial, much less with some kind of script.

Second, I'm not sure you understand the point of hashing the passwords. I doubt you will get a hash collision just from 10,000 possibilities, but that is basically irrelevant when the passwords can be brute-forced. All you are accomplishing is a little bit of obfuscation from someone with read access to the database.

Third, the needs of a password hashing algorithm are different than the needs of other hashing algorithms. You need the algorithm to be slow, which usually means having to run it repeatedly, and you need for there to be salt so that the password cannot be derived from a lookup table. Supposedly, Blowfish isn't bad. I find the pgcrypto docs from PostgreSQL have a pretty good explanation.