Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use bcrypt

unlimitednovelty.com

Post reply on HN
Print view View original

141–150 of 193 posts

Re: Don't use bcrypt

#141

Post by dchest »

cperciva wrote: post #139
dchest wrote: post #23

Earlier quoted context omitted.

Doesn'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?

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

Thank you for your answers.

Re: Don't use bcrypt

#142

Post by marshray »

tptacek wrote: post #95
pbsd wrote: post #90

Earlier quoted context omitted.

I see you've adopted Moxie's argument, block ciphers against hashes. Very well. The hard part of designing a good hash function is achieving collision-resistance; one-wayness is easy. In this context, we don't really care about collision-resistance, since HMAC can be a PRF without collision resistance of the underlying hash (there was a recent proof by Mihir Bellare) --- this is why it's still "OK" to use HMAC-MD5, d…

It's not "Moxie's argument". It's also Schneier and Ferguson's argument from Cryptography Engineering: Event hough hash functions are used in almost every system, we know far less about hash functions than we do about block ciphers. This is one of the failures of the cryptographic community. Compared to block ciphers, very little research has been done on hash functions, and there are not many practical proposals to…

I think that book is going to need an update soon as the SHA-3 competition has directed a significant amount of research behind hash function security.

The good news is that SHA-2 and HMAC remain in pretty decent shape (known limitations notwithstanding).

Re: Don't use bcrypt

#143

Post by marshray »

JoachimSchipper wrote: post #132
marshray wrote: post #125

Earlier quoted context omitted.

Yep. There are off-the-shelf FPGA arrays available. Still, bad guys would probably find it much cheaper to rent botnet time for a $0.02/(host*day) or whatever the going rate is. A solid 80 bits of security out of any of these functions might turn out to be safe forever. But, in practice, most password databases are going to have some fraction of users choosing passwords straight out of the cracker's dictionary, some…

COPACOBANA cost ~$10 000 and apparently is as fast as 2500 PCs for the DES cracking it's optimized for, so ~$4/PC-work-unit plus insignificant power costs. You'd need to find someone with experience with implementing crypto in hardware, though. On the other hand, botnets risk detection. (If you're buying in bulk, ASICs are cheaper, but few will be willing to pay for that much cracking power.)

Yeah, I suspect it depends on your bad guys (er, sorry, "threat model") whether or not they feel more comfortable trying to buy botnet time or acquire $10,000 worth of FPGAs in an untraceable way.

If I were a bad guy, I would prefer to not have a password-cracking special-purpose supercomputer in my possession. (But I'm not a bad guy, and in fact I would love to have a few around the house. :-)

Re: Don't use bcrypt

#144

Post by steveh73 »

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

Re: Don't use bcrypt

#145

Post by pbsd »

cdavidcash wrote: post #122
moxie wrote: post #54

This 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) t…

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. Is this a common opinion amongst practitioners? The opposite philosophy (e.g., that a random oracle is a "weaker object" than an ideal cipher) underlies some lines of work in the theoretical cryptography…

The two models are equivalent, in fact: http://eprint.iacr.org/2008/246

This of course says nothing about how to go about building an actual cipher/hash that withstands all kinds of cryptanalysis.

Edit: apparently not so clear, I'm told: http://arxiv.org/abs/1011.1264

Re: Don't use bcrypt

#146

Post by orthecreedence »

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

Re: Don't use bcrypt

#147

Post by davidcash »

pbsd wrote: post #145
cdavidcash wrote: post #122

Earlier quoted context omitted.

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. Is this a common opinion amongst practitioners? The opposite philosophy (e.g., that a random oracle is a "weaker object" than an ideal cipher) underlies some lines of work in the theoretical cryptography…

The two models are equivalent, in fact: http://eprint.iacr.org/2008/246 This of course says nothing about how to go about building an actual cipher/hash that withstands all kinds of cryptanalysis. Edit: apparently not so clear, I'm told: http://arxiv.org/abs/1011.1264

A better interpretation of that paper is that it is giving an upper [edit: upper bound] on how inequivalent the models are.

Also, that paper was subsequently shown to be fatally flawed. http://arxiv.org/abs/1011.1264

Anyway, yeah, a theoretical diversion.

Re: Don't use bcrypt

#148

Post by sirclueless »

marshray wrote: post #138
cperciva wrote: post #130

Earlier quoted context omitted.

The Scrypt x5000 seems to only apply when your attacker has access to a chip foundry If your attacker is using GPUs, scrypt probably gives you an even bigger win, due to the compute/memory balance they use.

So I reckon he won't use GPUs then, eh? Note that the defender pays a cost for this too though. Where he could be happily running PBKDF2 or Bcrypt in multiple Apache process on his multicore servers, Scrypt is going to completely trash the L2/L3 caches and saturate the memory bus and make everything else on the server run like a dog. Scrypt is operating as designed, of course, but it raises the question of whether or…

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?

Re: Don't use bcrypt

#149

Post by jiggy2011 »

bascule wrote: post #105
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…

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

It depends what level you are using it on. If you are writing crypto libraries on your own then sure you are at significant risk of screwing it up, but a good crypto library should have good defaults that will provide proper security.

Expecting every programmer who needs to build an application that stores passwords or personal information etc to have a rigorous mathematical understanding of crypto (this probably means having a PhD or similar in the subject) is just plain unrealistic.

It's sort of akin to suggesting you shouldn't allow a mechanic to change the brakes on your car without them having a detailed understanding physics.

Re: Don't use bcrypt

#150

Post by maaku »

regularfry wrote: post #61
cperciva wrote: post #24

Earlier quoted context omitted.

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

When 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?

No you were not wrong. That is the correct, conservative attitude to take in most instances.
Post reply on HN