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

131–140 of 144 posts

Re: Md5crypt is no longer strong enough

#131

Post by marshray »

jnorthrop wrote: post #76
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…

That reminds me of the sage advice Bruce Schneier wrote in Secret and Lies, "Anyone who creates his or her own cryptographic primitive is either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't very good."

He's saying to build a custom function out of well established cryptographic primitives.

I don't think that's a good idea either. There's still a ton that can go wrong that won't be apparent at all to someone who knows how to analyze entropy flows through the internals of hash functions. There's a reason why we have a PBKDF2 that's favored over the original PBKDF.

Re: Md5crypt is no longer strong enough

#132

Post by marshray »

EthanHeilman wrote: post #109
dchest wrote: post #104

Earlier quoted context omitted.

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

No, it can be worse.

If 'key' must be kept secret in order to achieve its stated security properties now the system is much more unwieldy for the defender. He now has a key distribution problem that he didn't have before. If the defender can reliably solve the key distribution problem then the attacker wouldn't have gotten a copy of the password key database.

On the other hand, if 'key' is public, then the incremental computational cost added with AES raises the cost for the defender, but not the attacker. The attacker can just un-AES a password hash once and remember the result whereas the defender must perform the AES on every password validation.

Re: Md5crypt is no longer strong enough

#133

Post by drewcrawford »

dchest wrote: post #25
konstruktor wrote: post #23

Earlier quoted context omitted.

There is no mention in the article of secret algorithms.

"Unique algorithm ... in order to make development of highly optimized password brute-force technologies a "per-site" exercise for attackers" for KDF/password hashing is similar in principle to secret algorithm for ciphers: consider that the attacker already has an optimized brute-force technology for your combination of primitives (for ciphers: consider that the attacker knows your algorithm); replace this unique al…

I think a clearer way to express the author's position is to consider the case where a feasible attack is discovered on (say) SHA1. If you consider the probability of an attack on SHA1 and blowfish to be of independent probability, then the author's scheme allows you to "hedge your bets", as in theory your algorithm is as strong as its strongest component, even if the strengths of its components change in the future due to new discoveries.

This line of reasoning assumes A) that the probabilities of attacks on the algorithms are independent, and B) that the algorithms in use do not substantially reduce their input entropy, both of which are potential attacks.

It does _NOT_, however, assume that the scheme be kept secret.

Re: Md5crypt is no longer strong enough

#134

Post by EthanHeilman »

marshray wrote: post #132
EthanHeilman wrote: post #109

Earlier quoted context omitted.

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

No, it can be worse. If 'key' must be kept secret in order to achieve its stated security properties now the system is much more unwieldy for the defender. He now has a key distribution problem that he didn't have before. If the defender can reliably solve the key distribution problem then the attacker wouldn't have gotten a copy of the password key database. On the other hand, if 'key' is public, then the incrementa…

Consider the possibilities: (1) if the key is captured by the attacker the system is just as strong as SHA256, (2) If the key is not captured by the attacker then the system is as unbreakable as AES.

Many of the attacks that lead to password hash exposure involve a SQL injection that dumps the password table. If you store the password in the source code an attacker must then capture both the source code and the hashes. Furthermore, if they leak your key, you learn that they have gained access to your source code.

I agree that this is a less than ideal system. My point was not to design a better system, but to point out that composing permutations with a secure hash function is at least as strong as that secure hash function. If you disagree consider the identity permutation. Really you'd want to implement it like SHA256(AES(key,SHA256(password|salt)).

If I wanted to design a better system this is what I would do. Put the hashing system on a dedicated box that maps passwords to hashes. To compromise the hash key an attacker must compromise your hashing box and your database. Locking-down a box that performs only one action, hashing, is significantly easier than locking down a complex web application.

Re: Md5crypt is no longer strong enough

#135

Post by udp »

Stefan_H wrote: post #106
Tyr42 wrote: post #74

Earlier quoted context omitted.

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.

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

How so? Surely the client would know their username too?

Re: Md5crypt is no longer strong enough

#136

Post by darkarmani »

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.

Ok, sorry for the harsh response, but i don't think that anyone is using it for "common purposes." Everyone should be using strong crypto, because it is inexpensive to do right.

