11 ms·
Don't use bcrypt
- jgrahamc 15y agoHowever, if you're looking for a key derivation function for a new project, bcrypt is probably not the best one you can pick. I'm confused. Why would I pick bcrypt as a key derivation function when there are nice key derivation functions out there that are widely documented?
- lhnn 15y agoAs stated in the article, a popular stance on Hacker News and Stack Overflow is "USE BCRYPT". It's chanted to crypto-noobs and webdevs as a simple-to-use library for password storage that is more secure than MD5/SHA/Whatever hashing, and with built-in salts. The whole point of this article is to say that, in fact, there are other options.
- deleted 15y ago[deleted]
- cperciva 15y agoWith a few very rare exceptions, those use cases are equivalent. EDIT: The context was comparing 1. converting passwords into keys for cryptographic purposes and 2. hashing passwords to be used for logins.
- tptacek 15y agoBullshit. There is one very-well-written article at Coda Hale's site that says "just use bcrypt", but in discussions of adaptive hashing on HN, people who know what they're talking about are continuously at pains to vouch for PBKDF2 and scrypt (it helps that one of the people who knows what they're talking about on this subject is (a) vocal on HN and (b) designed scrypt). It irritates me that despite going through the effort of vouching for PBKDF2 and scrypt every time this f'ing topic comes up on HN, people still manage to reduce this issue to another tribal conflict. And who are these "crypto noobs" you speak of?
- funkah 15y agoRaises hand It's important to know what you don't know. And I know enough about crypto to know that I don't know anything and should listen to people who do.
- lhnn 15y agoI'm one of those crypto-noobs. I'm getting better and studying, and obviously hanging out on Stack Exchange. I didn't make it a tribal conflict. If anything, the article did... I was summarizing. I must have missed the part where scrypt was mentioned here, but I have seen it called out on SE.
- there 15y agoThe whole point of this article is to say that, in fact, there are other options. Then maybe it shouldn't have such an inflammatory title as "Don't use bcrypt". "Alternatives to bcrypt", perhaps.
- lhnn 15y agoI agree with you there. I only let it pass my personal bullshit-ometer because it's a rebuttal to a popular article titled "use bcrypt".
- DanBC 15y agoI like this article. But this sentence is odd. > […] with an academic pedigree from RSA Labs, you know, the guys who invented much of the cryptographic ecosystem we use today. Appeal to authority fails a little bit when RSA opens random Excel attachments from unknown untrusted sources - attached to an email that have to be retrieved from the junk mail folder. (http://blogs.rsa.com/rivner/anatomy-of-an-attack/ http://blogs.rsa.com/rivner/anatomy-of-an-attack/) EDIT: As other commentators point out, I am wrong to suggest that anything coming from RSA Labs is somehow "weak" because someone at RSA fell for a phishing attack. I do find it odd that a security article suggests "These people are good; they did 'this thing' which everyone uses". That's not a great way to approach choosing crypto components. Even experts make mistakes.
- SoftwareMaven 15y agoAs does ad hominem... Edit: realized I should probably explain. What an administrative assistant does in a social engineering attach has nothing to do with the quality of cryptographic research at RSA. Humans are ALWAYS the weak point in cryptography.
- yock 15y agoNo, ad hominem is "You're wrong 'cause you're a jerk." DanBC pointed out that their opinion might not be as above reproach as is often assumed because of past lapses in good judgment.
- SoftwareMaven 15y agoAd hominem is an attempt to negate the truth of a claim by pointing out a negative characteristic or belief of the person supporting it.[1] That sounds pretty much like what happened above. The truth item is whether RSA's cipher chops can be respected. The negative characteristic is an HR person succumbing to a social engineering attack. Ad hominem isn't just calling names. Let me put it differently: in what way does the HR rep's mistake reduce the quality of ciphers that have come from RSA? 1. http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
- lhnn 15y agotl;dr PBKDF2 and scrypt each have supposed upsides to bcrypt and all the benefits. PBKDF2: RSA tested and widely used. scrypt: memory hard as well.
- tptacek 15y ago"Memory hard" is a serious benefit that scrypt actually has. "RSA tested and widely used" is subjective, not particularly meaningful, and in some senses erroneous, and so makes a poor case for PBKDF2. If people want to seriously push for scrypt as a replacement for bcrypt as the "default" function, I'll design and print flags and pennants for the movement. But when people say "use PBKDF2 instead of bcrypt", I think the net effect is to scare people back to salted hashes, and my general response is going to be to poke holes in their arguments.
- dhimes 15y agoQuestion: what does "memory hard" mean? Uses lots of RAM to preclude simultaneous connections running attempts in parallel?
- m0nastic 15y agoCorrect. I just spent the past two days sitting in a workshop on "Special-Purpose Hardware for Attacking Cryptographic Systems" and the most repeating thread from all of the talks was how to deal with the unique memory limitations of GPU's and FPGA's when using them to attack crypto. Bandwidth is the largest one, and specifically the tiny amount of shared memory available to the GPU. Basically, if you're forced to use "local memory" (which has a huge cost in transaction time), the amount of operations per cycle you can perform goes way down, which in some cases can be the difference between an attack taking "2 years" and "until the heat death of the universe".
- marshray 15y agoJust to add to that a little: when comparing these functions it's not so relevant the absolute time consumed; all of them can be tuned to take whatever amount of time is acceptable on the defender's general purpose hardware. The key factor is minimizing the relative advantage that an attacker with focused resources (such as dedicated hardware) is able to gain over the defender.
- user2459 15y agoLong story short, if a bcrypt exploit is found, you'll be sorry. So use http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2 or http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html instead. They're apparently better tested. I'm no expert opinion, but seems a bit unnecessary and that bcrypt is still a perfectly good choice for most password stores.
- deleted 15y ago[deleted]
- deleted 15y ago[deleted]
- cperciva 15y ago> While scrypt's cryptographic soundness, like bcrypt's, is poorly researched I think we may have different notions of what "poorly researched" means.
- zheng 15y agoI think he meant it hasn't undergone the same level of public scrutiny. You've certainly spent ample time researching it, and it's obviously been tested, but possibly not as much something like AES.
- dchest 15y agoNote that scrypt uses PBKDF2 before and after the memory-hard function.
- cperciva 15y agoOnly as a cryptographic mixing/expansion function. There is no reason to think that scrypt's security would be any less if the PBKDF2 calls were replaced with xor.
- dchest 15y agoDoesn't it provide more protection against possible flaws in Salsa? Also, somewhat related question -- what if Salsa core in scrypt is replaced with BLAKE core (with fewer rounds than in hash), and SHA-2 in PBKDF2 with BLAKE, thus making it possibly smaller (hardware and lines of code). Will this work well?
- cperciva 15y agoDoesn't it provide more protection against possible flaws in Salsa? In a very theoretical sense, yes. But Salsa would need to be very very broken in order for that to matter (hence the "no reason to think" comment). what if Salsa core in scrypt is replaced with BLAKE core (with fewer rounds than in hash), and SHA-2 in PBKDF2 with BLAKE, thus making it possibly smaller (hardware and lines of code). Will this work well? Probably. I proved the security under the random oracle model, but the property I actually need is approximately "can't be iterated fast", which is a far weaker requirement.
- dchest 15y agoThank you for your answers.
- SkyMarshal 15y agoTLDR: Use PBKDF2 or scrypt instead. PBKDF2 has had longer public exposure, and also features an adjustable CPU work factor (though with a lower theoretical safety-to-compute-time than bcrypt). scrypt is newer, but features both a CPU and memory work factor (memory-hard algorithm), and is algorithmically superior to both.
- _delirium 15y ago> PBKDF2 has had longer public exposure I don't know whether or not it's had more public exposure, but I don't think it's had longer public exposure. Afaik, bcrypt's canonical reference document is the June 1999 Usenix paper (http://static.usenix.org/event/usenix99/provos/provos_html/index.html http://static.usenix.org/event/usenix99/provos/provos_html/i...), while PBKDF2's is the September 2000 RFC (http://www.ietf.org/rfc/rfc2898.txt http://www.ietf.org/rfc/rfc2898.txt).
- SkyMarshal 15y agoThanks for the reference, didn't realize that, though I think that's what the article was implying.
- ceol 15y agoSo the author says to use PBKDF2 because it's researched and tested better than bcrypt, and then suggests scrypt as another alternative despite having, from what I can tell, less research done on it than bcrypt. The crypto space can be intimidating to your average dev, but almost every app needs some sort of protection (at least for user information). I think the author is fair in wanting to push for the "default" to be PBKDF2 instead of bcrypt, but should he really be advocating a less-tested function in the same article?
- tptacek 15y agoIs there a reason other than branding that you think it's fair to push for PBKDF2 to be the "default" instead of bcrypt?
- pbsd 15y agoTo be honest, I don't see why anyone would use bcrypt over PBKDF2, if the security of the primitives is of any serious concern. I am new here on HN, so I'm not aware of your arguments on why bcrypt is better than PBKDF2. As for the "branding" question, would you recommend XTEA or MARS or Threefish over AES for someone in need of a block cipher? Of course not. Standards are not always perfect (and many a flaw has been found in standards), but they are generally beneficial. PBKDF2 also has the advantage of being modular. It takes in an arbitrary PRF (although HMAC-SHA1 is the usual); maybe HMAC-SHA1 turns out to be poor for the job, just plugin a better PRF (hell, you can plugin a provable PRF that reduces to integer factorization or the elliptic curve discrete log). bcrypt is just bcrypt --- a seemingly not too peer-reviewed modification of an ancient cipher, that is not even recommended anymore. scrypt is better than both, of course. Provable time-memory hardness is great, and should be made standard.
- tptacek 15y agoIt takes an arbitrary PRF that is in practice virtually always SHA2, and practically always a well-known cryptographic hash function. If you're going to bank on a cryptographic primitive and you have a choice between "cipher" and "hash function", you pick "cipher". Also, for lay developers, choosing a crypto construct for its modularity is like choosing a smoke detector because it allows you to use different radiological bits in it. You're not supposed to be messing with those bits. The whole point of the package is not to have random developers changing them. Also, I want you to note something: You pick AES not because it's a standard but because it's the product of a contest in which many of the world's best cryptographers competed to design the replacement to DES. That's not what PKCS standards are. A PKCS standard is simply something that survived a standards group discussion.
- tptacek 15y agoPBKDF2 is worse than bcrypt. scrypt is better than bcrypt. bcrypt has the advantage of being both very good, and also broadly available on web platforms. scrypt does not yet have that advantage; when it does, I will start saying "just use scrypt". But the simple fact is: all three of these functions are fine. ANY of them is a huge step forward from what people do without them. "Just use bcrypt" is 1000x more effective as a meme than "just use adaptive hashing" (which is what all these constructions are). So, while I have few specific technical qualms with this article (e.g. why do I care whether something is a PKCS standard or not?), the overall message is a bit hyperbolic.
- cperciva 15y agoPBKDF2 is worse than bcrypt. By roughly a factor of 5. scrypt is better than bcrypt. By roughly a factor of 4000. why do I care whether something is a PKCS standard or not? You don't care, and I don't care, but I'm sure you know lots of companies which do care (especially since PBKDF2 is a NIST standard too).
- tptacek 15y agoFor what it's worth: when dealing with banks and financial firms, where any technology without an adequately staid and reassuring web presence is frowned upon, we happily recommend PBKDF2. There's nothing "wrong" with PBKDF2. It's just not as good as bcrypt.
- regularfry 15y agoWhen we were looking at password hashing, and the choice came down to bcrypt or scrypt (about a year ago, so recently enough), I said we should go for bcrypt because scrypt was comparatively new; inasmuch as it makes a difference, it's just had less time to be attacked. Was I wrong?
- zobzu 15y agoits a sane decision. just make sure you implement properly. like everything crypto, it will be broken, eventually. but its a safer choice than a new algoritm. it reminds me of the vulnerability issues. when apps have no known vulnerabilities, all is fine. when a new "instant root compromise of any system" comes out, its omgomgomg. Then its fixed, and all is fine again. Except that vulnerability was always there. And other ones that are yet to be public are there too. And many of them are "omgomgomg" material. Well crypto is the same. We don't have public data on which algorithm are broken. We just know they will be eventually, by logic or by brute force. So, take the wise decisions, and don't forget you might eventually need to update it.
- tedunangst 15y ago"that won't help you if an attack is discovered which mitigates bcrypt's computational complexity." AND you lose control of your database. Even if I had a magic instant bcrypt reverser, it does me no good if I don't have the hashes. You cannot be compromised by a bcrypt mistake, it would only make your already existing compromise slightly worse.
- tptacek 15y agoAnd of course that's a nonsensical argument in favor of bcrypt, as it applies identically to PBKDF2 and scrypt. You could use a similar argument to recommend Elliptic Curve over RSA, or RSA over Elliptic Curve.
- tedunangst 15y agoIt's not an argument in favor of bcrypt. It's a rebuttal to an argument against bcrypt. I have seen several people, whenever this comes up, make the mistake of thinking that your whole app could somehow be compromised by the wrong choice of password hash.
- tptacek 15y agoI agree that this is a second-tier security issue, as well. I only got religion about it after reading 100 threads from people bragging about how they'd designed their custom password hashes with Whirlpool and AES-256; in other words, as a nerd tic.
- deleted 15y ago[deleted]
- tptacek 15y agoWhy, exactly, do you think PBKDF2 is a more sensible default than bcrypt? (If scrypt was trivially installable from a gem for Ruby, easy_install for Python, CPAN for Perl, a jar for Java and a .NET assembly for Microsoft, and all those bits came from sources where I didn't have to manually audit them and make personal attestations for their quality when I recommended them to clients, I would immediately stop recommending bcrypt).
- Cushman 15y agoWow, you jumped right on that :) I deleted the comment immediately after posting it because I wasn't really sure I could support that statement. As someone who doesn't know a lot about security algorims, I'm susceptible to the idea posed in the article that the better-proven algorithm is a safer bet; but on second thought, it seemed a little paranoid, since I haven't seen any positive reason to doubt bcrypt's security. And given that PBKDF2 is an uglier thing to try to recommend, and "just use something" is the most important message, I think the current atmosphere around bcrypt is probably fine.
- grandalf 15y agoHow is being from RSA labs an advantage? I'd estimate that it's more likely that there are government backdoors in RSA crypto than in other variants.
- tptacek 15y agoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA IT BURNS IT BURNS
- marshray 15y agoFor one, it's something the government uses for its own crypto. Unlike some crypto standards, PBKDF2 is just something too simple and too user-configurable to be able to hide a meaningful hole in. Given that PBKDF1 was found to be less-than-ideal and depracated in favor of the better PBKDF2, it would be a very risky proposition to attempt to weaken it in a way that gave a meaningful advantage to one party over the other.
- JoachimSchipper 15y agoPBKDF2 is a fairly "obvious" construction (it's mostly just repeated HMAC'ing); it would be really hard to hide anything clever in it.
- noonespecial 15y agoI wouldn't exactly call "just use bcrypt" a cargo cult. It has had real benefits to the web dev community because it factors down to "don't store it in plain text or use MD5 or something". Several people working on small projects have already come to me and asked me "what's this bcrypt thing? should I use it here?" I guarantee these folks would have just stored it plaintext otherwise. So I've directly observed the mantra making stuff safer. Win.
- tptacek 15y agoI strongly agree that when asked by friends what to use, you should think about which library is going to be easier for them to use, and not try to think through which construction is "better". That this blog post gets the real ordering of betterness wrong is tangential to the real problem, which is that it gets the value proposition of bcrypt wrong.
- smacktoward 15y ago> I write this post because I've noticed a sort of "JUST USE BCRYPT" cargo cult... This is absolutely the wrong attitude to have about cryptography. No. This is incorrect. This is exactly the right attitude for most developers to have about cryptography, because on a subject as complex as cryptography most developers (including me!) are nowhere near smart enough to understand the ins and outs. Encouraging people to make their own decisions on subjects they aren't equipped to understand fully is dangerous advice. It leads to all sorts of bad outcomes. People who have to choose between options they don't really understand end up choosing things at random, or on the basis of incomplete or misleading information, or getting seized up by the need to make a choice and choosing nothing at all. This makes cryptography one of the very few cases where a cargo-cult approach is better than the alternatives. A simple message that "this is the approach people smarter than you agree is correct, use it," repeated consistently, will help more people more completely than dumping them into the deep end of the crypto pool ever will.
- pleasebehonest 15y agoThat attitude is abrasively condescending. Why not just say, "people who spent a lot of their time studying cryptography strongly recommend this approach. They feel the approach that you are considering is simply insecure."? Framing things in terms of intelligence isn't going to win anyone over, if that's your goal. And it probably isn't accurate, either.
- tptacek 15y agoSounds pretty close to accurate to me. Do you want to feel good, or do you want to choose good crypto? Pick one or the other.
- dhimes 15y agoHe's probably using "smart" in the sense of "accumulated knowledge in a particular space" instead of in the sense of raw mental horsepower. http://news.ycombinator.com/item?id=3583985 http://news.ycombinator.com/item?id=3583985
- 15y ago
- moxie 15y agoThis article doesn't feel very well done to me. He writes: "The first cipher I'd suggest you consider besides bcrypt is PBKDF2." PBKDF2 is not a cipher. It's a KDF, and it's almost always used with an HMAC or a cryptographic hash rather than a cipher. The thesis of this article seems to be "PBKDF2 is well understood, where bcrypt is not." In fact, the opposite is probably true. bcrypt uses a block cipher (blowfish) to create its underlying compression function. Block ciphers are extremely well understood, have been studied to death for years, and are modeled on extremely well understood constructs. They can be used to create cryptographic hash functions, but usually aren't, because they're slow (which we don't care about in this case). Cryptographic hash functions, by contrast, are not well understood at all. They are "magic" in many ways, and aren't modeled after anything. Many more "bad things" happen in this space than in the block cipher space. The only reason people mess with them at all is because they're faster than block ciphers, which again, we don't care about in this case. The other appeal to PBKDF2 is because it "comes from RSA." This doesn't feel like an extremely compelling argument, but if we were going to believe it, then why not use the PKCS#12 KDF? PBKDF2 was proposed in PKCS#5, and "12" is a larger number than "5", so if we're going to do what RSA tells us we should do, they're essentially saying we shouldn't actually use PBKDF2.
- tptacek 15y agoLadies & Gentlemen, Moxie Marlinspike, whose comment should be heading up this whole thread.
- marshray 15y agoNow I'm as much a fan of Moxie's as anybody, but I think one part of cryptography that needs to change is this tendency to excessively appeal to authority. Especially when speaking about practical issues.
- tptacek 15y agoSo, I agree, but am happy he took the time to comment and (reasonably) concerned that his comment would be buried somewhere in the bottom third of the thread. I'm appealing to high quality comments, not authority.
- justin_vanw 15y agoI guess it's hip to have an opinion, but JUST USE BCRYPT. It's secure and available. Don't spend time thinking about it, just use bcrypt, it does everything you want, move on to something more worth your time. Unless you're some blogger who needs to generate some page views, then pick some obscure topic like how to store password hashes and rake muck.
- baq 15y ago> JUST USE BCRYPT multiple things come to mind: - Millions Of Flies Can't Be Wrong - Citation Needed - JUST USE SCRYPT etc.
- zobzu 15y agoYeah, don't think about stuff. Never think about stuff, in fact! Let us think for you! Or if possible, random self-proclaimed experts! That's the way to go. (and i bet many won't even notice the sarcasm) Freaking hell, do critise, do research, and that apply to everything, not just crypto. It's not rocket science.
- SoftwareMaven 15y agoAs long as we've got some smart people hanging around: where does HKDF[1] fit into this? More specifically, when would you use HKDF over scrypt? 1. http://eprint.iacr.org/2010/264.pdf http://eprint.iacr.org/2010/264.pdf
- tptacek 15y agoThis makes PBKDFs very di fferent than the general-purpose KDFs studied here. In particular, while passwords can be modeled as a source of keying material, this source has too little entropy to meaningfully apply our extractor approach except when modeling the hash function as a random oracle. Also the slowing-down approach of PBKDFs is undesirable for non-password settings
- SoftwareMaven 15y agoBut, as mentioned by @cperciva elsewhere in this thread, generating a key and creating a password hash are nearly synonymous. Using HKDF for passwords would be silly, but the more interesting question is: when would you use scrypt for key derivation in a system? More to the point: what are the tradeoffs you'd consider in choosing one over the other? (Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as its actual key derivation function for file encryption and authentication. Why scrypt instead of something else (and I have faith that it's not "not invented here" syndrome)?
- tptacek 15y agoI'm quoting the actual paper.
- SoftwareMaven 15y agoI am aware. I did read it before I posted it.
- tptacek 15y ago
- jiggy2011 15y agoTo be honest, if anybody breaks into your web application it is very unlikely to be because they broke any encryption. SQL injection or man in the middle type attacks are far far more likely. What you need out of an encryption package is in the event of being tested for PCI compliance or any legal liability investigation into a breach. You need to be able to say "all of our encryption is done with bcrypt , it's the industry standard an complies with X Y and Z".
- m0nastic 15y agoThe debate around secure password storage is sort of orthogonal to initial compromise of a web application. The reason that it's important (although as others here have noted, less important than primary application security concerns) is what areas of attack are opened up by using insecure password storage "after" an initial compromise. This could be something as simple as being a nuisance to users of the system (having to send out those "our password database was compromised, and we didn't do a good job of storing them securely, so you should probably change all of your associated passwords), to something much more serious (using said insecurely stored passwords to attack your other systems for example). PCI doesn't really care how you're encrypting your data at rest. I cracked the password storage from an application once which was literally just a simple substitution cipher (which was positionally dependent...it was for all intents and purposes as secure as a newspaper cryptogram puzzle). That application was PCI compliant. While "what you need out of an encryption package" might just be the bare minimum of "cover your ass", that's no reason to settle for insecure password storage.
- marshray 15y agoIt's also something of a public health issue given how most users re-use some passwords across multiple sites. "Site A" may be less than careful about security since they perceive their data as being of low value (e.g. "register for a chance to win free movie tickets"). But when they get hacked and their users' passwords cracked, it will likely expose plenty of Facebook and online banking credentials.
- 16s 15y agoMicrosoft uses PBKDF2 for newer domain cached credentials (DCC2). These password hashes are stored in the registry of Windows clients (laptops and desktops) and allow users to logon when the domain is unavailable. They use 10240 iterations. It's very compute intensive to crack... roughly 330 guesses per second. Great article BTW! Edit: I only post this to add to the examples of who uses PBKDF2 in addition to what the article lists.
- steveh73 15y agoI'm a web developer, so while security is obviously a huge concern, it's not my main area of expertise. I don't have the knowledge to evaluate the pros and cons of each cipher, and the situations in which it's appropriate to use each one. It would be wonderful if someone with more knowledge of the subject could throw up a 1-page site with an appropriate security choice (or a few choices with situations in which each would be more acceptable) for a given range of situations, to establish a 'sane default', taking into account their availability on a number of platforms and programming languages. For example: Need to sign a message? Use HMAC-SHA1 Need to checksum a file? Use SHA-1 Need to hash a password? Use bcrypt Need to transmit data over a network? Use SSH2 Need to secure HTTP? Use SSL 1.2 with (these ciphers in order of preference) Need to secure home WiFi? Use WPA2-PSK Need to encrypt files? Use GnuPG Need to do (this type) of encryption? Use CBC. For (this type), use ECB Need to create a TrueCrypt volume? Use (this cipher) with (this many) bits.
- chrismsnz 15y agoI guess the question is - who do you trust to make these calls? In this case, the answer probably is OWASP which is a great and often overlooked resource, contributed to by a lot of experts in the area. They have a lot of pages in their wiki that address crypto concerns... https://www.owasp.org/index.php/Guide_to_Cryptography https://www.owasp.org/index.php/Guide_to_Cryptography https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_... https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
- tptacek 15y agoOWASP is a great resource with a terrible track record for application cryptography.
- chrismsnz 15y agoWhoops, I will stand corrected. Casting my eye over the recommendations in the pages I linked - yes some of it seems to be a little behind the times (for instance, adaptive hashing isn't mentioned once in terms of securing passwords), but none of it seems outright terrible. Is this something that the crypto community/experts can come together and improve the same way as the vuln/exploit security community have made OWASP what it is? Or is the real truth that executing proper crypto techniques are simply to difficult to boil down into a pile of cheatsheets?
- orthecreedence 15y agoOddly enough, this article prompted me to setup bcrypt hashing for our unreleased app. I tend to not follow the tide when it comes to people screaming on the internet about something. People get highly emotional about the "next big thing" and defend with every ounce of willpower the decisions they've made. While I understand this mentality, it can make it hard to be objective. Seeing an article where someone disagrees with the buzzing hive mind is always refreshing for me and made me actually consider, for the first time, that an algorithm aside from sha1(app_salt + user_salt + password) would be a good idea. I did some research and decided that for PHP, bcrypt is the absolute easiest option to implement. scrypt is too new, PBKDF2 while administratively accepted has much less info on using it in PHP than bcrypt does. So while I ultimately ended up disagreeing with the author, the article was invaluable in the end.
- m8urn 15y agoYes, Use Bcrypt. And Scrypt: http://news.ycombinator.com/item?id=3725284 http://news.ycombinator.com/item?id=3725284
- tzs 15y agoSuppose hypothetically you knew everyone using your service used a strong password. Say they all have good password managers that generate 40 character random passwords for them. Is there then any need to do more than a simple salted hash? (Remember, the hypothesis is that all your users are using strong passwords).
- tptacek 15y agoThe difference in that (obviously unrealistic) case is (I think?) between a cost per password of hundreds of thousands of dollars versus high tens of millions of dollars.
- emboss 15y agoWhile we agree on the fact that using either of the three can't be a bad thing, I'd like to give my opinion on why I favor PBKDF2 over bcrypt, and probably even over scrypt, although I admit the "memory-hardness" of the latter makes it superior in principle. But still, my reasons for going with PBKDF2: It's not just that it's endorsed by RSA, no it's actually the NIST recommendation for password hashing and I find it rather unfair that people on this thread turn that against it! It's the same argument why we generally recommend AES over let's say Twofish or Serpent. We all agreed here that in crypto it's a good thing to be mainstream. And being recommended by NIST makes you Justin Bieber, or not? Standard algorithms may be poor, true, but being a standard has one important advantage: most of the public scrutiny goes into the standard. Much more money and fame there. So it's much more likely that the public will get to know about a flaw in the standard faster than it will get to know about flaws in non-standard algorithms. And that's why I follow standards - even if it's a crappy algorithm, I will know immediately when it's broken and I can react by replacing it right away. The time between an algorithm gets broken and the fact becoming public knowledge is potentially higher the less common an algorithm is. And the time in between being broken and being public knowledge is the most dangerous in my opinion. I'd like to point out that bcrypt is not equal to Blowfish. It piggybacks on Blowfish's key setup. But note that it just piggybacks, on top of that it further extends the original key setup. Blowfish's key setup was probably never invented to do what bcrypt does now, and the last 30min of googling have not brought up any papers about bcrypt cryptanalysis. Compare that to HMAC. Compare that to using PBKDF2 with HMAC SHA-3 when it's out. I'm not saying that Blowfish or any of its parts are bad, but if not PBKDF2 itself, but then most certainly its building blocks have received a lot more analysis than bcrypt or scrypt. With SHA-3 on the horizon the research community knows a lot more about hash algorithms and there is a lot of research going into these topics. That's why I personally feel safer with a construction that maybe in itself has not received more research than the other two alternatives, but where its building blocks almost certainly have, unless somebody proves me wrong. And when that happens, I'll stand happily corrected and will use the next standard.
- dlitz 15y agoI wasn't aware that anyone suggested using bcrypt for key derivation. The idea, as I understood it, was to avoid writing your own password hashing implementation. Bcrypt is a complete password-hashing implementation, so use it, rather than cobbling something together yourself. This is the standard advice for cryptographic software. PBKDF2 isn't a password hash: the specification doesn't define a storage format for iterated, salted password hashes. It's not that hard to invent one if you already specialize in writing cryptographic software, but most programmers still shouldn't be doing that. It's just too easy to make mistakes that go unnoticed until it's too late. If you insist on using PBKDF2, then I suggest using my PBKDF2.crypt() implementation at https://github.com/dlitz/python-pbkdf2 https://github.com/dlitz/python-pbkdf2. I'm not a cryptologist, but I'm the maintainer of PyCrypto, so presumably I can be trusted to do a better-than-average job of this sort of thing. If people want, I'll write a proper spec and add SHA256 support with a different algorithm identifier (the current implementation still uses SHA1). But really, if you need a password hash, just use bcrypt and get back to writing the code that actually provides value to your user base and differentiates you from your competitors. Bcrypt is good enough for now. This advice might change in the future, so do pay attention, but for now, just use bcrypt.
- antihero 15y agoI know this may be dumb, but why don't we chain all the algorithms, then if one is broken the passwords are still secure.