(a) It is not more likely that a developer who can't hash passwords correctly is going to host SRP Javascript securely, not least because you can't host SRP Javascript securely --- but even if you could, doing so would be harder than hashing passwords.
(b) The failure mode for badly hashed passwords is better than the failure mode for an insecure login form.
(c) Most developers already know how to set up an HTTPS login form; most popular apps already host secure login forms (how many do you think hash passwords securely? 10%?). This is a step backwards.
Your proposed solution doesn't solve your complaint of browser security. Even if you use SSL and have a bcrypt hashed database, once someone gets onto the browser they can get at any password typed. It is literally a 1 liner if they have jquery.
That's why I'm saying this doesn't even try to solve the insecurity of the browser, because nothing can. They're just not secure in the face of a moderately determined hacker, period.
You have a good point. You're saying, "if an attacker could hijack Javascript on an already-HTTPS-secured login page, she could steal credentials whether the system used SRP or not".
I don't think this assertion is 100% correct: I think that there are Javascript injections that wouldn't be able to intercept a FORM post or alter the "action" attribute on the form; meanwhile, any Javascript injection can intercept a free function that handles password data. But that's a quibble.
The real point is, with a straight-up HTTPS login, the browser already has security controls that ensure that (say) a secure-looking form isn't being posted to a random site somewhere else on the Internet. Broader point: there are more ways to screw up simply hosting your tool than there are to screw up password hashing.
This is tricky for me. You're working with the most toxic possible combination of technologies (number-theoretic crypto in browser Javascript), but you've come up with a design that only barely relies on any of that crypto. Usually, when people write Javascript crypto, they ignore horrific threat models and then wish away everything bad about browser crypto.
At this point, the worst I can say about what you're doing is "I don't see the value". On the other hand, SRP is a beautiful little algorithm. It's at least fun to talk about.
Yep, programmers will screw this up, and that's where good docs and good easy to use implementations come in.
I also believe there's a market for auditing people's use of services like this. At the point where programmers can screw it up you just can't invent better tech to make them less stupid, so a better approach is to have social elements. Badges saying they're audited, documentation, good examples doing it right, well done APIs, etc.
Comments
(a) It is not more likely that a developer who can't hash passwords correctly is going to host SRP Javascript securely, not least because you can't host SRP Javascript securely --- but even if you could, doing so would be harder than hashing passwords.
(b) The failure mode for badly hashed passwords is better than the failure mode for an insecure login form.
(c) Most developers already know how to set up an HTTPS login form; most popular apps already host secure login forms (how many do you think hash passwords securely? 10%?). This is a step backwards.
Your proposed solution doesn't solve your complaint of browser security. Even if you use SSL and have a bcrypt hashed database, once someone gets onto the browser they can get at any password typed. It is literally a 1 liner if they have jquery.
That's why I'm saying this doesn't even try to solve the insecurity of the browser, because nothing can. They're just not secure in the face of a moderately determined hacker, period.
You have a good point. You're saying, "if an attacker could hijack Javascript on an already-HTTPS-secured login page, she could steal credentials whether the system used SRP or not".
I don't think this assertion is 100% correct: I think that there are Javascript injections that wouldn't be able to intercept a FORM post or alter the "action" attribute on the form; meanwhile, any Javascript injection can intercept a free function that handles password data. But that's a quibble.
The real point is, with a straight-up HTTPS login, the browser already has security controls that ensure that (say) a secure-looking form isn't being posted to a random site somewhere else on the Internet. Broader point: there are more ways to screw up simply hosting your tool than there are to screw up password hashing.
This is tricky for me. You're working with the most toxic possible combination of technologies (number-theoretic crypto in browser Javascript), but you've come up with a design that only barely relies on any of that crypto. Usually, when people write Javascript crypto, they ignore horrific threat models and then wish away everything bad about browser crypto.
At this point, the worst I can say about what you're doing is "I don't see the value". On the other hand, SRP is a beautiful little algorithm. It's at least fun to talk about.
Yep, programmers will screw this up, and that's where good docs and good easy to use implementations come in.
I also believe there's a market for auditing people's use of services like this. At the point where programmers can screw it up you just can't invent better tech to make them less stupid, so a better approach is to have social elements. Badges saying they're audited, documentation, good examples doing it right, well done APIs, etc.