3 ms·

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. Ther

by 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.
    - dchest 12y ago
      I agree with you that browsers help can improve security, in general. (Mozilla tried this with BrowserID/Persona, but failed.) As for your second point, I still don't understand it :-) It's hard to make something usable without trusting servers in the current browser environment, even if browser vendors cooperate.
      - nly 12y ago
        > It's hard to make something usable without trusting servers in the current browser environment, even if browser vendors cooperate. That's why the solution needs to be built in to web standards like HTTP 2.x and HTML, rather than shimmed in to a javascript library. The original HTTP authentication scheme actually did one thing right, and that was bypassing HTML and Javascript (where any hope of security and privacy is long dead and buried) and going straight to the browser UI.

by dchest 12y ago

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.
  - dchest 12y ago
    I agree with you that browsers help can improve security, in general. (Mozilla tried this with BrowserID/Persona, but failed.) As for your second point, I still don't understand it :-) It's hard to make something usable without trusting servers in the current browser environment, even if browser vendors cooperate.
    - nly 12y ago
      > It's hard to make something usable without trusting servers in the current browser environment, even if browser vendors cooperate. That's why the solution needs to be built in to web standards like HTTP 2.x and HTML, rather than shimmed in to a javascript library. The original HTTP authentication scheme actually did one thing right, and that was bypassing HTML and Javascript (where any hope of security and privacy is long dead and buried) and going straight to the browser UI.