41–50 of 193 posts
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.
TLDR: 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.
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/i...), while PBKDF2's is the September 2000 RFC (http://www.ietf.org/rfc/rfc2898.txt).
Earlier quoted context omitted.
And 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.
It'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.
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.
Earlier quoted context omitted.
As 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.
What can you share with us about the quality of cryptographic research at big software companies? And, besides that one: what are some other big companies whose cryptographic research you would rely on when selecting algorithms and crypto constructions? Are you sure you know what you're talking about here? I'm not saying you don't, but most HN'ers who would write a comment like yours don't.
PBKDF2 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 effecti…
You seem to be speaking only to its compute time -- what do you say to the article's claim that bcrypt has a higher probability of having an unexpected attack that mitigates its computational complexity?
Also, since all of these algorithms have adjustable work factors, what does it even mean to say that one is stronger than another? Couldn't you just calibrate the work factors so that they are equivalently strong? Though naturally scrypt has strength in another dimension also (memory).
I 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 ma…
[deleted]
Why, 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 recommen…
PBKDF2 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 effecti…
> PBKDF2 is worse than bcrypt. You seem to be speaking only to its compute time -- what do you say to the article's claim that bcrypt has a higher probability of having an unexpected attack that mitigates its computational complexity? Also, since all of these algorithms have adjustable work factors, what does it even mean to say that one is stronger than another? Couldn't you just calibrate the work factors so that t…
But that's not my issue with the article. My issue with the article is that it takes a simple security issue with no "real" wrong answers and turns it into a tribal conflict, which has the net effect of reducing the number of people who will use adaptive hashing at all.
I'm familiar with Tony Arcieri's work and generally think highly of him; this article, though, is inexplicable and smacks of hipsterism. "I liked Nirvana but then they got popular and sold out, so now I listen to Sleater Kinney". Well, that's going to sound dumb in 10 years.
Let me say yet again that if you use PBKDF2, bcrypt, or scrypt, you are going to look smarter than the average webdev, no matter which one you pick. Do whichever is easiest.
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.
Earlier quoted context omitted.
What can you share with us about the quality of cryptographic research at big software companies? And, besides that one: what are some other big companies whose cryptographic research you would rely on when selecting algorithms and crypto constructions? Are you sure you know what you're talking about here? I'm not saying you don't, but most HN'ers who would write a comment like yours don't.
I can't share anything. All I can do is respect the peer review process. I'm certainly not making the real appeal to authority of "they are a big company, so they make good ciphers". If you have something specific, I'd love to hear it. In particular, I'd like to hear how social engineering negatively impacts cipher algorithms (negatively impacting key security doesn't count).
(Me just saying it won't be nearly as impactful, because apparently I'm in the tank for bcrypt).
Don't know? This will make a worthwhile 30 minute Googling project. That's what I do when I get in over my head, and I promise, learning about adaptive hashing is going to be more useful than reading court decisions about what does or doesn't constitute a breach of the duty of loyalty for a company director (to cite my last Google dive from HN).