[deleted]
Don't use bcrypt
31–40 of 193 posts
Re: Don't use bcrypt
#32[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 recommending bcrypt).
Re: Don't use bcrypt
#33"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.
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.
Re: Don't use bcrypt
#34I 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/ ) EDIT…
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.
Re: Don't use bcrypt
#35However, 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?
As 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.
Bullshit. 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?
Re: Don't use bcrypt
#36How 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.
Re: Don't use bcrypt
#37PBKDF2 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…
How does one stay up-to-date on this stuff? Or is it just something that's easier to remember for someone who specializes in security?
Re: Don't use bcrypt
#38"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.
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.
Re: Don't use bcrypt
#39Earlier 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.
No, 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.
Ad 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?
Re: Don't use bcrypt
#40PBKDF2 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…
How does one stay up-to-date on this stuff? Or is it just something that's easier to remember for someone who specializes in security?
bcrypt is something like a decade old. You don't have to stay up-to-date on it. The vulnerability that bcrypt accounts for dates back to 1972.
All you have to do is not design your own password hashes with SHA-2 (or Whirlpool or CubeHash or whatever some random Stack Overflow answer says you should use). You can safely keep PBKDF2, bcrypt, and scrypt in your bag of tools --- of those, only scrypt is recent --- and reach for whichever one is easiest.