Don't use bcrypt • Hacker News Board

Re: Don't use bcrypt

#171

Post by InclinedPlane » Mon, Mar 19, 2012, 11:50 PM UTC

InclinedPlane wrote: post #81

smacktoward wrote: post #49

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

Option 1: Rely on what everyone else does. What happens if that method is flawed? You hear about it as soon as it's discovered and it gets fixed quick. Option 2: Roll your own stack based on a personal understanding of cryptography. What happens if that method is flawed? Perhaps only you and an attacker could possibly know such a thing. You have to be ever vigilant and you have to acquire an incredible amount of cryp…

To add on to this, it is of course necessary to have enough familiarity and competence with the basic principles of cryptography to know that you're "doing what everyone else is doing" correctly, instead of just some silly pantomime, such as: http://thedailywtf.com/Articles/Topgrade,-SHA1-Encryption.as...

But it's not necessary to understand the depths of cryptography beyond that there are various black boxes that have certain properties.

Re: Don't use bcrypt

#172

Post by lhnn » Tue, Mar 20, 2012, 12:23 AM UTC

tptacek wrote: post #35

lhnn wrote: post #6

Earlier quoted context omitted.

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

I'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.

Re: Don't use bcrypt

#173

Post by chrismsnz » Tue, Mar 20, 2012, 12:35 AM UTC

tptacek wrote: post #157

chrismsnz wrote: post #155

Earlier quoted context omitted.

I 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/Cryptographic_Storage_Cheat_... https://www.owasp.org/index.…

OWASP is a great resource with a terrible track record for application cryptography.

Whoops, 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?

Re: Don't use bcrypt

#174

Post by lhnn » Tue, Mar 20, 2012, 1:00 AM UTC

there wrote: post #101

lhnn wrote: post #6

Earlier quoted context omitted.

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.

I 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".

Re: Don't use bcrypt

#175

Post by tzs » Tue, Mar 20, 2012, 1:14 AM UTC

Suppose 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).

Re: Don't use bcrypt

#176

Post by emboss » Tue, Mar 20, 2012, 1:37 AM UTC

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

Re: Don't use bcrypt

#177

Post by repsilat » Tue, Mar 20, 2012, 1:54 AM UTC

cheald wrote: post #127

zobzu wrote: post #88

Earlier quoted context omitted.

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

This is a naive attitude. Mathematically-secure cryptography with an implementation that avoids all side-channel attacks is unbreakable , as in, would take more time than the projected heat death of the universe to brute force. That's not to say that all implementations are secure, or that there are not undiscovered mathematical flaws in common algorithms, but the idea that all encryption is brute-forcable given enou…

> Mathematically-secure cryptography ... is unbreakable

To expand on sibling comments: Cryptography essentially depends on the assumption that P=NP (well, not exactly, but...). It's possible, though unlikely, that mathematical discoveries could undermine all possible conventional cryptographic schemes.

As for brute-force, that's a tricky one as well. If you allow a strengthening of Moore's law that says that operations per second per dollar increase exponentially, then you can construct the following "polynomial time" algorithm for any cryptographic problem:

    Wait n*k years, where
      - n is the problem size in bits, and
      - k is a scaling factor to get the exponents to align
    Buy a computer
    Run the brute force algorithm on your new computer

Re: Don't use bcrypt

#178

Post by tptacek » Tue, Mar 20, 2012, 2:00 AM UTC

tzs wrote: post #175

Suppose 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).

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

Re: Don't use bcrypt

#179

Post by cperciva » Tue, Mar 20, 2012, 3:44 AM UTC

moxie wrote: post #170

marshray wrote: post #158

Earlier quoted context omitted.

OK, but what if you're a web app that specializes in authentication (like, say, an Oath provider) or a database server where the attacker-facing app doesn't use connection pooling? > but most websites I've seen so far always had some sort of slow operation that was easily exploitable without authentication Yes, but those things are typically easy to optimize or temporarily disable in a hurry once they come under atta…

Yep, I work close to an extremely high traffic OAuth endpoint. I think scrypt would probably "cost" a lot more in terms of actual servers required to operate it.

scrypt is tunable; you can make it use as much or as little CPU time as you want. For any particular amount of CPU time, scrypt will give you more security than bcrypt or PBKDF2 would give you for the same amount of CPU time.

Re: Don't use bcrypt

#180

Post by cperciva » Tue, Mar 20, 2012, 4:44 AM UTC

marshray wrote: post #154

sirclueless wrote: post #148

Earlier quoted context omitted.

I thought the definition of "better" in this case is that it requires less work to get the same computational strength with scrypt. Are you saying that the memory locality issues that scrypt causes more than cancel out the computational win?

In this context, work is computational strength so what we're mainly concerned about is an attacker finding a way to do the task significantly more efficiently than the defender. E.g., if the attacker can evaluate the function with half the cost on his power bill relative to the defender, then that can be thought of as knocking off 1 bit of security off the top. The primary advantage of Scrypt over the others is that…

scrypt's memory access pattern isn't particularly pathological; it's random, sure, but it reads large blocks.

The key issue isn't the design of the RAM subsystem but instead the design of the RAM subsystem -- in particular, making sure the attacker can't "cheat" by using a smaller circuit than the defender.