One SQL injection vulnerability gives you the password for all the users when said passwords are stored in the clear.

Yes, in many situations, you could also use a SQL injection vulnerability to overwrite a stored password hash. However, this isn’t particularly stealthy and it’ll be pretty obvious to the victim when he tries to login and can’t. I wasn’t suggesting that people use unsalted hashes — that’s why immediately after describing unsalted hashes, I pointed out the rainbow table attack.

As for dropping tables or databases, that causes disruption but it doesn’t help the attacker. They’re usually after the data so it doesn’t do them much good to delete it. Information is king.

The “CWE/SANS Top 25 Most Dangerous Programming Errors” post was Chris Wysopal’s, not mine. I’m sure he’ll respond to you when he gets some time.

I am a little bit confused. I thought that ‘one SQL injection vulnerability’ can update the database to store a one way hashed password. In that case, the solution you propose does not work (except for the one improved with salt).
And beyond that I will even say that SQLIA is worse than password theft, you can drop tables/database or even shutdown the server.

Am i missing something here ?

Kinds regards,
P.S. You did not react to my reply on ‘CWE/SANS Top 25 Most Dangerous Programming Errors’ post

Let’s assume that the time to recover a password stored as an unsalted SHA-1 is zero (it’s not, because the lookup takes a finite amount of time). But it’s pretty fast. The reason it’s fast is because you’ve pre-calculated the hashes for all possible inputs.

Now let’s assume that you’re trying to recover a password stored as a salted SHA-1 hash, where the salt is 64 bits. Unless you had some serious computational resources and storage available to you, you probably don’t have 2^64 pre-computed rainbow tables (corresponding to each of the 2^64 possible salt values). Since you don’t have a rainbow table, you can’t simply look up the hash, so your only option is to use brute force. Now you have to calculate the hash for billions of possible passwords until you eventually find the one you’re looking for. If we brute force all possible 8-character alphanumeric passwords, you’ll have to do that calculation (62^8)/2, or 109 trillion times, on average, before you recover the password. That’s what we affectionately refer to as “computationally infeasible.”

If you throw away the salt, then you can’t recover the password. But neither can the authentication routine, which is why you have to store it alongside the password.

Ah, I get it now. You’re the one actually issuing the CHAP challenge, so you need the plaintext password in order to calculate and verify the hash (or whatever sort of calculation CHAP uses for the verification step, I can’t remember). Thanks for the clarification; it’s always interesting to hear stories from the field.

The situation I was referring to is if you are writing an authentication backend supporting multiple clients. The clients under your control should absolutely support protocols allowing hashed passwords, as you suggest. If you are required to support a client that only supports CHAP or EAP-MD5, for instance, your backend still has to have access to the plaintext password.

I’m not trying to criticize your article – it’s very good. I recently was unfortunate enough to have to ‘break’ a system implemented as you suggest so that it can support legacy protocols, and thought others might appreciate the heads up. In my case, I force the administrator to explicitly enable reversibly encrypted passwords and accept the lowered security (similar to the approach taken by MS IAS.)

1. a) using a salt, can it be cracked using the rainbow tables assuming that you don’t know the salt? how much is x now?
b) same question, but this time supposing that you have no idea what’s the value of the salt

Thanks. Yes, that point is definitely worth calling out — I should have emphasized that. I could write an entire post on “don’t roll your own” (and you could probably write dozens). ;)

@Patrick:

I tried to allude to that with the example of md5crypt using 1000 iterations. But I wasn’t aware that the practice was called “key stretching.”

There are even implementations for python and Java:
http://www.mindrot.org/projects/py-bcrypt/
http://www.mindrot.org/projects/jBCrypt/