3 ms·

> Ask me which I'd trust more: a website that stores passwords using whatever hash a PHP developer came up with, or a website that implemented some kind of PAKE

> Ask me which I'd trust more: a website that stores passwords using whatever hash a PHP developer came up with, or a website that implemented some kind of PAKE, like SRP, to authenticate passwords. If you're asking that question you don't understand the purpose of SRP or ZKPP. If you're giving a password you use elsewhere to a website, you're trusting them with your private data, and you shouldn't. As developers it's our jobs to prevent users from making this mistake if we can. When using SRP or another ZKPP scheme, trust doesn't enter the equation. You aren't giving the server your password, you're giving them a piece of data which is verifiably difficult to reverse to obtain your password, so you don't need to trust them to store it properly. > What's especially ironic about your comment is that password-authenticated key exchanges still require servers to store authenticators which can be attacked offline. This isn't ironic: this is exactly what I would expect from kerkelsager's comment. Again you're just showing your ignorance. Yes, you can attack an authenticator. The point of ZKPP is that it allows the client to verify that such an attack is computationally difficult. If you've given the server your password in plain text (or reversibly encrypted form), you can no longer verify that obtaining the password from the authenticator is computationally difficult. For all you know, the server stores your password in plain text. This isn't a theoretical problem: there are numerous examples of this happening. > PAKEs actually make the problem we're talking about harder, not easier, because the authenticator format has to be compatible with the protocol. If you're objecting to implementing things correctly because it's hard, software might not be the right career for you.

tptacek 12y ago
It's always possible that I just don't know how SRP works, I suppose. Or: it's possible that I'm right, and that using a PAKE to handle simple logins to web and mobile applications is a really bad idea that doesn't make any of the problems we're talking about on this thread easier.
- copsarebastards 12y ago
  SRP solves a problem that password hashing doesn't solve. Obviously SRP is harder to implement than password hashing. If you're still talking about which is "easier" you're still missing the point of SRP (and ZKPP).
  - tptacek 12y ago
    You're missing me. SRP doesn't solve the password storage problem --- its authenticators are crackable --- and introduces new ones. SRP does not address the problem we're talking about on this thread. We don't have password storage problems simply because applications don't use "ZKPPs" and PAKEs.
    - copsarebastards 12y ago
      There is no good solution to the "password storage problem", as you call it. The fundamental issue is that "storing passwords securely" is the wrong problem to solve. Think from the perspective of a non-technical user. You're lazy, so you want to use a short password that's easy to remember, and you want to use it on every website. Now think from the perspective of a software engineer. Your non-technical users will use short passwords that are easy to remember and therefore easy to break. And they will use that password on every website. So no matter how you store your user's passwords, some idiot server administrator somewhere will store those same passwords in plain text, and they'll get hacked, and the hackers will have access to your user's passwords. So the problem isn't "how do I store passwords securely", it's "how do I prevent my users from giving their passwords to an idiot server administrator who won't store them securely". And as a technical user, I also have this problem, which is "how do I know if my server administrator is an idiot and is storing my passwords in plain text?" The solution to this is to use different high-entropy passwords on different sites, but this is tedious. If ZKPP (zero-knowledge password proof) is widely adopted and supported in browsers, it solves both the server administrator's problem and the technical user's problem: 1. It stops idiot server administrators from storing passwords in plain text. The "zero knowledge" part of ZKPP means that users never give server administrators their password or any knowledge about their password, so administrators can't store the password stupidly. 2. As a technical user, I can now use the same password on multiple sites, provided a) my password is significantly entropic and b) all those sites use a ZKPP scheme. Since I never give the password to any site, I don't have to worry that one of them will store my password stupidly. My browser does the job of providing different authenticators to different sites, so breaking one authenticator doesn't break all of them. 3. A non-technical user with a low-entropy password on multiple still runs the risk that their password will be broken one one site, breaking it for all sites. However, the non-technical user is still better off because a) their password is at least properly hashed on all sites, rather than being stored in plain text, which will make an attack more costly, and b) caching password hashes amortizes the performance hit of password hashing, so we can afford to use more secure hashes, which again makes an attack more costly. NOTE: I don't know the details of SRP well enough to know whether all these benefits apply. I do know that SRP claims to provide a ZKPP, so I'll tentatively lump it in with ZKPPs, but I haven't actually verified the algorithm personally so I can't speak to its security.

tptacek 12y ago

It's always possible that I just don't know how SRP works, I suppose. Or: it's possible that I'm right, and that using a PAKE to handle simple logins to web and mobile applications is a really bad idea that doesn't make any of the problems we're talking about on this thread easier.

copsarebastards 12y ago
SRP solves a problem that password hashing doesn't solve. Obviously SRP is harder to implement than password hashing. If you're still talking about which is "easier" you're still missing the point of SRP (and ZKPP).
- tptacek 12y ago
  You're missing me. SRP doesn't solve the password storage problem --- its authenticators are crackable --- and introduces new ones. SRP does not address the problem we're talking about on this thread. We don't have password storage problems simply because applications don't use "ZKPPs" and PAKEs.
  - copsarebastards 12y ago
    There is no good solution to the "password storage problem", as you call it. The fundamental issue is that "storing passwords securely" is the wrong problem to solve. Think from the perspective of a non-technical user. You're lazy, so you want to use a short password that's easy to remember, and you want to use it on every website. Now think from the perspective of a software engineer. Your non-technical users will use short passwords that are easy to remember and therefore easy to break. And they will use that password on every website. So no matter how you store your user's passwords, some idiot server administrator somewhere will store those same passwords in plain text, and they'll get hacked, and the hackers will have access to your user's passwords. So the problem isn't "how do I store passwords securely", it's "how do I prevent my users from giving their passwords to an idiot server administrator who won't store them securely". And as a technical user, I also have this problem, which is "how do I know if my server administrator is an idiot and is storing my passwords in plain text?" The solution to this is to use different high-entropy passwords on different sites, but this is tedious. If ZKPP (zero-knowledge password proof) is widely adopted and supported in browsers, it solves both the server administrator's problem and the technical user's problem: 1. It stops idiot server administrators from storing passwords in plain text. The "zero knowledge" part of ZKPP means that users never give server administrators their password or any knowledge about their password, so administrators can't store the password stupidly. 2. As a technical user, I can now use the same password on multiple sites, provided a) my password is significantly entropic and b) all those sites use a ZKPP scheme. Since I never give the password to any site, I don't have to worry that one of them will store my password stupidly. My browser does the job of providing different authenticators to different sites, so breaking one authenticator doesn't break all of them. 3. A non-technical user with a low-entropy password on multiple still runs the risk that their password will be broken one one site, breaking it for all sites. However, the non-technical user is still better off because a) their password is at least properly hashed on all sites, rather than being stored in plain text, which will make an attack more costly, and b) caching password hashes amortizes the performance hit of password hashing, so we can afford to use more secure hashes, which again makes an attack more costly. NOTE: I don't know the details of SRP well enough to know whether all these benefits apply. I do know that SRP claims to provide a ZKPP, so I'll tentatively lump it in with ZKPPs, but I haven't actually verified the algorithm personally so I can't speak to its security.