3 ms·

> In the next post I'll talk about some of those ...[snip]... I'll also talk about why I dislike SRP so much. I'm going to guess this is going to be: * Rocky

by nly 12y ago

> In the next post I'll talk about some of those ...[snip]... I'll also talk about why I dislike SRP so much. I'm going to guess this is going to be: * Rocky development process (~6 versions, removing attack vectors with each release). This however isn't exclusive to SRP: EKE flavours have also suffered from problems[0] * Outdated constructs (e.g. the RFC for TLS-SRP still recommends using salted SHA1 for password hashing, so realistically still relies upon strong database security. Fortunately, this is under client control regardless of what the document actually says) * Lack of a formal security proof (although it's generalised and dealt with in quite a few papers alongside other protocols). * Perhaps the lack of an EC formation, although I believe you can build one with a few modifications. (Yongge Wang drafted one in 2001[5] that looks to me, as an amateur, to be sound. The critical modification is no more crazy than the freaky ECDSA construct we rely upon today, afaict, simply because more elegant Schnorr constructs were covered by patents) I'm not sure why Matt considers the protocol to be complex[1] or crazy[2]. It seems to be a pretty straightforward DH protocol, with a couple of interesting parameters: a commitment by each party to the password verifier, each closing off a different attack (one where a client could otherwise auth knowing just the verifier but not the password, and the other to prevent an impersonating server from gleaning enough to do an offline dictionary attack) There are a lot of subtleties in all off the PAKEy protocols I've read about, not just SRP, one good example can be had here[3], which talks about the intricacies of picking commitment constructs. Atm I agree with Bram Cohens sentiment on this one[4]. If not SRP, then something. I'm looking forward to Matts thoughts in the follow-up. Perhaps he has a more modern starting point in mind[6] I'd like to see the prevalence of full-on PGP-esque signing and HSMs in every device, but we can't continue to do nothing with passwords. The two uses of password authentication that everyday people rely on the most: password authentication on the web, and WPA2-PSK, are both terrible compared to the PAKEs we already have. Worse, the lack of better things is spawning absolute garbage like third-party login. I like SRP. While I'm not as familiar with more current IETF RFCs, like Dragonfly[7] and Pwd[8], I believe from cursory looks that they fail to fall in to the "augmented" PAKE category, which means if a server is compromised the infiltrator can use the knowledge they've gained from the database immediately, and without any further work. [0] http://www.jablon.org/jab97.pdf http://www.jablon.org/jab97.pdf [1] https://twitter.com/matthew_d_green/status/288743176825622529 https://twitter.com/matthew_d_green/status/28874317682562252... [2] https://twitter.com/matthew_d_green/status/288741651357245440 https://twitter.com/matthew_d_green/status/28874165135724544... [3] http://coitweb.uncc.edu/~yonwang/papers/TCSsrp5.pdf http://coitweb.uncc.edu/~yonwang/papers/TCSsrp5.pdf [4] https://twitter.com/bramcohen/status/330423520062476288 https://twitter.com/bramcohen/status/330423520062476288 [5] http://grouper.ieee.org/groups/1363/passwdPK/submissions/p1363ecsrp.pdf http://grouper.ieee.org/groups/1363/passwdPK/submissions/p13... [6] https://twitter.com/matthew_d_green/status/344831693586321409 https://twitter.com/matthew_d_green/status/34483169358632140... [7] https://datatracker.ietf.org/doc/draft-irtf-cfrg-dragonfly/?include_text=1 https://datatracker.ietf.org/doc/draft-irtf-cfrg-dragonfly/?... [8] https://tools.ietf.org/html/draft-harkins-tls-pwd-03 https://tools.ietf.org/html/draft-harkins-tls-pwd-03

nullc 12y ago
> using salted SHA1 for password hashing Anything else would be better there. But right now there is a huge multiplicity of trendy password strengthening functions (see also: https://password-hashing.net/ https://password-hashing.net/). I'd worry that doing something better than sha1 might still not be great because of a lack of clarity of choices there. E.g. Some of the most popular (e.g. scrypt) are potentially ill-advised for some fairly overt reasons, like data-dependent timing that potentially leaks information about your password (in what should other wise be a ZKP thats potentially pretty bad!), or potentially problematic in subtle ways. (E.g. is memory hardness really desirable? the cost analysis ignore operating costs. But for compute bound silicon on 28nm built in quantity, power costs more than die area after only a couple months of operation. Requiring lots of upfront costs in gate area means that attackers can amortize their costs over many attacks. Meanwhile, most of the user's computer is siting idle and not contributing to expanding the amount of work an attacker must do. > * Perhaps the lack of an EC formation, Yea, well ... SRP sends a fair amount of data and isn't terribly fast for reasonably secure parameters. If someone is unconvinced about the value of this crypto-security-whatever having them send kilobytes of data over the regular password they were going to send may be the straw the breaks the camels back. Also, if your cryptographic stack is otherwise all ECC having to have a separate bignum implementation for SRP wouldn't be very welcome. But OTOH, the latest in trend curve design uses curves with non-prime order, and at least some of the PAKE schemes I've seen lose their ZK property when there is a cofactor. Bleh.
- nly 12y ago
  > Anything else would be better there. Yeah, I can't fathom how that spec got drafted with SHA1. I guess as network guys they just didn't care too much about verifier storage, which is insane, because it's clearly the weakest point of any password based scheme where boxes are, in all practicality, going to be off-the-shelf hardware sat on the open Internet. I think the other proposals like Dragonfly and TLS-PWD repeat this mistake also except, not being "augmented", they're even worse. > right now there is a huge multiplicity of trendy password strengthening functions How's that going? Is there anything amongst the PHC candidates looking like it'll 'win'? It's gone very silent. > Some of the most popular (e.g. scrypt) are potentially ill-advised for some fairly overt reasons, like data-dependent timing that potentially leaks information about your password Afaict this probably isn't too much of a problem for a client-server PAKE? The password is only hashed on the client/users, probably somewhat noisy and unique, machine. You're already talking about pretty sophisticated and targeted attack that's hard to pull off on a repeated basis. I know that's not a "sound" crypto argument, but you can't easily make a user enter their password 10,000 times for example. The server will probably need to apply a regular hash the password verifier for commitment purposes, but it's typically mixed in with session nonces, and already hardened, so couldn't be any worse than a db dump from SQL injection even if successful. I personally don't see a hole that doesn't exist with current server-side hashing practices. Thoughts? > some of the PAKE schemes I've seen lose their ZK property when there is a cofactor Hmm, interesting. Any information on this?

by nly 12y ago

nullc 12y ago

> using salted SHA1 for password hashing Anything else would be better there. But right now there is a huge multiplicity of trendy password strengthening functions (see also: https://password-hashing.net/ https://password-hashing.net/). I'd worry that doing something better than sha1 might still not be great because of a lack of clarity of choices there. E.g. Some of the most popular (e.g. scrypt) are potentially ill-advised for some fairly overt reasons, like data-dependent timing that potentially leaks information about your password (in what should other wise be a ZKP thats potentially pretty bad!), or potentially problematic in subtle ways. (E.g. is memory hardness really desirable? the cost analysis ignore operating costs. But for compute bound silicon on 28nm built in quantity, power costs more than die area after only a couple months of operation. Requiring lots of upfront costs in gate area means that attackers can amortize their costs over many attacks. Meanwhile, most of the user's computer is siting idle and not contributing to expanding the amount of work an attacker must do. > * Perhaps the lack of an EC formation, Yea, well ... SRP sends a fair amount of data and isn't terribly fast for reasonably secure parameters. If someone is unconvinced about the value of this crypto-security-whatever having them send kilobytes of data over the regular password they were going to send may be the straw the breaks the camels back. Also, if your cryptographic stack is otherwise all ECC having to have a separate bignum implementation for SRP wouldn't be very welcome. But OTOH, the latest in trend curve design uses curves with non-prime order, and at least some of the PAKE schemes I've seen lose their ZK property when there is a cofactor. Bleh.

nly 12y ago
> Anything else would be better there. Yeah, I can't fathom how that spec got drafted with SHA1. I guess as network guys they just didn't care too much about verifier storage, which is insane, because it's clearly the weakest point of any password based scheme where boxes are, in all practicality, going to be off-the-shelf hardware sat on the open Internet. I think the other proposals like Dragonfly and TLS-PWD repeat this mistake also except, not being "augmented", they're even worse. > right now there is a huge multiplicity of trendy password strengthening functions How's that going? Is there anything amongst the PHC candidates looking like it'll 'win'? It's gone very silent. > Some of the most popular (e.g. scrypt) are potentially ill-advised for some fairly overt reasons, like data-dependent timing that potentially leaks information about your password Afaict this probably isn't too much of a problem for a client-server PAKE? The password is only hashed on the client/users, probably somewhat noisy and unique, machine. You're already talking about pretty sophisticated and targeted attack that's hard to pull off on a repeated basis. I know that's not a "sound" crypto argument, but you can't easily make a user enter their password 10,000 times for example. The server will probably need to apply a regular hash the password verifier for commitment purposes, but it's typically mixed in with session nonces, and already hardened, so couldn't be any worse than a db dump from SQL injection even if successful. I personally don't see a hole that doesn't exist with current server-side hashing practices. Thoughts? > some of the PAKE schemes I've seen lose their ZK property when there is a cofactor Hmm, interesting. Any information on this?