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

121–130 of 144 posts

Re: Md5crypt is no longer strong enough

#121

Post by drivebyacct2 »

ams6110 wrote: post #108
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.

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?

Don't use ASP.NET membership? I can't get over how much effort they put into MVC ASP.NET and they still carry that cludgy mess around.

Re: Md5crypt is no longer strong enough

#122

Post by jlgreco »

shard wrote: post #119
dchest wrote: post #118

Earlier quoted context omitted.

You don't know what you're talking about.

Please elaborate for those of us who are not experts on cryptography.

For one, salts prevent using rainbow tables. A random combination of hashes with tweakable knobs, or whatever his suggestion is, is just a complicated way of salting except you have the possibility of weakening your function if you don't know what you are doing (as another has already mentioned, the unexpected behaviour of combining DES should be remembered).

Re: Md5crypt is no longer strong enough

#123

Post by aethr »

shadowfiend wrote: post #120
aethr wrote: post #117

Earlier quoted context omitted.

[deleted] This comment was factually incorrect and only served to cloud the issue. The link given in one of the responses provides more than enough information for a developer to understand the options available for password storage. Apologies for the noise.

bcrypt in and of itself already uses multiple runs to make it expensive in terms of CPU time to reproduce a given password. Moreover, salts are precisely designed to help against rainbow table attacks by making it infeasible to create rainbow tables including the large number of salts that you tag onto the end of a given password. bcrypt includes a salt as part of its core. So no, if your scheme is “simply” bcrypt(pa…

Yes, you're completely right. I was actually trying to illustrate the "tweakable knobs" concept in bcrypt in my nested example but I can see that my explanation was not helpful, and served to confuse the issue.

Thank you for clarifying!

Re: Md5crypt is no longer strong enough

#125

Post by ricardobeat »

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.

Why not do both then?

    1. bcrypt(SHA1(pass)) right now to secure all pws
    2. check against that, then update to bcrypt(pass) on login

Re: Md5crypt is no longer strong enough

#126

Post by ams6110 »

drivebyacct2 wrote: post #121
ams6110 wrote: post #108

Earlier quoted context omitted.

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?

Don't use ASP.NET membership? I can't get over how much effort they put into MVC ASP.NET and they still carry that cludgy mess around.

Sometimes you have to deal with what you are given.

Re: Md5crypt is no longer strong enough

#127

Post by astrodust »

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?

Salting means that you must crack each key individually. It slows things down marginally in the long-run and at least precludes someone form using Google as your rainbow table. Have you ever tried searching for MD5 hashes of things like 'password' or 'pass123'? It's terrifying.

Re: Md5crypt is no longer strong enough

#128

Post by drivebyacct2 »

ams6110 wrote: post #126
drivebyacct2 wrote: post #121

Earlier quoted context omitted.

Don't use ASP.NET membership? I can't get over how much effort they put into MVC ASP.NET and they still carry that cludgy mess around.

Sometimes you have to deal with what you are given.

That's fair, my snark doesn't help with that, as I was in that same position about a year ago and opted to just leave it and pretend it wasn't there.

I'm sure there is a way to improve it, but I don't know how, sorry!

Re: Md5crypt is no longer strong enough

#129

Post by FaceKicker »

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.

But in that case the password has only been compromised on that one website, as opposed to every other website where it's being used (likely a non-zero number of them given the average user's password habits). I'm no security expert but I think client-side password hashing with the domain name as the salt seems like a pretty good idea, especially for sites without HTTPS logins (but it also helps in the case of a database leak even for sites with HTTPS logins). Of course, for non-HTTPS logins a network attacker could modify the HTML form code to remove the client-side hashing without the user's knowledge, but it's still at least as secure as the alternative, modulo 'false sense of security' type arguments.

Edit: never mind the last parenthetical; it pretty much wouldn't help in a database leak at all (just adds one extra hashing step to the cracking process), sorry. Still helps for non-HTTPS logins though.

Edit 2: ... though maybe if the client-side hash were something strong like bcrypt, it would help in the case of database leaks on HTTPS sites that refuse to use strong hashing on the server side for performance reasons. Sorry for the rambly disorganized post.

Re: Md5crypt is no longer strong enough

#130

Post by [deleted] »

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.

[deleted]
Post reply on HN