Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Md5crypt is no longer strong enough

phk.freebsd.dk

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Md5crypt is no longer strong enough

#51

Post by cheald »

al_james wrote: post #49
cheald wrote: post #45

Earlier quoted context omitted.

Why is this any more secure than keeping a salt in your code? bcrypt(password + hardcoded application salt + db-stored user salt) is far less complex and arguably just as secure, since your argument is predicated on "assume the source code is safe". bcrypt is tunable to be as slow as you want, even to account for hardware progress.

>bcrypt is tunable to be as slow as you want, even to account for hardware progress. I did not know that. Can you expand on this point?

Part of the bcrypt process includes a "work factor", which is, crudely, "how many times do I run this?" What you can do is tune your work factor so that it takes a reasonably long time to hash a password (say, 0.05 sec on your webserver = 20 passwords/sec), which won't necessarily heavily impact the performance of your website, but which would be a significant impediment to anyone trying to brute-force those passwords.

As hardware improves, you just implement a system wherein when the user submits login information, you verify their password with your old work factor, and if it passes, re-hash with your new (slower) work factor and store the updated hash. This allows you to effectively use a progressively slower algorithm over the lifetime of your application to compensate for Moore's Law.

You obviously don't want to pick a work factor that's too high for your web server hardware, since that opens you up to DOS attacks, but a reasonable work factor can easily mitigate the weaknesses of MD5 and SHA1 - notably, that they can be computed by the hundreds of millions of second on the right harware.

Re: Md5crypt is no longer strong enough

#52

Post by al_james »

cheald wrote: post #51
al_james wrote: post #49

Earlier quoted context omitted.

>bcrypt is tunable to be as slow as you want, even to account for hardware progress. I did not know that. Can you expand on this point?

Part of the bcrypt process includes a "work factor", which is, crudely, "how many times do I run this?" What you can do is tune your work factor so that it takes a reasonably long time to hash a password (say, 0.05 sec on your webserver = 20 passwords/sec), which won't necessarily heavily impact the performance of your website, but which would be a significant impediment to anyone trying to brute-force those password…

Ok, got it. Thanks. Yes, much better. I was under the impression bcrypt was also a fixed cost operation.

If anyone else is wondering how to implement bcrypt with a cost parameter in PHP, see http://php.net/manual/en/function.crypt.php under CRYPT_BLOWFISH.

Re: Md5crypt is no longer strong enough

#53

Post by Retric »

repsilat wrote: post #38
mike-cardwell wrote: post #28

Earlier quoted context omitted.

Yes. That is the standard behaviour that nearly all sites use, and is perfectly fine.

It's not great, though - it means that someone who hacks your server can get users' passwords a lot easier. I read a couple of weeks ago that Blizzard's games don't send the passwords to the server, they send a hash. Things are necessarily crappier on the web, of course. Edit: there's more detail at the link below. It looks clear that in at least some of their schemes they deliberately do not send the client password…

Sending a hash is no different than sending a plain text password. Because the attacker has complete control at their end and can just hack a client that sends that same hash even if they don't know the original password.

Re: Md5crypt is no longer strong enough

#54

Post by jedbrown »

cheald wrote: post #45
al_james wrote: post #40

Here's a (potentially stupid) idea: The app provides a fixed 'secret key' that defines (somehow) a sequence of hashing and scrambling functions to apply to the password. So, for example, the secret key "df8dfuhuejew3" (or whatever) might be interpreted as '3 iterations of md5 hash followed by rotate hash 5 places to the left followed by 2 iterations of bcypt etc..'. So, in effect, each app (with a different secret ke…

Why is this any more secure than keeping a salt in your code? bcrypt(password + hardcoded application salt + db-stored user salt) is far less complex and arguably just as secure, since your argument is predicated on "assume the source code is safe". bcrypt is tunable to be as slow as you want, even to account for hardware progress.

PHK is not concerned with preventing precomputed (rainbow table) attacks. A salt is fine for that. He wants to make it harder to create special-purpose hardware for brute-forcing. Combining many different types of hashes is only intended to eat up die space.

Re: Md5crypt is no longer strong enough

#56

Post by bradleyjg »

