[cryptography] any reason PBKDF2 shouldn't be used for storing hashed passwords?
Any reason PBKDF2 shouldn't be used for (storing) hashed passwords? Seems like it solves many problems: 1) slowing down guesses (at cost of slowing valid entries too) 2) parameterized iteration 3) IV/salt/uniquification 4) widely deployed, tested 5) difficult to parallelize (iterations) 6) prepackaged, doesn't require developers to roll their own (and we all know about letting developers roll their own) many language stacks published test vectors 7) No potential short cycles, at cost of being unable to update iteration count without preimage I'm ignoring the differences between PBKDF2 and bcrypt at the moment, I know it seems to require more memory... scrypt seems to be a better countermeasure for the FPGA threat, though much less widely implemented. Also, what's the status of SHA-3? Is it on horizon? Finally, is PBKDF2-HMAC-SHA1 significantly weaker than PBKDF2-HMAC-SHA512? I couldn't find the latter in JRE and some other stacks. -- http://www.subspacefield.org/~travis/ What are you saying? I'm not saying anything. I didn't say anything then, and I'm not saying anything now. -- Babylon 5 pgpaRS7QVaPsM.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] any reason PBKDF2 shouldn't be used for storing hashed passwords?
One curious note is that NIST recommends PBKDF2 for master key derivation, and specifically write, The MK [PBKDF2 output] shall not be used for other purposes. Perhaps the document was meant to document just KDFs. Since the hashes are one-way anyway, I don't see it making a difference for use as password digests. On Thu, Aug 16, 2012 at 2:15 AM, Jon Callas j...@callas.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 15, 2012, at 4:50 PM, travis+ml-rbcryptography@subspacefield.orgwrote: * PGP Signed by an unknown key Any reason PBKDF2 shouldn't be used for (storing) hashed passwords? My recommendation is that you should use it. It's even got a NIST document, now: http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf To be the most rigorous, use PBKDF2-HMAC-SHA[12]. It doesn't matter a lot which hash function you're using if you're doing the HMAC version. The major difference will be the number of iterations. SHA2 is slower than SHA1, so you'll use fewer iterations. SHA512 is faster on a 64-bit processor than SHA256, which puts a small wrench in things. Use lots of iterations. Calibrate them against real time -- enough for 100ms or more, for example, rather than a fixed count. If you're worried, then add more iterations. Jon -BEGIN PGP SIGNATURE- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFQLDuusTedWZOD3gYRAt0+AKC0jAKZS40IDBdYelX19y5pQ6zS5gCgpYhI dYokIg8zciE7iY5NrXVWkwc= =pSLW -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client-side SRP vs. server-side KDF
On Wed, Aug 15, 2012 at 8:46 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Blizzard Entertainment has been receiving a lot of flak from tech and mass media lately for choosing to employ SRP in their Battle.net clients and games. A lot of these outlets have been suggesting that SRP is weaker than KDFs, and that Blizzard switch out SRP on the client side for a KDF on the server side. That seems to me a very apples-to-oranges comparison (indeed akin to blaming Diffie-Hellman key exchange for the fact that DES is easy to break,) and indeed would only replace one security issue (weak password digests/verifiers on the server) for another (susceptibility to network eaves-dropping.) As far as I know, the SRP authors never made any claim about the verifiers being hardened against dictionary attacks. It seems to me that a strong KDF on the client side, like PBKDF2 or scrypt (optionally with a salt managed by the server,) coupled with a non-reproducible proof of some sort, like SRP, would be the ideal solution, not one or the other. What do you think? On the server side, the salt and hash look exactly like a Unix passwd file. One could easily beef it up in a KDF like fashion, but mobile clients will need to perform the same pre-processing before the real SRP takes effect. One could also cut in a different hash, such as scrypt. In the past, I implemented it twice and only found I needed to increase the size of the server's authentication tag from 32 (or was it 64) bits to something larger (96 or 128 bits). I had mobile clients, so the UI folks would not accept the KDF pre-processing (Windows Phone era, before iPhone was introduced). SRP also cuts out the [useless] third party known as a Public CA. +1 to Thomas Wu and SRP. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Client-side SRP vs. server-side KDF
On Thu, Aug 16, 2012 at 02:46:58AM +0200, Patrick Mylund Nielsen wrote:
Blizzard Entertainment has been receiving a lot of flak from tech and mass
media lately for choosing to employ SRP in their Battle.net clients and
games. A lot of these outlets have been suggesting that SRP is weaker
than KDFs, and that Blizzard switch out SRP on the client side for a KDF on
the server side. That seems to me a very apples-to-oranges comparison
(indeed akin to blaming Diffie-Hellman key exchange for the fact that DES
is easy to break,) and indeed would only replace one security issue (weak
password digests/verifiers on the server) for another (susceptibility to
network eaves-dropping.) As far as I know, the SRP authors never made any
claim about the verifiers being hardened against dictionary attacks.
Indeed. It would be best for Blizzard to add a decent KDF, but continue
using SRP as well.
Meanwhile, this apparent leak of SRP verifiers has resulted in us adding
support to John the Ripper - initially for Blizzard's revision of SRP
based on publicly available information (reverse-engineered by others).
For this one, we're getting speeds of up to about 70k combinations (of
{candidate password, target verifier}) per second per CPU core - that's
using a 64-bit build of GMP (with OpenSSL's modexp code the speeds are
somewhat lower; ditto on 32-bit).
Apparently, Blizzard has since moved away from the 256-bit modulus, so
speeds for more recently changed passwords may be lower.
However, much of this is speculation. We don't actually have access to
the presumably leaked Blizzard SRP verifiers. Has anyone in here
actually seen those? We'd like to verify that our code is actually
working right.
Disclaimer and credit: I did not work on the JtR implementation myself;
JimF did.
Alexander
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] any reason PBKDF2 shouldn't be used for storing hashed passwords?
On Thu, Aug 16, 2012 at 02:25:34AM +0200, Patrick Mylund Nielsen wrote: PBKDF2 is certainly decent, and often the easiest choice if you intend to comply with e.g. FIPS 140-2/ISO 27001, but the biggest argument against it is that it _isn't_ difficult to parallelize, since it is just e.g. HMAC-SHA256. Each guess might require sequential iteration, but you can still compute many guesses simultaneously. Exactly. bcrypt is slightly more computationally expensive On current GPUs, that's a lot, not slightly. GPUs currently deliver CPU-like speeds for bcrypt, but a lot higher speeds for PBKDF2-HMAC-SHA*. (I expect that we'll get faster attacks on bcrypt using general-purpose hardware with AVX2 and Intel MIC, though.) (although its 55-byte input limit is often ignored,) The limit is actually at 72 chars. 55 was an error in the paper. PBKDF2-HMAC-SHA1 significantly weaker than PBKDF2-HMAC-SHA512? SHA-1 is still safe in an HMAC construction, however there's no convincing reason not to use at least PBKDF2-HMAC-SHA256 that I can think of. You don't need it to be fast. Going beyond that won't really give you much security compared to using a memory-hard function. There's a lot of difference between SHA-1 and SHA-512 in terms of friendliness to current GPUs. SHA-512 is a lot less GPU-friendly. SHA-256 is inbetween. This is related to SHA-512 making more complete use of 64-bit CPUs. If you use more of the available resources and do so wisely, then the attacker will similarly have to use more resources. This alone accounts for a 2x difference between SHA-256 and SHA-512 when we consider attackers' GPU implementations. Further difference comes from SHA-512's increased register pressure (on GPU's 32-bit registers). Overall, SHA-256 is 2-3 times slower than SHA-1, and SHA-512 is a further 4-14 times slower than SHA-256 on current GPUs with currently available implementations. SHA-512 is 10 to 30 times slower than SHA-1 on current GPUs with currently available implementations. Still PBKDF2-HMAC-SHA-512 is a lot more susceptible to attacks with current GPUs than bcrypt, let alone scrypt. Alexander ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