I would argue that almost everyone that is storing passwords should start worrying about people bring racks of GPUs to bear against you, because it is so cheap. At 33.1 Billion MD5 hashes/s with 4 dual-linked GPUs (one machine), you can eat through all 8-digit alphanumerics very quickly for a few thousand dollars. (of course that is using PBKDF1 or less). I had done the calculations in a spreadsheet and forget how long it would take, but it is way shorter than you'd thik.

Re: Md5crypt is no longer strong enough

#137

Post by marshray »

EthanHeilman wrote: post #134
marshray wrote: post #132

Earlier quoted context omitted.

No, it can be worse. If 'key' must be kept secret in order to achieve its stated security properties now the system is much more unwieldy for the defender. He now has a key distribution problem that he didn't have before. If the defender can reliably solve the key distribution problem then the attacker wouldn't have gotten a copy of the password key database. On the other hand, if 'key' is public, then the incrementa…

Consider the possibilities: (1) if the key is captured by the attacker the system is just as strong as SHA256, (2) If the key is not captured by the attacker then the system is as unbreakable as AES. Many of the attacks that lead to password hash exposure involve a SQL injection that dumps the password table. If you store the password in the source code an attacker must then capture both the source code and the hashe…

> (1) if the key is captured by the attacker the system is just as strong as SHA256

This is the part that I think is subtly invalid. Coincidentally, I was having this mailing list discussion the other day: http://lists.randombit.net/pipermail/cryptography/2012-May/0...

It has to do with the fact that the defender is obligated to pay the cost of the AES every time (because he follows the rules of the algorithm by definition). But the attacker is free to bend the rules however he can and one thing he can do is perform the AES once on the entire data file, a negligible amount of computation.

So even though AES is an identity transformation, it makes the function more costly for the defender than for the attacker. Wncrypting one's database may be an acceptable tradeoff for other reasons, but when we're considering the work factor for cracking passwords this is worse.

Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.

Re: Md5crypt is no longer strong enough

#138

Post by marshray »

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.

Right. If someone is able to infect the browser with malware, MitM your HTTPS connection, or even just load mixed HTTP/HTTPS content, then they are able to run Javascript in the login page. If they are able to run Javascript in the login page, then they are able to monitor the keystrokes as it is typed in.

This is not theoretical. This is what Tunisia did to Facebook and it's what online banking trojans (e.g. Zeus) do every day.

Re: Md5crypt is no longer strong enough

#139

Post by adambyrtek »

astrodust wrote: post #127
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?

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.

Looks like it wasn't clear that my question was rhetorical. My point was that some secret mangling on top of a standard hashing algorithm doesn't offer more protection than salting.

Re: Md5crypt is no longer strong enough

#140

Post by EthanHeilman »

marshray wrote: post #137
EthanHeilman wrote: post #134

Earlier quoted context omitted.

Consider the possibilities: (1) if the key is captured by the attacker the system is just as strong as SHA256, (2) If the key is not captured by the attacker then the system is as unbreakable as AES. Many of the attacks that lead to password hash exposure involve a SQL injection that dumps the password table. If you store the password in the source code an attacker must then capture both the source code and the hashe…

> (1) if the key is captured by the attacker the system is just as strong as SHA256 This is the part that I think is subtly invalid. Coincidentally, I was having this mailing list discussion the other day: http://lists.randombit.net/pipermail/cryptography/2012-May/0... It has to do with the fact that the defender is obligated to pay the cost of the AES every time (because he follows the rules of the algorithm by defi…

>Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.

I agree, and I don't think AES (or any easily invertible function) should be used to increase the work factor.

We have been arguing past each other. I was responding to a post that said ~'if you compose two functions and the second function is insecure, than the composition is insecure'. While such a statement is correct for compression/hash functions, it does not hold for permutations.

Do you agree that keys or peppers decrease the risk of passwords being revealed if the key or pepper can remain secret from the attacker? Assuming that keeping a key secret is much easier than keeping a bunch of hashes secret, which is a fair assumption, shouldn't such a method increase the security of the system?

Post reply on HN