JonnieCache wrote: post #7
mistercow wrote: post #4

Earlier quoted context omitted.

Also, if that's what should be encouraged, someone might as well put together a simple framework for automating it. Basically, you hard code a list of salts and a list of hash function names (which could also be automatically generated by a tool), and it gives you a new hash function which is the composition of those other functions. There's no reason for everyone to try to do it by hand and risk messing it up in som…

The PBKDF2 protocol allows you to safely brew your own password scrambler using any hash functions you choose. It is equivalent to bcrypt for common purposes, assuming the hash functions you pick are decent. Here's a question for the people here who actually know wtf they're talking about: if I choose to iterate through a set of hash functions with each pass of PBKDF2 rather than using the same one each time, what ef…

There is no per se answer to that question. Cryptanalysis is hard, you can't assume things like commutativity and orthogonality.

This whole line of thought is at best a waste of time, and at worst dangerous.

PBKDF2-HMAC-SHA-256 is a vetted NIST approved standard with an adjustable work factor. It has been subject to professional attention for many years.

BCrypt, while not subject to nearly as much analysis nor approved by NIST, was designed by very competent cryptographers, has an adjustable work factor and is based on blowfish -- which has been subject to substantial professional attention.

Use one of the above with the highest work factor you have the processing power for and call it a day. Don't try to roll your solution.

Re: Md5crypt is no longer strong enough

#57

Post by dchest »

al_james wrote: post #40

Here's a (potentially stupid) idea: The app provides a fixed 'secret key' that defines (somehow) a sequence of hashing and scrambling functions to apply to the password. So, for example, the secret key "df8dfuhuejew3" (or whatever) might be interpreted as '3 iterations of md5 hash followed by rotate hash 5 places to the left followed by 2 iterations of bcypt etc..'. So, in effect, each app (with a different secret ke…

Again, if you really need to use a secret algorithm, instead use a secret key with the known proven algorithm (see for example https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#...)

That the security of a cipher system should depend on the key and not the algorithm has become a truism in the computer era, and this one is the best-remembered of Kerckhoffs's dicta. ... Unlike a key, an algorithm can be studied and analyzed by experts to determine if it is likely to be secure. An algorithm that you have invented yourself and kept secret has not had the opportunity for such review.

http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle#Implic...

Moreover, you made the security of your system "key"-dependent: what if I generate such "key" that will only use 5 iterations of MD5 and 1 iteration of SHA-1? This would be a major failure. Imagine if the security of AES was not 2^128, but varied between 2^10 to 2^128 depending on what key you supplied -- would you use it?

Re: Md5crypt is no longer strong enough

#58

Post by jonknee »

16s wrote: post #13
gibybo wrote: post #2

>All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm for their site He probably means to use some combination of well known/tested algorithms rather than inventing your own crypto, but I think his wording is ambiguous enough to be dangerous. While there is some benefit to using a unique algorithm for your site, it's almost certainly more risky than using a…

One, often over-looked reason, that website designers chose simple MD5 or SHA1 hashing (and why many still do) is for portability. Years ago this was more of an issue than it is today. They may wish to change web frameworks, programming languages, service providers, etc. and when doing so they want a simple, easy way to use the hashes they have. Also, many big service providers still use MD5 or SHA1. I saw a company…

> Google accepted hashes in two formats only... MD5 or SHA1.

It's not surprising that they don't support importing custom formats. They support two formats to bulk-import and then surely convert to their standard from there.

Re: Md5crypt is no longer strong enough

#60

Post by monkeyfacebag »

Retric wrote: post #53
repsilat wrote: post #38

Earlier quoted context omitted.

It's not great, though - it means that someone who hacks your server can get users' passwords a lot easier. I read a couple of weeks ago that Blizzard's games don't send the passwords to the server, they send a hash. Things are necessarily crappier on the web, of course. Edit: there's more detail at the link below. It looks clear that in at least some of their schemes they deliberately do not send the client password…

Sending a hash is no different than sending a plain text password. Because the attacker has complete control at their end and can just hack a client that sends that same hash even if they don't know the original password.

Would it not be an aid to users in cases where they are reusing the same password on multiple sites?
Post reply on HN