5 ms·
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
by mistercow 14y ago
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.
- JonnieCache 14y agoThe 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?
- bradleyjg 14y agoThere 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.
- mistercow 14y agoI 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.
- JonnieCache 14y agoI 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.
- dchest 14y ago(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.
- JonnieCache 14y ago>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.
- darkarmani 14y ago> 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.
- JonnieCache 14y agoYes, 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.
- dchest 14y agoYou 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.
- JonnieCache 14y agoYes, 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.
- dchest 14y agoI 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?
- JonnieCache 14y ago
- phkamp 14y agoSuch a toolkit would probably be a good idea. Tie a card-carrying cryptographer to a chair until he delivers it ?
- mistercow 14y ago>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.
- dchest 14y agoI'm pretty sure no cryptographer will vet it.
- GoodIntentions 14y agoI read 'vet' as "tear it to bits"
- deleted 14y ago[deleted]
- mistercow 14y agoYes, exactly. After several phoenix iterations of that kind, you might have something approaching usable.