3 ms·

> using salted SHA1 for password hashing Anything else would be better there. But right now there is a huge multiplicity of trendy password strengthening func

by 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?
- nullc 12y ago
  > Yeah, I can't fathom how that spec got drafted with SHA1. I'm not sure, PBKDF2 existed then... though computationally expensive KDFs for passwords have become more popular over time. And grinding the server for SRP isn't totally cheap. > How's that going? Is there anything amongst the PHC candidates looking like it'll 'win'? It's gone very silent. Been pretty silent from what I've seen but the schedule gave a fair amount of time for review... though I'm not sure how much review various proposals are getting, since this is a domain with basically infinite shed-painting potential (as my own comments here go!), makes it almost feel pointless to review. > Afaict this probably isn't too much of a problem for a client-server PAKE? I'm not sure. It would be an unfortunate result if you sought out to make it more secure, and maybe its less secure. (E.g. server database never leaks, but lots of opportunities for timing attacks show up) > 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. 10,000 probably isn't needed though, since extracting a few bits may let you reasonably grind out the rest against the server only; if you make pessimal (read: reasonable) assumptions about how much entropy users actually have in their passwords. Consider an attack where the attacker code is running in the background (say in another browser tab/nacl) performing cache timing while the user logs it. It's a sophisticated attack, but it could potentially extract quite a few bits. It may be a somewhat complex attack, but a simple conventional hash PKKDF2 would be invulnerable to it. Yea, I don't see any concern on the server. Server's commitment shouldn't be using an intentionally expensive hash, and normal cryptographic hashes in wide use are constant time. > Hmm, interesting. Any information on this? Will look when awake. But the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash.
  - nly 12y ago
    > the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash. Ah, a partition attack. Could you fix this with more ugly by just iterating the hashing/munging process until your commitment was in a predetermined subgroup? I'm not at all familiar with EC subgroup theory, but the EC-SRP scheme proposed already does some deterministic munging to select the y-coordinate. Of course, even if you can do this, you're open to another timing side-channel.

by nullc 12y ago

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?

nullc 12y ago
> Yeah, I can't fathom how that spec got drafted with SHA1. I'm not sure, PBKDF2 existed then... though computationally expensive KDFs for passwords have become more popular over time. And grinding the server for SRP isn't totally cheap. > How's that going? Is there anything amongst the PHC candidates looking like it'll 'win'? It's gone very silent. Been pretty silent from what I've seen but the schedule gave a fair amount of time for review... though I'm not sure how much review various proposals are getting, since this is a domain with basically infinite shed-painting potential (as my own comments here go!), makes it almost feel pointless to review. > Afaict this probably isn't too much of a problem for a client-server PAKE? I'm not sure. It would be an unfortunate result if you sought out to make it more secure, and maybe its less secure. (E.g. server database never leaks, but lots of opportunities for timing attacks show up) > 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. 10,000 probably isn't needed though, since extracting a few bits may let you reasonably grind out the rest against the server only; if you make pessimal (read: reasonable) assumptions about how much entropy users actually have in their passwords. Consider an attack where the attacker code is running in the background (say in another browser tab/nacl) performing cache timing while the user logs it. It's a sophisticated attack, but it could potentially extract quite a few bits. It may be a somewhat complex attack, but a simple conventional hash PKKDF2 would be invulnerable to it. Yea, I don't see any concern on the server. Server's commitment shouldn't be using an intentionally expensive hash, and normal cryptographic hashes in wide use are constant time. > Hmm, interesting. Any information on this? Will look when awake. But the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash.
- nly 12y ago
  > the result was something like checking which subgroup a point was in leaking log2(cofactor) bits about the secret. The normal way of avoiding this by multiplying all your values by the cofactor isn't readily available when you're doing some ugly trick of constructing points with no known discrete log from a hash. Ah, a partition attack. Could you fix this with more ugly by just iterating the hashing/munging process until your commitment was in a predetermined subgroup? I'm not at all familiar with EC subgroup theory, but the EC-SRP scheme proposed already does some deterministic munging to select the y-coordinate. Of course, even if you can do this, you're open to another timing side-channel.