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

41–50 of 144 posts

Re: Md5crypt is no longer strong enough

#41

Post by ominous_prime »

bigiain wrote: post #16
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…

" … 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 it as a huge problem. Sure it could be more secure, but interoperability and keeping a relatively low barrier of entry are very important to them too.

Re: Md5crypt is no longer strong enough

#42

Post by pwaring »

StavrosK wrote: post #35
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 } }

Eh, why not just bcrypt the SHA1/MD5 hashes? Your auth check will just become bcrypt(SHA1(pass)) rather than bcrypt(pass). You can convert all passwords right away and I don't see any significant downside to it.

Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table? Given that bcrypt is intentionally 'slow', this might be a problem for applications with large numbers of users (albeit a one-off cost).

I agree that for small sites, changing the auth check and updating all the existing rows (and deleting/overwriting the old hashes) is probably the best solution though.

Re: Md5crypt is no longer strong enough

#43

Post by Sunlis »

udp wrote: post #26
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 } }

You mean you're sending unhashed passwords from the client?

What would be the point of hashing on the client? Let's say you're using md5, and you hash the password before you send it. Chances are, that un-salted hash can be easily decrypted by any number of reverse-lookup tables around online. You can't salt the hash client side, because anyone can look at your JS and find your salting tactic.

The best approach to securing information going from client to server is SSL.

Re: Md5crypt is no longer strong enough

#44

Post by cheald »

KhalidAbuhakmeh wrote: post #6

It's very telling that hardware is outpacing our own cryptographic techniques. I remember reading an article that stated that all passwords will someday be crackable due the advances in Quantum computing. By that time we'll all know that your password is "I Love Care Bears 123" :P

Hardware is not outpacing our cryptographic techniques. Go spin up an AWS GPU cluster to break an AES-256-encrypted file and let me know what the bill runs you.

md5crypt is a "poor man's" crypto system, simply because it's built on MD5, which is intended to verify data integrity more than it is designed to hide information. We've known that md5 was broken since 2004, so at this point, anyone actually using MD5-based systems for password hiding really has no excuse.

Quantum computing is a whole 'nother ballgame, and while it does offer the promise of making current encryption schemes more or less obsolete, it's an entirely different ballgame than "chain together a few Radeon cards and crack a DB full of MD5 hashes".

Re: Md5crypt is no longer strong enough

#45

Post by cheald »

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.

Re: Md5crypt is no longer strong enough

#46

Post by mike-cardwell »

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…

If the server is hacked, then all bets are off. They can just modify the webpage if they want the un-hashed password.

Re: Md5crypt is no longer strong enough

#47

Post by StavrosK »

pwaring wrote: post #42
StavrosK wrote: post #35

Earlier quoted context omitted.

Eh, why not just bcrypt the SHA1/MD5 hashes? Your auth check will just become bcrypt(SHA1(pass)) rather than bcrypt(pass). You can convert all passwords right away and I don't see any significant downside to it.

Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table? Given that bcrypt is intentionally 'slow', this might be a problem for applications with large numbers of users (albeit a one-off cost). I agree that for small sites, changing the auth check and updating all the existing rows (and deleting/overwriting the old hashes) is probably the best solution though.

> Will there not be a time lapse whilst you run bcrypt on all the existing hashes to update your users table?

No, just SHA1 the password and check, and then bcrypt(SHA1) and check, until the encryption process finishes. Or just check the length, or store the hash type along with the hash, a la Django. These problems are trivial, really.

Re: Md5crypt is no longer strong enough

#48

Post by ddlatham »

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 out the details of the scheme before using brute force (category 1).

However, many cryptographic compromises are actually due to bugs or weaknesses in the implementation (category 2); i.e. on paper your custom combination of schemes is fine, but you made a bug in implementing it or forgot to handle some case correctly.

How can you have confidence that your scheme is safe from category 2 attacks? Use a scheme that has already been widely reviewed and attacked. If no one has been able to find a vulnerability in it thus far, there's a good chance that your attacker won't either.

So there _is_ an advantage to using the same scheme that many others use. Use something hard, like scrypt, bcrypt, or PBKDF2, but also find an implementation of it that is likely to have been well used, reviewed, and hopefully attacked.

Re: Md5crypt is no longer strong enough

#49

Post by al_james »

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.

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

Re: Md5crypt is no longer strong enough

#50

Post by repsilat »

mike-cardwell wrote: post #46
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…

If the server is hacked, then all bets are off. They can just modify the webpage if they want the un-hashed password.

Exactly - "Things are necessarily crappier on the web, of course."

I wonder, though. Could there be a "code has changed" warning from the client? I mean, authentication should be pretty damn stable, and maybe even universal. If someone does modify the page, it'd be nice to know if that change was reflected on other sites, and it'd be nice to know that someone I trust had signed off on it (cryptographically).

A simple alternative is to build it into browsers. A password field could generate a salt per-domain and automatically encrypt any queries to password-fields. The server doesn't even need to know about it. You'd have to be more than a little careful building it, obviously, and you'd have to find a way to deal with passwords used on more than one site, but it could work.

Post reply on HN