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

111–120 of 193 posts

Re: Don't use bcrypt

#111

Post by SoftwareMaven »

tptacek wrote: post #93
SoftwareMaven wrote: post #91

Earlier quoted context omitted.

But, as mentioned by @cperciva elsewhere in this thread, generating a key and creating a password hash are nearly synonymous. Using HKDF for passwords would be silly, but the more interesting question is: when would you use scrypt for key derivation in a system? More to the point: what are the tradeoffs you'd consider in choosing one over the other? (Addressed more to @cperciva...) I'm assuming tarsnap uses scrypt as…

I'm quoting the actual paper.

I am aware. I did read it before I posted it.

Re: Don't use bcrypt

#112

Post by pbsd »

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…

You're right, I do recall that passage. Apologies if I sounded patronizing.

I tried to be careful with the wording, precisely to avoid making a common-sense statement into a controversy. Yes, block ciphers are more well-studied (2012-70s > 2012-80s). My point was that the gap is much smaller now than (say) when AES was standardized (I wonder, was that passage also in the "Practical Cryptography" 2003 book?).

As a personal note, I doubt 5-10 years from now SHA-2 will have been compromised for password hashing (or HMAC), though. It has been remarked several times during the process that SHA-2 would have made a great SHA-3 candidate, its only major flaw being length extension attacks. The main fear was that SHA-2 would succumb to the same techniques as SHA-1 and MD5; so far, that has not been the case (perhaps because everyone is fighting it off with the SHA-3 candidates).

Of course, I didn't write a blog post either with anything. I don't blog. Given the choice, I'd give priority to PBKDF2; that's about it. Of course, I'm not a customer-facing developer, so my worries are different.

Re: Don't use bcrypt

#113

Post by tptacek »

SoftwareMaven wrote: post #111
tptacek wrote: post #93

Earlier quoted context omitted.

I'm quoting the actual paper.

I am aware. I did read it before I posted it.

So you think maybe Hugo Krawczyk is mistaken? :)

Short answer: I think scrypt is an advancement over the class of constructions HKDF belongs to. If you're picking nits about which function to use, use scrypt.

Re: Don't use bcrypt

#114

Post by JoachimSchipper »

marshray wrote: post #94
marshray wrote: post #71

Earlier quoted context omitted.

> By roughly a factor of (5|4000). Do you have this written up anywhere? Link?

OK, it's in the Scrypt paper. http://www.tarsnap.com/scrypt/scrypt.pdf Here's my opinion on this: * These numbers are more appropriately expressed exponentially. I.e. "factor of 5" = 2 bits of security. * 2 bits of security is not significant at all. * The Scrypt x5000 seems to only apply when your attacker has access to a chip foundry and it buys you maybe about 12 bits of security against such an attacker. * For co…

You're right, but don't forget Deep Crack. (FPGA-)hardware-based attacks have only become cheaper since then; I would be surprised if the NSA doesn't have a few arrays.

(Also, 80 bits is usually enough to withstand attack, no?)

Re: Don't use bcrypt

#115

Post by m0nastic »

jiggy2011 wrote: post #85

To be honest, if anybody breaks into your web application it is very unlikely to be because they broke any encryption. SQL injection or man in the middle type attacks are far far more likely. What you need out of an encryption package is in the event of being tested for PCI compliance or any legal liability investigation into a breach. You need to be able to say "all of our encryption is done with bcrypt , it's the i…

The debate around secure password storage is sort of orthogonal to initial compromise of a web application.

The reason that it's important (although as others here have noted, less important than primary application security concerns) is what areas of attack are opened up by using insecure password storage "after" an initial compromise.

This could be something as simple as being a nuisance to users of the system (having to send out those "our password database was compromised, and we didn't do a good job of storing them securely, so you should probably change all of your associated passwords), to something much more serious (using said insecurely stored passwords to attack your other systems for example).

PCI doesn't really care how you're encrypting your data at rest. I cracked the password storage from an application once which was literally just a simple substitution cipher (which was positionally dependent...it was for all intents and purposes as secure as a newspaper cryptogram puzzle). That application was PCI compliant.

While "what you need out of an encryption package" might just be the bare minimum of "cover your ass", that's no reason to settle for insecure password storage.

Re: Don't use bcrypt

#116

Post by JoachimSchipper »

bascule wrote: post #107
tptacek wrote: post #48

Earlier quoted context omitted.

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.

Why? "Use bcrypt" is boring from a crypto-nerd point of view, but it's a really useful meme.

Re: Don't use bcrypt

#117

Post by bascule »

JoachimSchipper wrote: post #116
bascule wrote: post #107

Earlier quoted context omitted.

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

Why? "Use bcrypt" is boring from a crypto-nerd point of view, but it's a really useful meme.

I thought I explained that in my blog post. scrypt is superior to bcrypt in every regard.

At the very least, I'd rather the meme be: Use bcrypt, scrypt, or PBKDF2.

Re: Don't use bcrypt

#118

Post by ams6110 »

FaceKicker wrote: post #110
specialist wrote: post #99

Earlier quoted context omitted.

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?

I would say that yes, every voter needs to be able to comprehend the system. Counting paper ballots is something anyone of normal intelligence can understand. Auditing them is something everyone can understand. Not so for cryptographic based systems, particularly proprietary systems.

The only electronic voting system I'd probably be OK with is one that is totally open-source, software and hardware. The implementation must be completely transparent.

Even then, fraud will happen. Always has, always will.

Re: Don't use bcrypt

#119

Post by marshray »

grandalf wrote: post #36

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

For one, it's something the government uses for its own crypto.

Unlike some crypto standards, PBKDF2 is just something too simple and too user-configurable to be able to hide a meaningful hole in. Given that PBKDF1 was found to be less-than-ideal and depracated in favor of the better PBKDF2, it would be a very risky proposition to attempt to weaken it in a way that gave a meaningful advantage to one party over the other.

Re: Don't use bcrypt

#120

Post by JoachimSchipper »

grandalf wrote: post #36

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

PBKDF2 is a fairly "obvious" construction (it's mostly just repeated HMAC'ing); it would be really hard to hide anything clever in it.
Post reply on HN