10 ms·
Md5crypt is no longer strong enough
- 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.
- 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.
- phkamp 14y agoYes, of course. I have clarified the text now on this point.
- hodgesmr 14y agoUm. Haven't we known not to use MD5 for years now?
- phkamp 14y agoMD5 is not vulnerable as used in md5crypt.
- KhalidAbuhakmeh 14y agoIt's very telling that hardware is outpacing our own cryptographic techniques. I remember reading an article that stated that all passwords will someday be crackable due the advances in Quantum computing. By that time we'll all know that your password is "I Love Care Bears 123" :P
- cheald 14y agoHardware is not outpacing our cryptographic techniques. Go spin up an AWS GPU cluster to break an AES-256-encrypted file and let me know what the bill runs you. md5crypt is a "poor man's" crypto system, simply because it's built on MD5, which is intended to verify data integrity more than it is designed to hide information. We've known that md5 was broken since 2004, so at this point, anyone actually using MD5-based systems for password hiding really has no excuse. Quantum computing is a whole 'nother ballgame, and while it does offer the promise of making current encryption schemes more or less obsolete, it's an entirely different ballgame than "chain together a few Radeon cards and crack a DB full of MD5 hashes".
- reitzensteinm 14y agoThat this is upvoted to #1, in 2012, on a site called Hacker News, is probably more notable than the article itself.
- phkamp 14y agoI reinforces my belief in humanity that it did happen, I have been pondering for a long time how to do a "People of Earth, your attention please..." which would reach the necessary audience.
- 16s 14y agoInertia. The fact that it works and has been tested extensively in production means more to many managers than security does. (pause for collective gasp from the nerds) Until it becomes a crime of some sort to use these simple, well-tested hashes to store passwords and the world police begin locking-up CIOs because of it, then don't expect anything to change.
- reitzensteinm 14y agoYou're responding to an argument I never made. I'm not surprised MD5 is used in the wild, nor confused about the reasons why. And hell, it's a step up from plain text, which is probably even more common. I'm just surprised to read about its deficiencies on Hacker News as if it were news.
- koide 14y agoExcellent idea, a hash scheme per site. A multi language framework to help you build your own scheme, one which can be validated by many cryptography-knowledgeable eyes, would improve the chances of this actually happening some day. It's a pity that seemingly trivial changes on an crypto algorithm can totally obliterate its security.
- ars 14y agoBTW COTS means Commercial off-the-shelf. (I've always known that abbreviation as just OTS, and was trying to figure out if the C stood for "Custom".)
- acheron 14y agoI've never seen just OTS, but then I work in an area where it is necessary to distinguish COTS from GOTS ("government..."). If you have no reason to encounter government software, then I suppose there's no reason to specify that you mean commercial.
- JonnieCache 14y agoI read it as Cheap Off The Shelf.
- olifante 14y agoI usually parse it as common-off-the-shelf
- dchest 14y agoAh, the good old "secret algorithm" thing. If you really want a "custom algorithm", the better advice would be to use a known algorithm with a secret key. For example, https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#... Why? See http://en.wikipedia.org/wiki/Kerckhoffs_principle http://en.wikipedia.org/wiki/Kerckhoffs_principle In most case, you don't need this, though. Can you prove that your construction is secure? How many hashing algorithms are there? Remember that big O thing. Just increasing the workfactor for scrypt will be much better than using a combination of 5 or so hash functions.
- konstruktor 14y agoThere is no mention in the article of secret algorithms.
- dchest 14y ago"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 algorithm with the work factor/secret key to have fewer moving parts.
- drewcrawford 14y agoI 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.
- al_james 14y agoHere's a (potentially stupid) idea: The app provides a fixed 'secret key' that defines (somehow) a sequence of hashing and scrambling functions to apply to the password. So, for example, the secret key "df8dfuhuejew3" (or whatever) might be interpreted as '3 iterations of md5 hash followed by rotate hash 5 places to the left followed by 2 iterations of bcypt etc..'. So, in effect, each app (with a different secret key) will have a different hashing process, but with the advantages that its repeatable and cross platform (reference implementations could be available in the major languages). Of course, if your secret key is hacked you are in trouble, but at that point the hacker can probably get your source code for whatever hash system you use, and anyway, the combined hashing process is probably slow enough to prevent brute force attack. Any thoughts? Edit: Probably better to just use bcrypt with a larger work factor.
- cheald 14y agoWhy is this any more secure than keeping a salt in your code? bcrypt(password + hardcoded application salt + db-stored user salt) is far less complex and arguably just as secure, since your argument is predicated on "assume the source code is safe". bcrypt is tunable to be as slow as you want, even to account for hardware progress.
- al_james 14y ago>bcrypt is tunable to be as slow as you want, even to account for hardware progress. I did not know that. Can you expand on this point?
- cheald 14y agoPart of the bcrypt process includes a "work factor", which is, crudely, "how many times do I run this?" What you can do is tune your work factor so that it takes a reasonably long time to hash a password (say, 0.05 sec on your webserver = 20 passwords/sec), which won't necessarily heavily impact the performance of your website, but which would be a significant impediment to anyone trying to brute-force those passwords. As hardware improves, you just implement a system wherein when the user submits login information, you verify their password with your old work factor, and if it passes, re-hash with your new (slower) work factor and store the updated hash. This allows you to effectively use a progressively slower algorithm over the lifetime of your application to compensate for Moore's Law. You obviously don't want to pick a work factor that's too high for your web server hardware, since that opens you up to DOS attacks, but a reasonable work factor can easily mitigate the weaknesses of MD5 and SHA1 - notably, that they can be computed by the hundreds of millions of second on the right harware.
- ddlatham 14y agoPlease 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 out the details of the scheme before using brute force (category 1). However, many cryptographic compromises are actually due to bugs or weaknesses in the implementation (category 2); i.e. on paper your custom combination of schemes is fine, but you made a bug in implementing it or forgot to handle some case correctly. How can you have confidence that your scheme is safe from category 2 attacks? Use a scheme that has already been widely reviewed and attacked. If no one has been able to find a vulnerability in it thus far, there's a good chance that your attacker won't either. So there _is_ an advantage to using the same scheme that many others use. Use something hard, like scrypt, bcrypt, or PBKDF2, but also find an implementation of it that is likely to have been well used, reviewed, and hopefully attacked.
- ovi256 14y agoI 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-by, mass-trolling attacks uneconomical, as they're based on pointing an exploit tool at a list of adresses. It will not deter targeted attacks (spearfishing) by competent attackers, but again, not much would.
- IsTom 14y agoSuch combinations could end up worse sometimes, just like 2DES has the same strength as DES.
- chc 14y agoThe idea that my customizations would make it appreciably more secure (especially vs. just slightly increasing the work factor) seems questionable to me. On the other hand, it's very plausible that my customizations could accidentally make it less secure. Way smarter folks than me have messed up algorithms they actually put a lot of thought into — I'm not going to go blithely turning knobs in good algorithms and hope their positions weren't important. Incidentally, what kind of drive-by attack are you thinking? Like, you have your password database sitting out in the open and there are bots crawling the web trying mechanically to crack it? Because that doesn't sound like a common case, but I'm not sure what else you could mean.
- yashchandra 14y agoIn my very first internship/job, I implemented user management in ASP and Access database in backend. I chose MD5 for password hashing and I was so proud of myself. Of course this was about 10 years ago. :)
- al_james 14y agoJust found this if any PHP developers wants an easy to use bcrypt password library. https://gist.github.com/1053158 https://gist.github.com/1053158
- deleted 14y ago[deleted]
- jonaphin 14y agoNot exactly an expert on cryptography, but how different is the description of the "next" crypto-algorithm provided by Kemp different from what bcrypt can do today?
- stcredzero 14y agoFor server-side, how about password DB implemented as hardened information appliances? This would make the acquisition of the password database harder. White-box techniques could be used to hide a modified salting technique, making cracking much more labor intensive. Such a service could be offered by cloud and virtual server providers, perhaps for a small additional fee. (Which would still be almost all profit.)
- phkamp 14y agoI've been offline for some hours, and just wish to add a few concluding thoughts here: No, I'm obviously not proposing that people do something stupid with crypto, we've had enough of that in recent days already. But I am trying to provoke one or more card-carrying cryptographers to realize, that while password protection may be a problem we have good and strong theoretical solution for, those solutions will not protect any passwords until somebody turn them into Open Source code we can use. I only wrote md5crypt because nobody else had done so, and nobody else wanted to do so at the time, and FreeBSD needed an ITAR exportable password scrambler. If more cryptographers wrote more code under liberal Open Source licenses, instead of bitchy complaints against the people who do write code, then the world might gradually become a better place I have been dreading this announcement for a couple of years, knowing full well that the majority of the world can't tell MD5 from md5crypt. It is a credit to hackernews that you could, much appreciated.
- 5549900 14y agoThe way forward for nontechnical users seems clear: avoid giving websites sensitive information and letting them store it for you. How long before Facebook is hacked? Keep sensitive information on your own storage media, not on some website's servers connected to the internet.
- snow_mac 14y agoHow about this for security MD5(SaltFromDB + Password + ApplicationConstantSalt)? How would that be affected by something like this? Given the user you'd their salt, their paassword but not the application salt. Still really insecure?