Md5crypt is no longer strong enough • Hacker News Board

Re: Md5crypt is no longer strong enough

#91

Post by mike-cardwell » Thu, Jun 07, 2012, 5:35 PM UTC

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.

That would be fine if you wanted to retain the legacy hashing function. I was describing a migration from one hashing algorithm to another. You're describing modifying the existing hashing algorithm, which is something different.

Re: Md5crypt is no longer strong enough

#92

Post by tedunangst » Thu, Jun 07, 2012, 5:35 PM UTC

adambyrtek wrote: post #71

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…

Isn't salting a canonical way to vary the output for the same input, thus reducing feasibility of precomputed attacks like rainbow tables? What are the benefits of some extra mangling, besides security through obscurity?

The point is that computers are really fast now. There's no need to precompute anything, just crack hashes on the fly. The extra mangling slows things down.

Re: Md5crypt is no longer strong enough

#93

Post by daurnimator » Thu, Jun 07, 2012, 5:43 PM UTC

mikeryan wrote: post #67

daurnimator wrote: post #65

Earlier quoted context omitted.

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

4. Expire all passwords and ask your users to come reset them. - No legacy code necessary

Regular users should have no problems if there's an accompanying blog post Non-regular users might just remember about your site/service and come back :)

5. Use bcrypt/password stretching. Store the work value alongside the password and upgrade it as people log in. To me that's not really keeping legacy code around; just an extra variable...

Re: Md5crypt is no longer strong enough

#94

Post by drzaiusapelord » Thu, Jun 07, 2012, 5:47 PM UTC

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…

Excellent points. From a practical perspective not every website is going to get into the game of cryptography but its trivial to get into the game of salting. The fact that places like linkedin don't salt doesn't mean our algorithms are bad, it means the kinds of people who built the system there are bad.

Re: Md5crypt is no longer strong enough

#95

Post by lolcraft » Thu, Jun 07, 2012, 5:53 PM UTC

mike-cardwell wrote: post #28

udp wrote: post #26

Earlier quoted context omitted.

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

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

Note that getting the client to send only the hashed password is incredibly silly. If there's a leak, the hackers do not even have to crack those passwords.

Re: Md5crypt is no longer strong enough

#96

Post by StavrosK » Thu, Jun 07, 2012, 5:57 PM UTC

mike-cardwell wrote: post #91

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.

That would be fine if you wanted to retain the legacy hashing function. I was describing a migration from one hashing algorithm to another. You're describing modifying the existing hashing algorithm, which is something different.

It depends if your goal is to have security for everyone right away or if it's to only use one hashing function. I don't see anything wrong with a round of SHA1 in your setup, especially when it allows you to secure everyone's password immediately...

Re: Md5crypt is no longer strong enough

#97

Post by stcredzero » Thu, Jun 07, 2012, 6:05 PM UTC

For server-side, how about password DB implemented as hardened information appliances? This would make the acquisition of the password database harder. White-box techniques could be used to hide a modified salting technique, making cracking much more labor intensive. Such a service could be offered by cloud and virtual server providers, perhaps for a small additional fee. (Which would still be almost all profit.)

Re: Md5crypt is no longer strong enough

#98

Post by chc » Thu, Jun 07, 2012, 6:17 PM UTC

ovi256 wrote: post #63

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

The idea that my customizations would make it appreciably more secure (especially vs. just slightly increasing the work factor) seems questionable to me. On the other hand, it's very plausible that my customizations could accidentally make it less secure. Way smarter folks than me have messed up algorithms they actually put a lot of thought into — I'm not going to go blithely turning knobs in good algorithms and hope their positions weren't important.

Incidentally, what kind of drive-by attack are you thinking? Like, you have your password database sitting out in the open and there are bots crawling the web trying mechanically to crack it? Because that doesn't sound like a common case, but I'm not sure what else you could mean.

Re: Md5crypt is no longer strong enough

#99

Post by sveiss » Thu, Jun 07, 2012, 6:18 PM UTC

edoloughlin wrote: post #89

michaelmior wrote: post #39

Earlier quoted context omitted.

Graceful degradation is pretty easy. Override the form submit handler to hash the password, set a flag that the password is hashed, empty the original password, and submit the form. Users with JS blocked will just submit the unhashed password as usual. Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful. Finally, if your server will accept hashed passwords, then getting…

> Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful. I've seen this advised a lot. However, where are you going to put the per-user salt? I presume in your users table, or somewhere in your db. Does this not mean that the salts are just as likely to be hacked as the encrypted passwords? Are you not better off with either a single salt that's stored somewhere outside y…

Salts aren't meant to be secret (or rather, no more secret than the password hashes themselves). The goal is to prevent a precomputed brute force attack.

If you store straight unsalted hashes, you can precompute the hash for every likely password, store the precomputed hash -> password mappings in a nice efficient data structure (http://en.wikipedia.org/wiki/Rainbow_table) and use the same precomputed tables to reverse every hash in the system with a very fast lookup. And every other system using the same unsalted hash scheme.

If you have a salt, this doesn't work -- you'd need a set of precomputed tables for each salt value, which rather defeats the object of precomputation.

If you take it a step further, and use a storage scheme like bcrypt or PBKDF2, not only are you protected from the precomputation attacks, but testing each password candidate takes much longer than a straight cryptographic hash -- so brute force attacks becomes much slower, too.

Re: Md5crypt is no longer strong enough

#100

Post by michaelmior » Thu, Jun 07, 2012, 6:27 PM UTC

edoloughlin wrote: post #89

michaelmior wrote: post #39

Earlier quoted context omitted.

Graceful degradation is pretty easy. Override the form submit handler to hash the password, set a flag that the password is hashed, empty the original password, and submit the form. Users with JS blocked will just submit the unhashed password as usual. Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful. Finally, if your server will accept hashed passwords, then getting…

> Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful. I've seen this advised a lot. However, where are you going to put the per-user salt? I presume in your users table, or somewhere in your db. Does this not mean that the salts are just as likely to be hacked as the encrypted passwords? Are you not better off with either a single salt that's stored somewhere outside y…

My point was that sending the hash the server doesn't work if the hash is salted per user since you don't know what the salt is. (I suppose you asynchronously fetch the salt value after the user puts in a username, but at the solution as a whole starts to fall apart.)