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

81–90 of 144 posts

Re: Md5crypt is no longer strong enough

#81

Post by JonnieCache »

darkarmani wrote: post #77
JonnieCache wrote: post #7

Earlier quoted context omitted.

The PBKDF2 protocol allows you to safely brew your own password scrambler using any hash functions you choose. It is equivalent to bcrypt for common purposes, assuming the hash functions you pick are decent. Here's a question for the people here who actually know wtf they're talking about: if I choose to iterate through a set of hash functions with each pass of PBKDF2 rather than using the same one each time, what ef…

> The PBKDF2 protocol allows you to safely brew your own password scrambler using any hash functions you choose. It is equivalent to bcrypt for common purposes, assuming the hash functions you pick are decent. NO! Bcrypt in particular is designed to resist GPU brute forcing.

Yes, that's why I said "common purposes." If you're seriously worried about people bringing racks of GPUs to bear against you then what you're doing probably isn't "common," although I accept that this is rapidly changing.

Re: Md5crypt is no longer strong enough

#82

Post by brian_cloutier »

moioci wrote: post #70
ominous_prime wrote: post #41

Earlier quoted context omitted.

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…

I thought Google logon defaulted to SSL for all services.

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.

Re: Md5crypt is no longer strong enough

#83

Post by dchest »

JonnieCache wrote: post #81
darkarmani wrote: post #77

Earlier quoted context omitted.

> The PBKDF2 protocol allows you to safely brew your own password scrambler using any hash functions you choose. It is equivalent to bcrypt for common purposes, assuming the hash functions you pick are decent. NO! Bcrypt in particular is designed to resist GPU brute forcing.

Yes, that's why I said "common purposes." If you're seriously worried about people bringing racks of GPUs to bear against you then what you're doing probably isn't "common," although I accept that this is rapidly changing.

You can calculate billions of SHA-1 hashes per second on a single $100 graphics card using standard software. That's pretty common. There's AFAIK no implementation of bcrypt for GPU.

Re: Md5crypt is no longer strong enough

#84

Post by IsTom »

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…

Such combinations could end up worse sometimes, just like 2DES has the same strength as DES.

Re: Md5crypt is no longer strong enough

#85

Post by JonnieCache »

dchest wrote: post #83
JonnieCache wrote: post #81

Earlier quoted context omitted.

Yes, that's why I said "common purposes." If you're seriously worried about people bringing racks of GPUs to bear against you then what you're doing probably isn't "common," although I accept that this is rapidly changing.

You can calculate billions of SHA-1 hashes per second on a single $100 graphics card using standard software. That's pretty common. There's AFAIK no implementation of bcrypt for GPU.

Yes, but an opportunistic blackhat will just go and attack one of the millions of sites which don't need GPUs to crack instead. It's a margins game, like anything else.

If you're being attacked by anyone other than opportunists, you have bigger problems than your hash function. As soon as someone attacks you specifically, you're in a "trust no-one" situation, and suddenly it's time for anonymous meetings in basement carparks and the like.

Re: Md5crypt is no longer strong enough

#86

Post by dchest »

JonnieCache wrote: post #85
dchest wrote: post #83

Earlier quoted context omitted.

You can calculate billions of SHA-1 hashes per second on a single $100 graphics card using standard software. That's pretty common. There's AFAIK no implementation of bcrypt for GPU.

Yes, but an opportunistic blackhat will just go and attack one of the millions of sites which don't need GPUs to crack instead. It's a margins game, like anything else. If you're being attacked by anyone other than opportunists, you have bigger problems than your hash function. As soon as someone attacks you specifically, you're in a "trust no-one" situation, and suddenly it's time for anonymous meetings in basement…

I don't understand. If your "opportunistic blackhat" is willing to attack something, what are the chances that he doesn't have a pretty normal standard graphics card for this in his PC?

Re: Md5crypt is no longer strong enough

#87

Post by ordinary »

brian_cloutier wrote: post #82
moioci wrote: post #70

Earlier quoted context omitted.

I thought Google logon defaulted to SSL for all services.

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.

Re: Md5crypt is no longer strong enough

#88

Post by JonnieCache »

dchest wrote: post #86
JonnieCache wrote: post #85

Earlier quoted context omitted.

Yes, but an opportunistic blackhat will just go and attack one of the millions of sites which don't need GPUs to crack instead. It's a margins game, like anything else. If you're being attacked by anyone other than opportunists, you have bigger problems than your hash function. As soon as someone attacks you specifically, you're in a "trust no-one" situation, and suddenly it's time for anonymous meetings in basement…

I don't understand. If your "opportunistic blackhat" is willing to attack something, what are the chances that he doesn't have a pretty normal standard graphics card for this in his PC?

He probably does. What I'm saying is, why would he put that to work cracking n PBKDF2-HMAC-SHA-256 hashes per hour for n dollars per hour, when he could put it to work cracking >n MD5 hashes per hour for >n dollars?

If the answer is "my hashes protect something that is particularly valuable," then the attacker probably isn't going to hack your hash function, he's going to hack your secretary or your garbage disposal or something like that which is more effective.

Of course, in practice you should just use bcrypt anyway.

Re: Md5crypt is no longer strong enough

#89

Post by edoloughlin »

michaelmior wrote: post #39
darklajid wrote: post #29

Earlier quoted context omitted.

How many web login forms (as an example) are doing client side hashing? The only ones I know are of the recent 'test your password in the linkedin leak' variety. How do you degrade for NoScript users? And where's the harm in that anyway (assuming TLS)?

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 your db or with some other scheme for algorithmically picking a salt based on the user id?

Post reply on HN