I agree that this is strictly worse than a competently-implemented HTTPS login form on the server where people want to log in (the "webapp").
But ever notice how many times you've told people on HN not to use MD5/SHA1 for passwords? And those are the clueful ones - the idiots will store plaintext passwords and get their database compromised by the first attacker who's heard of SQL injection.
If everyone copy-pasted some Javascript from Zed (not a crypto/security guru, but at least a competent coder), it would be a significant improvement. Sure, it's not perfect, and the centralization of login credentials is not a good thing security-wise, but many people reuse passwords anyway, and it's not like OAuth and the like is any better. Authentication-as-a-service is, I think, likely to be a net win. [EDIT: So I do see the value here.]
Zed's implementation, Javascript crypto and all, even has the (potential - didn't check the code) advantage that the webapp servers don't need to trust the authentication server, provided they host the Javascript. I'm not convinced that this is enough justification for doing crypto in Javascript, but it's not the usual "host-proof" idiocy.
(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
I agree that this is strictly worse than a competently-implemented HTTPS login form on the server where people want to log in (the "webapp").
But ever notice how many times you've told people on HN not to use MD5/SHA1 for passwords? And those are the clueful ones - the idiots will store plaintext passwords and get their database compromised by the first attacker who's heard of SQL injection.
If everyone copy-pasted some Javascript from Zed (not a crypto/security guru, but at least a competent coder), it would be a significant improvement. Sure, it's not perfect, and the centralization of login credentials is not a good thing security-wise, but many people reuse passwords anyway, and it's not like OAuth and the like is any better. Authentication-as-a-service is, I think, likely to be a net win. [EDIT: So I do see the value here.]
Zed's implementation, Javascript crypto and all, even has the (potential - didn't check the code) advantage that the webapp servers don't need to trust the authentication server, provided they host the Javascript. I'm not convinced that this is enough justification for doing crypto in Javascript, but it's not the usual "host-proof" idiocy.
(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.