3 ms·

There is no usable secure password authentication standard that will protect from password compromise after password database leak. In fact, if you're talking a

by dchest 12y ago

There is no usable secure password authentication standard that will protect from password compromise after password database leak. In fact, if you're talking about SRP, it's worse in this regard compared to, say, using bcrypt.

nly 12y ago
SRP as published in RFC2945 (circa 2000), which uses SHA-1, is worse. The protocol and general idea is a lot better, and can be adapted to use any hash function you like. Replacing RSA with EC is also trivial. Half a day and a room full of cryptographers and browser guys and you could RFC these changes. Given more time, I have no doubt that they could come up with something entirely new and web-centric. We have a standards body responsible for stewarding the web, and a handful of some very smart and well resourced browser vendors who can solve these problems. Ultimately these guys have to take this burden eventually, and these people write web standards... not having a standard yet just isn't an excuse. Why aren't they doing so? Is it because they're more interested in pushing their own platforms and authentication solutions (hint: all 3rd party authentication is horrific). It's not like Google, to pick one, is shy when it comes to developing their own protocols. And it's not just protocols... why don't browsers come with cracklib style hints regarding password strength yet? Why no builtin password generation to go with the existing password storage? So many things not being done because it's easier to blame the next company when their database is compromised than cooperating to solve hard technological and UI failings.
- dchest 12y ago
  Again, SRP is useless against password database leaks. Even if it's used with scrypt instead of SHA-1, and ECC instead of RSA, it's no better than scrypt. There is no standard not because nobody invented it, but because it's impossible in principle (unless we replace passwords with something else).
  - nly 12y ago
    SRP does offer reassurance when databases are compromised. If my browser supported SRP-EC-Scrypt, and users were guided on password strength by their browsers UI, then there would be negligible public concern regarding 'encrypted passwords' being leaked, or worry about whether eBay or HN is using MD5 or leaking HTTP POST requests somewhere. Not to mention SRP verifiers are public keys. Password derived pubkeys like those in SRP can be used to securely encrypt other sensitive user data while still allowing users to decrypt and maintain those records interactively. A good solution isn't "impossible in principle", we just need a full-stack solution extending from browser UI all the way to your favourite CRUD webapps database. Most of that complexity falls to the browser vendors, web application frameworks and languages would jump all over it once there was a client-side consensus. We need to change our trust models. I trust eBay as an organisation to offer me a service. I don't trust the web stack or their servers.
    - dchest 12y ago
      It's true that if your browser and websites supported SRP-EC-Scrypt, you would know that they stored things "securely". However, this won't solve the problem of people using weak passwords and people using the same password for different websites. If you use strong passwords and don't reuse them, you already know your risks. As for your second point, I don't understand it. Do you mean, with the help of SRP, you can store some sensitive data on server, which won't be available to this server, but will be available to user? What's the use of it? This sounds strangely similar to this idea: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 > We need to change our trust models. I trust eBay as an organisation to offer me a service. I don't trust the web stack or their servers. Then passwords don't matter, because you assume that attackers already can do everything with your eBay account.
      - nly 12y ago
        > If you use strong passwords and don't reuse them, you already know your risks. Nobody does this. Geeks who use password management are are an extreme minority, and solutions like LastPass are crock that solve the same problem by papering over infrastructural failings and mean users are never completely free to move. Anecdotally I believe people typically use a 'good password' for banking etc, and a handful of lazy passwords. Cryptographically speaking, they're all weak of course, but imho people are better off with knowing one or two really good passwords (I used a 12 character mixed case password containing symbols entirely from QWERTY induced muscle memory) and letting their browser deal with derivation for different endpoints. > Do you mean, with the help of SRP, you can store some sensitive data on server, which won't be available to this server, but will be available to user? Not SRP specifically. Forget SRP. What I mean is generally that any user public key (whether it was originally derived from a user secret like a password or not) can be used by an organisation for online encryption and authentication and offline decryption, where data can be decrypted by either the organisation using their private key, or by the user using their password.

by dchest 12y ago

nly 12y ago

SRP as published in RFC2945 (circa 2000), which uses SHA-1, is worse. The protocol and general idea is a lot better, and can be adapted to use any hash function you like. Replacing RSA with EC is also trivial. Half a day and a room full of cryptographers and browser guys and you could RFC these changes. Given more time, I have no doubt that they could come up with something entirely new and web-centric. We have a standards body responsible for stewarding the web, and a handful of some very smart and well resourced browser vendors who can solve these problems. Ultimately these guys have to take this burden eventually, and these people write web standards... not having a standard yet just isn't an excuse. Why aren't they doing so? Is it because they're more interested in pushing their own platforms and authentication solutions (hint: all 3rd party authentication is horrific). It's not like Google, to pick one, is shy when it comes to developing their own protocols. And it's not just protocols... why don't browsers come with cracklib style hints regarding password strength yet? Why no builtin password generation to go with the existing password storage? So many things not being done because it's easier to blame the next company when their database is compromised than cooperating to solve hard technological and UI failings.

dchest 12y ago
Again, SRP is useless against password database leaks. Even if it's used with scrypt instead of SHA-1, and ECC instead of RSA, it's no better than scrypt. There is no standard not because nobody invented it, but because it's impossible in principle (unless we replace passwords with something else).
- nly 12y ago
  SRP does offer reassurance when databases are compromised. If my browser supported SRP-EC-Scrypt, and users were guided on password strength by their browsers UI, then there would be negligible public concern regarding 'encrypted passwords' being leaked, or worry about whether eBay or HN is using MD5 or leaking HTTP POST requests somewhere. Not to mention SRP verifiers are public keys. Password derived pubkeys like those in SRP can be used to securely encrypt other sensitive user data while still allowing users to decrypt and maintain those records interactively. A good solution isn't "impossible in principle", we just need a full-stack solution extending from browser UI all the way to your favourite CRUD webapps database. Most of that complexity falls to the browser vendors, web application frameworks and languages would jump all over it once there was a client-side consensus. We need to change our trust models. I trust eBay as an organisation to offer me a service. I don't trust the web stack or their servers.
  - dchest 12y ago
    It's true that if your browser and websites supported SRP-EC-Scrypt, you would know that they stored things "securely". However, this won't solve the problem of people using weak passwords and people using the same password for different websites. If you use strong passwords and don't reuse them, you already know your risks. As for your second point, I don't understand it. Do you mean, with the help of SRP, you can store some sensitive data on server, which won't be available to this server, but will be available to user? What's the use of it? This sounds strangely similar to this idea: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721 > We need to change our trust models. I trust eBay as an organisation to offer me a service. I don't trust the web stack or their servers. Then passwords don't matter, because you assume that attackers already can do everything with your eBay account.
    - nly 12y ago
      > If you use strong passwords and don't reuse them, you already know your risks. Nobody does this. Geeks who use password management are are an extreme minority, and solutions like LastPass are crock that solve the same problem by papering over infrastructural failings and mean users are never completely free to move. Anecdotally I believe people typically use a 'good password' for banking etc, and a handful of lazy passwords. Cryptographically speaking, they're all weak of course, but imho people are better off with knowing one or two really good passwords (I used a 12 character mixed case password containing symbols entirely from QWERTY induced muscle memory) and letting their browser deal with derivation for different endpoints. > Do you mean, with the help of SRP, you can store some sensitive data on server, which won't be available to this server, but will be available to user? Not SRP specifically. Forget SRP. What I mean is generally that any user public key (whether it was originally derived from a user secret like a password or not) can be used by an organisation for online encryption and authentication and offline decryption, where data can be decrypted by either the organisation using their private key, or by the user using their password.