Hacker News Reader

Comment by mistercow | Hacker News Reader

Also, if that's what should be encouraged, someone might as well put together a simple framework for automating it. Basically, you hard code a list of salts and a list of hash function names (which could also be automatically generated by a tool), and it gives you a new hash function which is the composition of those other functions. There's no reason for everyone to try to do it by hand and risk messing it up in some simple way. And if there were an easy to use framework for doing it, there would be no reason for only larger sites to use it. Using a custom hash function could simply be a best practice.

But honestly, I'd be pretty happy if we could get all sites with 50,000+ users to salt and hash their passwords with any algorithm.

View on HN

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 effect does that have on the entropy of the system and so on? Would it make it easier to crack, or harder?

There is no per se answer to that question. Cryptanalysis is hard, you can't assume things like commutativity and orthogonality.

This whole line of thought is at best a waste of time, and at worst dangerous.

PBKDF2-HMAC-SHA-256 is a vetted NIST approved standard with an adjustable work factor. It has been subject to professional attention for many years.

BCrypt, while not subject to nearly as much analysis nor approved by NIST, was designed by very competent cryptographers, has an adjustable work factor and is based on blowfish -- which has been subject to substantial professional attention.

Use one of the above with the highest work factor you have the processing power for and call it a day. Don't try to roll your solution.

I tend to agree, which is why my whole comment was conditional on "if it's a good idea for everyone to use custom hash functions". Basically, if we're going to have custom hash functions, we want to reduce the "roll your own" aspect of that to a minimum.

I hope nobody thought I was suggesting they actually do that. It was purely a matter of personal curiosity. Entropy is perhaps the most interesting thing in the universe.

I'm far too lazy to do anything other than slap bcrypt on it, unless there's a pressing need to do something else, which there never is.

(Not an expert) The entropy doesn't change. What you get by adding another hash function is a slightly larger die area (and thus the cost) required for brute force attacks. By using scrypt instead of PBKDF2, you can adjust the die area required for attacks in a more flexible and safe way by just giving it a different parameter.

Hash functions have different requirements than key stretching functions, but if you're interested in the security of combining cryptographic hashes, Google for "combining hash functions" and "chaining hash functions" -- there's a lot of interesting research.

>The entropy doesn't change

Yeah, that now seems obvious. The input string is the same, so the information entropy is the same. I'm struggling to think of the concept that I need here, I want to say kolmogorov complexity but I know that's wrong too.

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

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.

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.

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.

Such a toolkit would probably be a good idea.

Tie a card-carrying cryptographer to a chair until he delivers it ?

>Tie a card-carrying cryptographer to a chair until he delivers it ?

Alternatively, implement it very, very simply and put it on github, and ask card-carrying cryptographers to vet it. That one is harder on the ego though.

I'm pretty sure no cryptographer will vet it.

I read 'vet' as "tear it to bits"

Yes, exactly. After several phoenix iterations of that kind, you might have something approaching usable.

Reply on news.ycombinator.com