Live data from Hacker News

Don't use bcrypt

unlimitednovelty.com

101–110 of 193 posts

Re: Don't use bcrypt

#101
post #6
post #2

However, 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.

The 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.

Re: Don't use bcrypt

#102
post #63

Earlier quoted context omitted.

Ladies & Gentlemen, Moxie Marlinspike, whose comment should be heading up this whole thread.

Now 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.

So, 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.

Re: Don't use bcrypt

#103
post #20

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…

I can't speak for other platforms, but at least as far as Ruby goes:

    $ gem install scrypt
    Building native extensions.  This could take a while...
    Successfully installed scrypt-1.0.3
    1 gem installed

Re: Don't use bcrypt

#104
post #20

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…

I can't speak for other platforms, but at least as far as Ruby goes: $ gem install scrypt Building native extensions. This could take a while... Successfully installed scrypt-1.0.3 1 gem installed

You can't go wrong with Ruby scrypt.

But then, unless you give up and don't use any of the three, you can't go wrong with any of these constructions.

Re: Don't use bcrypt

#105

> 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 m…

You're defending cargo cult cryptography? If you try to use crypto without understanding it, you're at great risk of using it wrong.

Re: Don't use bcrypt

#106
post #59

Earlier quoted context omitted.

Question: what does "memory hard" mean? Uses lots of RAM to preclude simultaneous connections running attempts in parallel?

Correct. 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 us…

Just 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.

Re: Don't use bcrypt

#107
post #48

Earlier quoted context omitted.

> 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…

It's nonsensical. It essentially argues that SHA2 is less likely to have cryptographic results relevant to hashing in the next 5 years than Blowfish. It's also an argument the post doesn't support with any actual evidence. 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 effe…

I fully admit the title is linkbait. My goal was to get people interested in the alternatives to bcrypt.

Re: Don't use bcrypt

#108

> 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 m…

You're defending cargo cult cryptography? If you try to use crypto without understanding it, you're at great risk of using it wrong.

The opposite turns out to be true in practice. People have the choice of using a simple crypto library interface (like BouncyCastle PGP) or "really getting to understand" AES, and so end up fielding software with vulnerabilities PGP addressed in the '90s.

A pithier way to say the same thing is, "you're right, except for the words 'without understanding it'".

Re: Don't use bcrypt

#109

> 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 m…

You're defending cargo cult cryptography? If you try to use crypto without understanding it, you're at great risk of using it wrong.

This is true, but most programmers don't and won't ever get a deep understanding of crypto. For that large majority, it makes complete sense to ask "What do the people who do understand crypto use in a case like this?" and use that.

That kind of copying is clearly inferior to either gaining the knowledge to make an informed decision or hiring an expert to do it for you, but for most projects that need crypto neither one of those is practical. So, copying the experts is the best practical approach in most cases.

Re: Don't use bcrypt

#110
post #84

Earlier quoted context omitted.

> 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. I hear that a lot, and it always reminds me of Jante Law[1]. Its a disservice to keep telling people that they are too stupid to understand something. Too ignorant, perha…

Cryptography is exactingly and excruciatingly hard to do at industrial strength. Related: Which is why I'm against any and all forms of electronic voting. I've done a fair share of crypto (as a user of crypto libraries) and I barely understand how it works. There's ZERO hope for the layperson to understand crypto-based voting systems. One of the central tenets of American style voting is a public vote count. Using cr…

Regardless of what you think of the kind of people who the government would contract to develop electronic voting machines, I don't think I'd call them "laypeople". Or are you saying that every individual voter needs to understand the inner workings of the system for it to be effective?
Post reply on HN