Hacker News Reader

Comment by josephscott | Hacker News Reader

"The poor state of passwords protection in web services: passwords are too often either stored in clear (these are the services that send you your password by email after hitting "I forgot my password"), or just hashed with a cryptographic hash function (like MD5 or SHA-1), which exposes users' passwords to efficient brute force cracking methods."

If you can't get people to use current crypto hashing techniques like bcrypt or scrypt why would coming up with another one help?

Of course it would be nice to see something with the work factor features of bcrypt that were more specifically resistant to GPU optimized crackers.

View on HN

I'm torn.† On the one hand, it sends a "jury is out" message on modern password hashing in general. On the other hand, developers already handwave about "bcrypt not having gotten enough cryptographic review", as if someone was ever going to publish a cryptanalytic result showing bcrypt to be worse than SHA1.

I'd have liked the jury to have been back on this last decade, but I'll settle for it being in next year.

By the way, the construction you're looking for is scrypt.

† I'm not really torn.

> "jury is out"

One advantage of a jury being out is that someday said jury can come back in and return a verdict.

> as if someone was ever going to publish a cryptanalytic result showing bcrypt to be worse than SHA1.

SHA-1 has a formal specification, an RFC, a reference implementation, implementation guidance, and comprehensive test vectors published. To date, bcrypt is lacking some of those things.

And yes, bcrypt has gotten pwned worse than SHA-1 as a result: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483

Give me a break. That's an application implementation flaw, and one no standard could have prevented. It's like saying that insufficient cryptanalysis is responsible for the OpenSSL RCEs.

Again: I'm not really torn. It's a good thing you're all doing this.

The jury is not really out on bcrypt, though.

one no standard could have prevented

Then I'm sure you'll have no trouble* finding similar vulnerabilities introduced by implementation flaws of any NIST (or even IETF) defined algorithms.

*Note: sarcasm.

How about this: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-...?

Granted, these were just candidates and not actually NIST defined algorithms, but the point stands that algorithms can be fine while standard implementations have bugs.

Those were round 1 submissions, not even close to being "standard implementations". Which proves my point that the standardization process works to minimize implementation bugs in implementations of the standard.

NIST standardization sure didn't help SHA2:

http://mail-index.netbsd.org/tech-security/2009/07/28/msg000...

You're just wrong about this point, Marsh. You are very smart and often right, but not invariably so.

OK, so here's the patch to the bug in question:

http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash...

     +	/* The state and buffer size are driven by SHA256, not by SHA224. */
      	memcpy(context->state, sha224_initial_hash_value,
     -	    (size_t)(SHA224_DIGEST_LENGTH));
     -	memset(context->buffer, 0, (size_t)(SHA224_BLOCK_LENGTH));
     +	    (size_t)(SHA256_DIGEST_LENGTH));
     +	memset(context->buffer, 0, (size_t)(SHA256_BLOCK_LENGTH));

The NetBSD code was confused about which algorithm it was implementing. This can hardly be used to generalize about vulnerabilities in specific NIST approved algorithms.

You're just wrong about this point, Marsh. You are very smart and often right, but not invariably so.

So even if we allow this example as meeting my test of similar vulnerabilities introduced by implementation flaws of any NIST (or even IETF) defined algorithms I can still claim that this bug that existed in NetBSD only for 3 months in the spring of 2009 is the exception which proves the rule.

It doesn't compare at all in scope to http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483 in terms of the length of time, number of systems affected, or number of credentials created with weak cypto.

EDIT: Sorry, I'm looking at the wrong patch. It appears that at the time indicated in the advisory, a bunch of other stuff was added to the source tree.

Either I'm missing something obvious or there's a bit of misdirection going on. For example, it says: *"The overflow occurs at the time the hash init function is called (e.g. SHA256_Init). The init functions then pass the wrong size for the context as an argument to the memset function which then overwrites 4 bytes of the memory buffer located after the one holding the context." and "fixed: NetBSD-4 branch: Jul 22, 2009"

But the diffs of 2009-07-22 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?... http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash... don't seem to affect the memset call in SHA256_Init() at all or the size of the structure.

Oh, you mean like potential remote code execution in AES?

For reference, it looks like he's referring to this:

http://freecode.com/articles/suse-new-krb5-packages-fix-remo...

If I wanted to play dirty, I'd have mentioned ASN.1. :)

Or allowing \0 in X.509 fields.

I agree, ASN.1 sucks in terms of implementation in security-critical contexts.

But it's not a NIST or IETF standard, so it doesn't count. It's from ISO/IEC/ITU.

Do you have a link to the code with the bug?

I'll bet that "Specially crafted AES and RC4 packets" does not actually refer to the implementation of a NIST standard algorithm, just its usage in a context outside of such a standard.

The funny thing is that when BLAKE2 was announced, there were a lot of comments here, on reddit, and elsewhere, saying "but why is it fast? hashes must be slow to prevent password bruteforcing!". Authors had to add FAQ explaining the difference. So, at least some people have learned that "password hashes" must be slow.

Yeah, that was weird. Talk about learning the wrong lesson, or learning the right one and applying it to the wrong thing.

I attended a talk last month from [major security company] and he said that bcrypt was designed to be resistant against GPUs by using lots of space, and scrypt was for resistance to FPGAs.

I politely challenged him if that was right and he stuck to his guns, and honestly I haven't tried brute-forcing them myself so I couldn't really do any more than that. I thought scrypt was what was resistant to GPUs by using lots of space (hence the "s").

Kind of and not really. bcrypt's "memory-hardness" is minimal--it relies on the 4KB Blowfish setup cost (which stays constant.)

Designed for? Not for GPUs specifically (it was released in 1999), but the choice of Blowfish and its 4KB overhead was deliberate, and it makes hardware implementation harder. Effective against? Reasonably, but not compared to e.g. scrypt. Of course, SHA and friends still don't come close to bcrypt--they have a different purpose. (That also means that PBKDF2 is particularly bad in terms of memory cost: it's extremely easy to parallelize if you're using e.g. HMAC-SHA.)

scrypt tries to maximize the required die area by doing unpredictable (and tunable) memory access, and is significantly harder/costlier to run in parallel on ASICs and GPUs: http://i.imgur.com/iUpUk.png (from http://www.tarsnap.com/scrypt/scrypt.pdf)

Reply on news.ycombinator.com