6 ms·

"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 e

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

tptacek 14y ago
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.
- marshray 14y ago
  > "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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483
  - tptacek 14y ago
    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.
    - marshray 14y ago
      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.
      - jgeralnik 14y ago
        How about this: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1 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.
        marshray 14y ago
        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.
        tptacek 14y ago
        NIST standardization sure didn't help SHA2: http://mail-index.netbsd.org/tech-security/2009/07/28/msg000250.html 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.
        marshray 14y ago
        OK, so here's the patch to the bug in question: http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.17&r2=1.18&only_with_tag=MAIN 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 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?r1=1.1.4.1&r2=1.1.4.2&only_with_tag=netbsd-4 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?... http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.2.4.4&r2=1.2.4.5&only_with_tag=netbsd-4 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.
danielweber 14y ago
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").
- thirsteh 14y ago
  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 http://i.imgur.com/iUpUk.png (from http://www.tarsnap.com/scrypt/scrypt.pdf http://www.tarsnap.com/scrypt/scrypt.pdf)
dchest 14y ago
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.
- thirsteh 14y ago
  Yeah, that was weird. Talk about learning the wrong lesson, or learning the right one and applying it to the wrong thing.

tptacek 14y ago

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.

marshray 14y ago
> "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 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2483
- tptacek 14y ago
  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.
  - marshray 14y ago
    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.
    - jgeralnik 14y ago
      How about this: http://blog.fortify.com/blog/fortify/2009/02/20/SHA-3-Round-1 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.
      - marshray 14y ago
        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.
        tptacek 14y ago
        NIST standardization sure didn't help SHA2: http://mail-index.netbsd.org/tech-security/2009/07/28/msg000250.html 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.
        marshray 14y ago
        OK, so here's the patch to the bug in question: http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.17&r2=1.18&only_with_tag=MAIN 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 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?r1=1.1.4.1&r2=1.1.4.2&only_with_tag=netbsd-4 http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/sha2.h.diff?... http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/hash/sha2/sha2.c.diff?r1=1.2.4.4&r2=1.2.4.5&only_with_tag=netbsd-4 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.

danielweber 14y ago

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

thirsteh 14y ago
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 http://i.imgur.com/iUpUk.png (from http://www.tarsnap.com/scrypt/scrypt.pdf http://www.tarsnap.com/scrypt/scrypt.pdf)

dchest 14y ago

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.

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