"The salt needs to be known in order to validate the password, probably stored in the row with the password."
But it is not enough to know the salt. A correct implementation also includes a (lengthy) pepper, stored in the application code. If you've got that as well, and also details of how the particular hashing setup works, then it is indeed probable you would be able to brute force the hashes.
But my point is, if someone has enough access to get all that, then they can probably just silently suck off the passwords in some way anyway. They are obviously in the machines and are probably root. They could probably insert code right into your app to email them every new password coming in, pre-hashing, and you wouldn't learn about it for months.
And if they only have the user table - well, 700m hashes a second is very impressive indeed but that's still 2.7 × 10^36 seconds to brute force a 32-character pepper.
You might still think it's worth it - defence in depth and all that. But considering the price you pay, like its slowness - 0.1 seconds might sound fast but if the server's running at load then it will be more - and the hassle of having another gem, especially one with a C dependency, I do not agree.
update: actually, upon further consideration and research, fine. I'll switch to bcrypt too from now on. That's a huge gain and the cost is not that high. I guess it hadn't sunk in just how fast SHA1 implementations were getting.
I still maintain it's not the weakest link - the weakest links numbers 1 through 50 are staff - but it's a definite improvement with little cost.
No secure system depends on attackers not having access to your source code. This "pepper" idea is silly; if you believe it adds security, then you don't even have to bother with password hashing. Just XOR your passwords against a string in your code.
It does add security, because now your attacker needs the source code as well, which is probably on a different machine, requiring different login credentials, etc. Every little bit helps and it's a trivial addition to the authentication code.
Of course you would not depend upon it solely but it's called defence in depth.
You can say "defense in depth" about any idea, whether it works or it doesn't. My XOR idea --- which I am going to name "hippo", as in "your passwords should be salted, peppered, and hippoed", is also "defense in depth".
To evaluate the efficacy of a "defense in depth" measurement, insert it into an incident disclosure. For instance:
"We're sorry to inform our users that owing to an SQL Injection vulnerability, we may have disclosed the password hashes of all of our users. We believe these passwords remain safe, because an attacker would also need to have access to our source code in order to learn the secret key needed to mount a dictionary attack against them."
Compare to:
"We're sorry to inform our users that owing to an SQL Injection vulnerability, we may have disclosed the password hashes of all of our users. We believe these passwords remain safe, because the cryptographic algorithm used to create the hashes ensures that it would take over 100 years to complete a dictionary attack against a single password."
Right, this will be my last response on this, especially as I have already conceded defeat. You just like arguing, apparently.
Firstly, even in the first "disclosure" message - the passwords are indeed safe. Because of that "useless" peppering, there is no way the attackers will be able to unmask the hashes.
Secondly, if you have configured your database such that it is even possible to perform a select all on Users from the app server account, you are Doing It Wrong.
However, you are broadly right.
That said - my whole thesis here is that there are no magic bullets. Yes bcrypt is (much) better against this particular attack. But the DB server is not even web-facing and is unlikely to be compromised; the app servers are far more risky. They have access to the plaintext passwords flowing through them. When they are rooted, you're fucked no matter what hashing strategy you chose. And if you have a crooked insider - which as a security professional, you will know is by far the more likely risk - that's where they will strike as well, of course. Your precious passwords will be bcrypt hashed to the DB all right, but Mallory keeps his own plaintext backup, written by the comped bcrypt gem he snuck onto the system looking for a payday. Or whatever. There's a million ways to do it, all of them easier than brute forcing anything. You're focusing on this single scenario to the exclusion of any number of more likely attacks. Despite the hype, "steal-the-user-table" breaks are not common.
Anyway. I was wrong, and I admitted it. Use bcrypt, everyone. EOF
You only have to generate the hash during login, not during every page request. I don't think the majority of the time on most websites are spent on logging in.
You're right, but (I know I'm repeating myself) you don't even have to concede that for bcrypt to be a win. You can make hashes take sub-user-visible time and still make dictionary attacks totally infeasible. SHA1 is extremely fast. Even "just not extremely fast" is a win.
But it is not enough to know the salt. A correct implementation also includes a (lengthy) pepper, stored in the application code. If you've got that as well, and also details of how the particular hashing setup works, then it is indeed probable you would be able to brute force the hashes.
But my point is, if someone has enough access to get all that, then they can probably just silently suck off the passwords in some way anyway. They are obviously in the machines and are probably root. They could probably insert code right into your app to email them every new password coming in, pre-hashing, and you wouldn't learn about it for months.
And if they only have the user table - well, 700m hashes a second is very impressive indeed but that's still 2.7 × 10^36 seconds to brute force a 32-character pepper.
You might still think it's worth it - defence in depth and all that. But considering the price you pay, like its slowness - 0.1 seconds might sound fast but if the server's running at load then it will be more - and the hassle of having another gem, especially one with a C dependency, I do not agree.
update: actually, upon further consideration and research, fine. I'll switch to bcrypt too from now on. That's a huge gain and the cost is not that high. I guess it hadn't sunk in just how fast SHA1 implementations were getting.
I still maintain it's not the weakest link - the weakest links numbers 1 through 50 are staff - but it's a definite improvement with little cost.