Md5crypt is no longer strong enough • Hacker News Board

Re: Md5crypt is no longer strong enough

#101

Post by [deleted] » Thu, Jun 07, 2012, 6:35 PM UTC

chc wrote: post #98

ovi256 wrote: post #63

Earlier quoted context omitted.

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…

[deleted]

Re: Md5crypt is no longer strong enough

#102

Post by sirclueless » Thu, Jun 07, 2012, 6:57 PM UTC

ordinary wrote: post #87

brian_cloutier wrote: post #82

Earlier quoted context omitted.

It's still sent in plain text. Your browser doesn't do any hashing before sending your password to Google. But you're right, as far as anybody but you and Google are concerned, it's encrypted.

There's no point in hashing the password before you send it, is there? A MITM could just as easily grab the hash and send it to Google instead.

For MITM attacks, sure. But it's a fairly portable, inexpensive way to make it more difficult to use your password with other protocols. For example, intercepting a plaintext Google password has a decent chance of making someone's bank account vulnerable.

Re: Md5crypt is no longer strong enough

#103

Post by EthanHeilman » Thu, Jun 07, 2012, 7:01 PM UTC

dchest wrote: post #79

mackcam wrote: post #72

Earlier quoted context omitted.

You must take the next paragraph into consideration: All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm (consisting of course of standard one-way hash functions like SHA2 etc) So he is in fact telling you to use a standard one-way hash function along with whatever custom implementation.

By combining two or more standard functions you're creating a different cryptographic primitive, which must be evaluated accordingly. For example (while collision resistance is not that important for password hashing), by chaining MD5(SHA1(x)) you've created a better chance of collision than if you just used SHA1(x). If you use 10 hash functions in any possible combination, you must evaluate the security of every pos…

Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.

Re: Md5crypt is no longer strong enough

#104

Post by dchest » Thu, Jun 07, 2012, 7:41 PM UTC

EthanHeilman wrote: post #103

dchest wrote: post #79

Earlier quoted context omitted.

By combining two or more standard functions you're creating a different cryptographic primitive, which must be evaluated accordingly. For example (while collision resistance is not that important for password hashing), by chaining MD5(SHA1(x)) you've created a better chance of collision than if you just used SHA1(x). If you use 10 hash functions in any possible combination, you must evaluate the security of every pos…

Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.

Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :)

(Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.)

If you read my replies in this thread, I emphasize the point that if you really need a custom function with secret parameters, use a single algorithm with a secret key (I even gave a link to one such scheme with HMAC.)

Re: Md5crypt is no longer strong enough

#105

Post by EricDeb » Thu, Jun 07, 2012, 8:43 PM UTC

tedunangst wrote: post #92

adambyrtek wrote: post #71

Earlier quoted context omitted.

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.

If an attacker gets access to a database of user names/hashes, a salt prevents him from simply checking the hashes against a precomputed list because each hash is totally unique.

The attacker would have to recompute all hashes for each user using their individual salt.

At least that's what I remember from Computer Security ha

Re: Md5crypt is no longer strong enough

#106

Post by Stefan_H » Thu, Jun 07, 2012, 9:05 PM UTC

Tyr42 wrote: post #74

Sunlis wrote: post #43

Earlier quoted context omitted.

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.

It doesn't matter that they know your salting tactic, it still stops reverse-lookup tables with common passwords online.

However any salting tactic that can be pushed and used on the client side would have a tough time using a salt that is on a per-user basis. This means that if you could salt it client side, you would need to have a static salt, which is significantly less secure than a unique salt per user.

Re: Md5crypt is no longer strong enough

#107

Post by phkamp » Thu, Jun 07, 2012, 9:43 PM UTC

dchest wrote: post #79

mackcam wrote: post #72

Earlier quoted context omitted.

You must take the next paragraph into consideration: All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm (consisting of course of standard one-way hash functions like SHA2 etc) So he is in fact telling you to use a standard one-way hash function along with whatever custom implementation.

By combining two or more standard functions you're creating a different cryptographic primitive, which must be evaluated accordingly. For example (while collision resistance is not that important for password hashing), by chaining MD5(SHA1(x)) you've created a better chance of collision than if you just used SHA1(x). If you use 10 hash functions in any possible combination, you must evaluate the security of every pos…

Collision resitance is not really a worry for a password scrambler, until the probability gets into the 1e-6 range or above.

Re: Md5crypt is no longer strong enough

#108

Post by ams6110 » Thu, Jun 07, 2012, 9:43 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.

I like this idea for sites that e.g. use Microsoft ASP.NET Membership where all you can do is set a machineKey attribute about what kind of password hashing to use, and don't support any "old hash vs. new hash" alternatives for changing. Anyone know of an implementation that would do this and "drop in" to an existing ASP.NET site? Or pointers to how to approach developing this?

Re: Md5crypt is no longer strong enough

#109

Post by EthanHeilman » Thu, Jun 07, 2012, 9:46 PM UTC

dchest wrote: post #104

EthanHeilman wrote: post #103

Earlier quoted context omitted.

Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.

Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :) (Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.) If you read my replies in…

You missed my point. I was saying that this scheme AES(key, SHA256(password|salt)) is at least as secure as this scheme SHA256(password|salt).

Re: Md5crypt is no longer strong enough

#110

Post by mikeash » Thu, Jun 07, 2012, 9:51 PM UTC

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.

If you assume 6 million users and one second to compute a password hash, that's a couple of months on a single CPU. Takes a while, but no big deal, and it can proceed while your site stays live.