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

61–70 of 144 posts

Re: Md5crypt is no longer strong enough

#61

Post by al_james »

dchest wrote: post #57
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 studi…

>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?

Agreed. The unpredictability of the work factor would be a problem.

Re: Md5crypt is no longer strong enough

#62

Post by mistercow »

bradleyjg wrote: post #56
JonnieCache wrote: post #7

Earlier quoted context omitted.

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 approv…

I tend to agree, which is why my whole comment was conditional on "if it's a good idea for everyone to use custom hash functions". Basically, if we're going to have custom hash functions, we want to reduce the "roll your own" aspect of that to a minimum.

Re: Md5crypt is no longer strong enough

#63

Post by ovi256 »

ddlatham wrote: post #48

Please notice that there is _no_ advantage in everybody in the world using the exact same algorithm, quite the contrary in fact. If your password database is leaked, there are 2 categories of attacks that you need to be concerned with: 1. Brute force 2. A weakness in your implementation He's right that brute force attacks will require potentially more work if you have a custom scheme as the attacker will have to work…

I think what he's suggesting is composing secure hash functions with some simple customisable steps, like xor, negation, so that the final result is as secure as scrypt, bcrypt, what have you, but also customized, so that standard tools won't work, and the attacker would have to do some custom legwork to attack your application. This, done correctly, would increase the cost of attacking to the point of making drive-by, mass-trolling attacks uneconomical, as they're based on pointing an exploit tool at a list of adresses.

It will not deter targeted attacks (spearfishing) by competent attackers, but again, not much would.

Re: Md5crypt is no longer strong enough

#64

Post by GoodIntentions »

dchest wrote: post #34
mistercow wrote: post #22

Earlier quoted context omitted.

>Tie a card-carrying cryptographer to a chair until he delivers it ? Alternatively, implement it very, very simply and put it on github, and ask card-carrying cryptographers to vet it. That one is harder on the ego though.

I'm pretty sure no cryptographer will vet it.

I read 'vet' as "tear it to bits"

Re: Md5crypt is no longer strong enough

#65

Post by daurnimator »

mike-cardwell wrote: post #14
16s wrote: post #13

Earlier quoted context omitted.

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…

It's pretty easy to migrate users from one hashing algorithm to another when they next log in: if( user has an old style hash ){ if( password verifies against old style hash ){ add a new style hash delete the old style hash log them in } } else { if( password verifies against new style hash ){ log them in } }

The problem is that you may have to keep this code for a VERY long time (people don't log into sites for 3+ years and expect their old passwords to still work). Lugging around legacy code is never a good idea.

Re: Md5crypt is no longer strong enough

#66

Post by JonnieCache »

bradleyjg wrote: post #56
JonnieCache wrote: post #7

Earlier quoted context omitted.

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 approv…

I hope nobody thought I was suggesting they actually do that. It was purely a matter of personal curiosity. Entropy is perhaps the most interesting thing in the universe.

I'm far too lazy to do anything other than slap bcrypt on it, unless there's a pressing need to do something else, which there never is.

Re: Md5crypt is no longer strong enough

#67

Post by mikeryan »

daurnimator wrote: post #65
mike-cardwell wrote: post #14

Earlier quoted context omitted.

It's pretty easy to migrate users from one hashing algorithm to another when they next log in: if( user has an old style hash ){ if( password verifies against old style hash ){ add a new style hash delete the old style hash log them in } } else { if( password verifies against new style hash ){ log them in } }

The problem is that you may have to keep this code for a VERY long time (people don't log into sites for 3+ years and expect their old passwords to still work). Lugging around legacy code is never a good idea.

I agree that lugging around legacy code but whats the alternative? (Note I'm not a security expert)

AFAIK its this

1. Continue using legacy, less secure hashing algorithm

2. Upgrade your password storage scheme and carry around some extra code and/or fields in your db.

3. Crack you own users passwords and convert them

Its all kind of smelly but 2 seems like the only option (unless I'm missing an option?)

Re: Md5crypt is no longer strong enough

#68

Post by mikeryan »

daurnimator wrote: post #65
mike-cardwell wrote: post #14

Earlier quoted context omitted.

It's pretty easy to migrate users from one hashing algorithm to another when they next log in: if( user has an old style hash ){ if( password verifies against old style hash ){ add a new style hash delete the old style hash log them in } } else { if( password verifies against new style hash ){ log them in } }

The problem is that you may have to keep this code for a VERY long time (people don't log into sites for 3+ years and expect their old passwords to still work). Lugging around legacy code is never a good idea.

I agree that lugging around legacy code but whats the alternative? (Note I'm not a security expert)

AFAIK its this

1. Continue using legacy, less secure hashing algorithm 2. Upgrade your password storage schem and carry around some extra code and/or fields in your db. 3. Crack you own users passwords and convert them

Its all kind of smelly but 2 seems like the only option (unless I'm missing an option?)

Re: Md5crypt is no longer strong enough

#69

Post by estel »

al_james wrote: post #52
cheald wrote: post #51

Earlier quoted context omitted.

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.

It's probably prudent for most developers to instead use phpass [0] rather than attempt to roll their own implementation.

[0] http://www.openwall.com/phpass/

Re: Md5crypt is no longer strong enough

#70

Post by moioci »

ominous_prime wrote: post #41
bigiain wrote: post #16

Earlier quoted context omitted.

" … at that time, Google accepted hashes in two formats only... MD5 or SHA1." That's, ummm, _concerning_… I don't suppose anyone knows how securely Google are storing my gmail password? I _hope_ it's not unsalted MD5 or SHA1. (Especially since google search is probably the best general purpose md5 hash reverser most people have access to.)

Last migration I did (maybe 12 months ago), google only accepted passwords as an sha1 hash IIRC. I was told however, that was only an intermediary step, and google runs that hash through another KDF for internal use. The sha1sum of the password is really only used for transport to their API, as an alternative to sending it in plain-text which is what your browser does when you login to google services, so I don't see…

I thought Google logon defaulted to SSL for all services.
Post reply on HN