Md5crypt is no longer strong enough • Hacker News Board

Re: Md5crypt is no longer strong enough

#111

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

sveiss wrote: post #99

edoloughlin wrote: post #89

Earlier quoted context omitted.

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

To put it differently, hashing without salting lets an attacker crack the entire database at once. Try a password, see if the hash is in the database, repeat.

With salts, the attacker can only attack a single user at a time. Try a password with one user's salt, see if the hash is in the database, try the next user's salt, see if that hash is in the database, repeat.

Salts don't need to be secret to work.

Re: Md5crypt is no longer strong enough

#112

Post by dchest » Thu, Jun 07, 2012, 9:53 PM UTC

phkamp wrote: post #107

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…

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

Yes, that's what I said in parentheses.

Re: Md5crypt is no longer strong enough

#113

Post by keypusher » Thu, Jun 07, 2012, 10:12 PM UTC

jsprinkles wrote: post #36

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

Google could store passwords in plain text if they want, because they're never going to leak. I'm only partially joking.

Then at least you are only partially an idiot.

Re: Md5crypt is no longer strong enough

#114

Post by 5549900 » Thu, Jun 07, 2012, 10:13 PM UTC

The way forward for nontechnical users seems clear: avoid giving websites sensitive information and letting them store it for you. How long before Facebook is hacked?

Keep sensitive information on your own storage media, not on some website's servers connected to the internet.

Re: Md5crypt is no longer strong enough

#115

Post by snow_mac » Thu, Jun 07, 2012, 10:26 PM UTC

How about this for security MD5(SaltFromDB + Password + ApplicationConstantSalt)? How would that be affected by something like this? Given the user you'd their salt, their paassword but not the application salt. Still really insecure?

Re: Md5crypt is no longer strong enough

#116

Post by phkamp » Thu, Jun 07, 2012, 11:48 PM UTC

I've been offline for some hours, and just wish to add a few concluding thoughts here:

No, I'm obviously not proposing that people do something stupid with crypto, we've had enough of that in recent days already.

But I am trying to provoke one or more card-carrying cryptographers to realize, that while password protection may be a problem we have good and strong theoretical solution for, those solutions will not protect any passwords until somebody turn them into Open Source code we can use.

I only wrote md5crypt because nobody else had done so, and nobody else wanted to do so at the time, and FreeBSD needed an ITAR exportable password scrambler.

If more cryptographers wrote more code under liberal Open Source licenses, instead of bitchy complaints against the people who do write code, then the world might gradually become a better place

I have been dreading this announcement for a couple of years, knowing full well that the majority of the world can't tell MD5 from md5crypt.

It is a credit to hackernews that you could, much appreciated.

Re: Md5crypt is no longer strong enough

#117

Post by aethr » Thu, Jun 07, 2012, 11:51 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]

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.

Re: Md5crypt is no longer strong enough

#118

Post by dchest » Fri, Jun 08, 2012, 12:06 AM UTC

aethr wrote: post #117

chc wrote: post #98

Earlier quoted context omitted.

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] 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.

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

Re: Md5crypt is no longer strong enough

#119

Post by shard » Fri, Jun 08, 2012, 12:18 AM UTC

dchest wrote: post #118

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.

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

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

Re: Md5crypt is no longer strong enough

#120

Post by shadowfiend » Fri, Jun 08, 2012, 12:32 AM UTC

aethr wrote: post #117

chc wrote: post #98

Earlier quoted context omitted.

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] 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(password), it will not take so short a time for someone to extract passwords from rainbow tables, because they won't be able to have rainbow tables. Proper rainbow tables would need to both account for the salt and the number of encoding runs your bcrypt function has (which, incidentally, is also a configurable value).

Some information on how bcrypt, scrypt and friends apply salting and stretching to resist attacks was in yesterday's post at http://throwingfire.com/storing-passwords-securely/ . It's worth a read.