On 2013-09-30, at 10:43 AM, Adam Back <a...@cypherspace.org> wrote: > On Mon, Sep 30, 2013 at 02:34:27PM +0100, Wasa wrote: >> On 30/09/13 10:47, Adam Back wrote: >>> PBKDF2 + current GPU or ASIC farms = game over for passwords. >> >> what about stronger pwd-based key exchange like SRP and JPAKE?
Well SRP most certainly isn’t a solution to this problem. With SRP requires a shared secret key, so the attacker doesn’t even need to “crack a hash” after getting hold of a server’s password database. I don’t know enough about JPAKE to comment. Of course SRP can be used in a way to ensure that the shared secret is never reused among services, but I don’t actually know how SRP is used in practice. > of even more concern an attacker who steals the whole > database of user verifiers from the server can grind passwords against it. > There is a new such server hashed password db attack disclosed or hushed up > every few weeks. They are far more common than that. See http://blog.passwordresearch.com/2013/01/passwords-found-in-wild-for-december.html Undiscovered breaches are probably much more common than hushed up breaches, which in turn are more common that disclosed breaches. > You know GPUs are pretty good at computing scrypt. I’ve been told by those who develop password cracking tools that (current) GPUs have a hard time with SHA512. So for the moment anyway, something like PBKDF2-HMAC-SHA512 should bring down the attacker-defender ratio. But this is hardly a long term solution and is focused on the specific architectures that exist today. However, it is what I am advocating as a temporary measure until we have something usable out of the Password Hashing Competition. The PHC is intended to find (spur the development of) a successor to PBKDF2 and scrypt. https://password-hashing.net > But there is a caveat which is the client/server imbalance is related to the > difference in CPU power between mobile devices and server GPU or ASIC farms. Yep. I work for a company that produces password manager that is used on mobile devices. The attacker will have much more to bring to the fight. All we can do is try to make the best use of the 500ms we think our users will put up with for key derivation. At the moment, that's PBKDF2-HMAC-SHA512 with the number of iterations initially calibrated to 500ms on the device where the data was created. But we are stuck with this asymmetry between attacker and defender, and have to design with it very much in mind. > Anyway and all that because we are seemingly alergic to using client side > keys which kill the password problem dead. I’m hardly allergic to that. Back in the 90s, I thought that this really would solve the password problem. I worked briefly on trying to initiate a project to develop a scheme where UK universities would sign client certs for members of the university. But, among other things, X.509 is a bitch. So I'm not so much allergic as pessimistic. For a long time I thought the password problem would be solved within the next few years. I’ve long seen client keys as the solution of the future. My fear is that it will remain the solution of the future. (Of course, given the business I’m in, my pessimism may be self-serving.) (Sure, a solution to the password problem would eliminate the need for the product that contributes to my livelihood, so maybe my pessimism is self-interested. But back when a chunk of my income was from fighting spam; I longed for the day I there would be no need for those services.) > For people with smart phones to > hand all the time eg something like oneid.com (*) ...(*) disclaimer I > designed the crypto as a consultant to oneid. Cool. I will take a look. And even in my pessimism, I don’t see passwords (even with great password management tools) sticking around forever. It’s just that I’ve learned over time that, like unencrypted email, they have a disturbing staying power. Cheers, -j
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
