Slashdot Mirror

So what?

Not sure if you're trolling, unaware or making some sort of pedantic argument. Key stretching and adaptive hashing are considered best practice and here's a couple references to read up on including some from TFA. These solutions will partially mitigate the impact of weak passwords.

http://plaintextoffenders.com/...
https://codahale.com/how-to-sa...
https://nakedsecurity.sophos.c...

Weak passwords are even more vulnerable with a fast hashing algorithm. Hashed password storage should use bcrypt, which is intentionally slow, and makes dictionary attacks less practical.

Yup, that is indeed what's missing inside something like openssl.
Throw in a secure compare in way that doesn't cause confusion (i.e.: avoid's openssl's CRYPTO_memcmp vs OPENSSL_memcmp. If you really need the later, call it something unambiguous like "leaky_memcmp"), and bound checked substring copy, and you have basically covered all needs of a crypto library.

They actually state: "LivingSocial passwords were hashed with SHA1 using a random 40 byte salt." Source: https://www.livingsocial.com/createpassword

I'm glad they aren't using MD5, but wish they were using at least SHA-256 (SHA-1 has had flaws exposed). Or ideally bcrypt.

Honestly, as a web developer myself, there really is no reason not to use bcrypt.

This is completely orthogonal to the fact that salted hashed passwords have never been an appropriate means to store a password. http://codahale.com/how-to-safely-store-a-password/

Nah, you are. Hashes are used for a lot more than just passwords. Yes, for passwords a fast generic hash function like SHA2 or SHA3 (let alone MD5) is not such a good option. But for verifying that a downloaded executable or other file has not been modified, it's mostly fine. But don't use MD5, because it's completely broken (e.g. with it being possible to have two distinct PDF files having the same hash).

For password hashing use Blowfish/Bcrypt.

ok, a hash+salt is not an option to do this, maybe it was at some point, but it isn't atm =/, the rest of the advice do applies tho.
http://codahale.com/how-to-safely-store-a-password/

While one can arguably say everything can be hacked (unless air-gapped), in certain scenarios you can at least mitigate the impact of a breach to make it almost irrelevant.

Easiest example is password storing. Some SQLi may get through and provide someone with a dump of your user passwords, but if you follow up to date recommended security practices, the data will be nearly useless.

Beind said that, just by reading the Web Application Hacker's Handbook and following all of its recommendations you will have a pretty secured app.

Awesome. Sounds like they were doing things right.

To be blunt and brutish: No, no and *no*. Until not that long ago, I too believed that hashing and salting was the Right Way, but it seems Moore's Law got us on that one as well. As this article explains, most general-purpose hashing algorithms - like SHA2 and (the hopefully obsolete) MD5 - are designed for speedy computation, not for password security. Salting adds a layer of security indeed, fighting the much clamored rainbow tables, but it turns out CPU cycles are easy enough to come by now to crack truly *vast* amounts of "bad" hashes in nominal time. If you currently rely on SHAx or MD5, suspect you might one day need to design a password storage system, or simply have an interest, do read that article right away, then do some more research.

If it takes a cracker 0.3 seconds, as described in the article you cited, then it also takes the legit server 0.3 seconds to authenticate the user. If a lot of people submit the login form at once, this becomes a denial-of-service attack against the server.

doing multiple hashes of the password in a big enough magnitude for it to become slow

Hash algorithms like SHA1 and MD5 are designed to be fast. This is great if you are fingerprinting large amounts of data looking for patterns, comparing files, etc.. This is not great if you don't want your passwords to be brute-forced.

Rainbow tables are not the real danger to hashes. The real danger is simply that brute-forcing many password hashes is startlingly fast on modern hardware.

If you're hashing passwords that need to be safe from brute-forcing, use something like bcrypt, which let's you set a work factor.

More explanation here:
http://codahale.com/how-to-safely-store-a-password/

If you're using anything other than PBKDF2, bcrypt or scrypt to store your user's passwords, you have already lost.

Why is this even a question? Use bcrypt, always. (Preferably using the $5$ or $6$ extensions.)

mysql only offers AES, DES, MD5, and SHA... So... for at least a certain subset of developers, thats what they're going to use.

I'm not saying they're correct to do so, I'm just explaining why they will not even consider your suggestion, because they have architectural problems, for them its not as simple as search and replace all calls to md5() with bcrypt().

Why is this even a question? Use bcrypt, always. (Preferably using the $5$ or $6$ extensions.)

No, you're actually wrong - in the context of password protection, encrypting passwords means using a one-way encryption scheme. The method is in some ways similar to hashing, but the common process used is actually that of a modified version of the Blowfish crypto cipher resulting in a non-reversible output. The process is very time-consuming compared to generic hashing such as MD5, SHAx etc., and is practically impossible to create rainbow tables for, practically impossible to bruteforce. You can educate yourself further on the topic here: http://codahale.com/how-to-safely-store-a-password/

Or, better yet, just use the system designed to store passwords: bcrypt.

I recently rejected bcrypt because it seemed to have no way of increasing the verification cost on an existing hash, as would be needed a few years down the road. Was I wrong?

Also, articles promoting bcrypt often suggest not using SHA-1 because it runs fast in a GPU/FPGA. Can't bcrypt be made faster in a similar way?

Salting addresses some attacks, but as CPU time becomes cheaper, it becomes increasingly feasible to brute-force even salted hashes. To address this issue, you need key strengthening as well.

Or, better yet, just use the system designed to store passwords: bcrypt.

*sigh* Then again, I'm confident that we'll see incompetent web application developers using unsalted MD5 for decades to come. People don't learn from others' mistakes it seems.

Hashed passwords provide a degree of protection, so long as you salt the hash, and store a different salt for each password (for maximum protection).

Any programmer that doesn't understand salts, hashing, and encrypting should not bother making software that handles logins, period.

Unless you were intending to be ironic, salted hashes (even with per-user salts) do not offer maximum protection. Use bcrypt instead: http://codahale.com/how-to-safely-store-a-password/

See this thread for additional discussion behind it: http://news.ycombinator.com/item?id=1091104