Are You Sure SHA-1+Salt Is Enough For Passwords?

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."

Passwords

[betterunixthanunix]

Easy solution: do not rely on passwords. As TFA says, people are very bad at generating random passwords, so why are we relying on them to do so? Use cryptographic authentication methods, and a lot of problems will be solved.

Then again, it has been so hard to get people to start using IPv6, I expect that the effort it would take for people to change the time honored method of authentication is simply too large.

Re:The problem is people

[vlm]

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.

Its best to go overboard and require a minimum of 15 characters, a mix of upper and lowercase, at least two non-consecutive numbers and at least two punctuation marks. And store then so they can't reuse their previous 20 passwords. That way the users will exclusively save the password in their unsecure browser, unsecure post it notes, or cut and paste from a text file, or the corporate standard database that being an excel spreadsheet. Thats how REAL security pros roll, or so I'm told.

They don't necessarily get the salt

[mysidia]

When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

Not if you encrypt the salt using the password.

Password Hash = SHA256( AES_ENCRYPT( SALT using PASSWORD ) )
Salt Hash = SHA256( SALT )

Authentication: user enters password
Does SHA256 ( AES_DECRYPT ( Password Hash using PASSWORD ) ) equal Salt Hash ?
Yes: Password Entered Correctly
No: Access Denied

Okay...waitaminute..

[Chas]

So you're saying SHA+a salt value sucks *IF THE ATTACKER ALREADY HAS ROOT ACCESS*?

Ore are you saying SHA+a salt value sucks *IF PEOPLE ARE USING WEAK DICTIONARY PASSWORDS*?

Can I get a "well fucking DUH!" here?

Seriously, exactly how tall are you claiming this molehill to be?

In BOTH cases the problem IS NOT the weakness of SHA+salt.

In the latter, the problem is some jackass used a crappy password. And even that's defensible if you have things like login restrictions and account locking in place.

In the former, well, not sure how to put this politely, THEY HAVE ROOTED YOUR BOX! At that point, you've got MUCH bigger problems on your hands than their ability to decrypt your password database.

Sorry, but this sounds like someone with SEVERE tunnel-vision here. They're so monofocused on "A" problem, that they fail to see the larger ramifications of the scenarios they construct.

Re:News at 11

[bsDaemon]

Well, seeing as how the article is about web authentication, hacking the passwd binary probably isn't that useful, depending on how the devs implemented their stuff. Probably they just take the text, pass it through a hashing function that likely punts to something like crypt() in the libc on the system, possibly picks a a salt, then stores the hashed password in a database table.

crypt() putting out des, for example, usually only uses a 2-character salt, so if you have the hashed password you can knock the first 2 chars off, pass those back into crypt() as the salt value, the brute force the rest of the key space. Compare the result of the current iteration to the hash you're trying to crack, etc. or use rainbow tables, or other methods for doing this.

Getting access to the database through a flaw in a web app is going to be a lot easier than getting a shell on the system then getting a local privilege escalation to root and replacing system binaries.