9 ms·
>All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm for their site He probably means to use some
by gibybo 14y ago
>All major internet sites, anybody with more than 50.000 passwords, should design or configure a unique algorithm for their site
He probably means to use some combination of well known/tested algorithms rather than inventing your own crypto, but I think his wording is ambiguous enough to be dangerous. While there is some benefit to using a unique algorithm for your site, it's almost certainly more risky than using a secure algorithm (i.e. bcrypt/scrypt/etc) even if every other site was using it too.
- mistercow 14y agoAlso, 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.
- deleted 14y ago[deleted]
- 16s 14y agoOne, often over-looked reason, that website designers chose simple MD5 or SHA1 hashing (and why many still do) is for portability. Years ago this was more of an issue than it is today. They may wish to change web frameworks, programming languages, service providers, etc. and when doing so they want a simple, easy way to use the hashes they have. Also, many big service providers still use MD5 or SHA1. I saw a company migrate to Google Mail from an old legacy mail system and part of that was integrating some authentication services too. This was several years ago, but at that time, Google accepted hashes in two formats only... MD5 or SHA1.
- mike-cardwell 14y agoIt's pretty easy to migrate users from one hashing algorithm to another when they next log in: if( user has an old style hash ){ if( password verifies against old style hash ){ add a new style hash delete the old style hash log them in } } else { if( password verifies against new style hash ){ log them in } }
- ars 14y agoBut if you have code to run the old style hash you don't need the new one. (Although it's useful to upgrade the work factor.) The issue is you don't always have the ability to do the old style, that's why people prefer a hash that they can be assured will be found everywhere.
- deleted 14y ago[deleted]
- udp 14y agoYou mean you're sending unhashed passwords from the client?
- mike-cardwell 14y agoYes. That is the standard behaviour that nearly all sites use, and is perfectly fine.
- adambyrtek 14y agoIsn'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?
- tedunangst 14y agoThe point is that computers are really fast now. There's no need to precompute anything, just crack hashes on the fly. The extra mangling slows things down.
- EricDeb 14y agoIf an attacker gets access to a database of user names/hashes, a salt prevents him from simply checking the hashes against a precomputed list because each hash is totally unique. The attacker would have to recompute all hashes for each user using their individual salt. At least that's what I remember from Computer Security ha
- astrodust 14y agoSalting 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.
- adambyrtek 14y agoLooks 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.