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

151–160 of 193 posts

Re: Don't use bcrypt

#151

Post by davidcash »

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…

Moreover, what we (= provable security wonks) really don't understand is collision resistance, or, more generally, cryptographic security notions that are stronger than one-wayness (really UOWHF) and that do involve a secret key.

Trusting blockciphers over hashes based on this high-level argument is suspect, at least in principle. (To be clear, I'm not arguing with your practical recommendations as they seem pragmatically justified.) It could well be the case that the ways we build password hashes from blockciphers appear to be more secure simply because we haven't sufficiently cryptanalyzed blockciphers for the necessary collision-resistance-type properties. Perhaps collision resistance is just too much to hope from any highly-efficient function, and it is only a matter of investing the effort to find collisions in the functions derived from blockciphers. Adding to the suspicion is the fact that blockciphers give us good hashes by coincidence, not design (And formal evidence doesn't help explain the situation - although I see hand-wavy claims about related-key attack resistance being sufficient, in my work I've only found reverse connections).

So are you aware of any deeper reasoning behind the blockciphers-over-hashes argument? Could trusting blockciphers for collision-resistance just be a good usage of security-through-obscurity, because a tremendous amount of effort has been invested in finding collisions in the hash functions but not in the blockciphers?

Re: Don't use bcrypt

#152

Post by pygorex »

pnathan wrote: post #84
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…

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

> Its a disservice to keep telling people that they are too stupid to understand something

That's not the point. Specialization - developing a deep understanding requires time and effort. As a developer choosing a way to store passwords securely is one task out of 1,000 I'm responsible for. So I acquire a general understanding of cryptography to make a decision - but that decision relies heavily on experts and consensus. The worst thing I can do as a developer is to go down the rabbit hole of cryptography and spend 10 hours researching an optimal password hashing scheme for my app. Sure, I've begun the journey of having a deep understanding of crypto - but I still have 999 things to do!

Which reminds me I need to get off HN and get some work done .....

Re: Don't use bcrypt

#153

Post by Xylakant »

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've yet to see a website that get bogged down with authentication request in normal operation, even if those request measure in the multiples of 10ms. The basic idea with all those "slow" password hashes is that authentication is a pretty rare request compared to all other request. Usually authentication requires a single request, at most a handfull. If you run into trouble with bcrypt/scrypt on your webservers, you're doing things wrong. If you have that many authentication requests, direct them to a dedicated server - you'll be in the league that has a large farm running anyways.

Granted, an attacker could use your slow hash for a DOS-attack, but most websites I've seen so far always had some sort of slow operation that was easily exploitable without authentication.

Re: Don't use bcrypt

#154

Post by marshray »

sirclueless wrote: post #148
marshray wrote: post #138

Earlier quoted context omitted.

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?

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 it enters a completely pathological memory locality access pattern and stays there for almost the whole function. This works to neutralize the advantage of an attacker who has a custom CPU because he probably can't also develop a custom RAM subsystem to feed it with (at least not one that's many times more efficient than what the defender has in his server).

But if you've done any performance tuning on multithreaded code, you know that cache effects caused by memory access patterns very quickly begin to dominate as multiple cores and threads are added. Things that look great in single-threaded benchmarks almost never scale linearly and there's probably nothing that will scale worse on our shared-memory multiprocessors than Scrypt. It's a feature.

So the defender (say, a busy website with commodity multicore servers) with Scrypt is likely not going to be able to take as good an advantage of his hardware. He won't be able to crank up the work factor quite as high as he could with Bcrypt or PBKDF2.

This may represent an advantage to the attacker, who doesn't have the additional constraint of keeping the response time up on a busy webserver. This attacker's advantage is probably not significant by cryptographic standards (maybe 2 or 3 bits of security lost), but pathological multithreading could represent a big issue operationally.

I'm honestly not trying to cast FUD on Scrypt here, I think it's the best function. I'm just saying like everything else multithreaded you really need to benchmark it under real-world conditions.

Re: Don't use bcrypt

#155

Post by chrismsnz »

steveh73 wrote: post #144

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…

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.php/Password_Storage_Cheat_Sheet

Re: Don't use bcrypt

#156

Post by tptacek »

steveh73 wrote: post #144

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…

    Need to sign a message? Using S/MIME or PGP.
    Need to checksum a file? Use SHA256.
    Need to hash a password? Use bcrypt, scrypt, or PBKDF2.
    Need to transmit data over a network? Use HTTPS/TLS
    Need to secure HTTP? Use HTTPS/TLS, preferring AES in CTR and then CBC.
    Need to secure home WiFi? Use WPA2PSK.
    Need to encrypt files? Use any implementation of PGP.
    Need to do (this type) of encryption? Use PGP. Never use AES directly. Never use ECB for anything.
    Need to create a TrueCrypt volume? Can't help you; we use PGP.

Re: Don't use bcrypt

#157

Post by tptacek »

chrismsnz wrote: post #155
steveh73 wrote: post #144

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…

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.

Re: Don't use bcrypt

#158

Post by marshray »

Xylakant wrote: post #153
marshray wrote: post #138

Earlier quoted context omitted.

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've yet to see a website that get bogged down with authentication request in normal operation, even if those request measure in the multiples of 10ms. The basic idea with all those "slow" password hashes is that authentication is a pretty rare request compared to all other request. Usually authentication requires a single request, at most a handfull. If you run into trouble with bcrypt/scrypt on your webservers, you…

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 attack. Not so much with authentication.

Re: Don't use bcrypt

#159

Post by nknight »

pygorex wrote: post #152
pnathan wrote: 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…

> Its a disservice to keep telling people that they are too stupid to understand something That's not the point. Specialization - developing a deep understanding requires time and effort. As a developer choosing a way to store passwords securely is one task out of 1,000 I'm responsible for. So I acquire a general understanding of cryptography to make a decision - but that decision relies heavily on experts and consen…

> So I acquire a general understanding of cryptography to make a decision

But this is precisely what the cult priests don't want you to do. There are only two words you need to know: "use bcrypt". Any attempt to learn more is heresy.

Re: Don't use bcrypt

#160

Post by marshray »

tptacek wrote: post #140
JoachimSchipper wrote: post #136

Earlier quoted context omitted.

I agree, but: > PBKDF2 deployments virtually all use SHA2 as their PRF, and PBKDF2/SHA2 is a construction that depends entirely on the security of hash functions A quick look at Wikipedia (and my own recollection) suggests that it may be more commonly used with HMAC -SHA2. Although the HMAC construction is not provably secure [1] and poorly understood, it seems to be fairly resistant to attack (e.g. HMAC-MD5 is not k…

You're right, but the kinds of research results that would accelerate a brute force PBKDF2/HMAC-SHA2 cracker are a superset of the results that would jeopardize HMAC-SHA2 as a MAC. Not to downplay it (it's very important that you get HMAC right) but HMAC-SHA2 is just double-applying SHA2. I was imprecise, but my point is just, PBKDF2/xSHAx is a construction that relies entirely on the properties of cryptographic hash…

Except that SHA-1 and SHA-2 are constructed from a block cipher too.

"SHACAL". Look it up! ;-)

Post reply on HN