With a normal SRP implementation, I'd ask questions like "why aren't you checking B mod N" (you're using Wu's libs so thankfully you're not automatically boned on the server) and "why don't you hardcode N and g so you don't have to check them for safety every time you run the protocol". That's presumably the kind of feedback you're looking for.
But that's all kind a moot point because you're delivering this over Javascript. Making sure g doesn't generate a tiny subgroup, or that N isn't (say) 2 is past the point, because how can a client trust any of this?
You're not delivering the Javascript over HTTPS, but that'd be a fig leaf anyways, because the idea is to embed this in other people's websites. Every one of those those sites would need to load this script on a page that is (a) itself HTTPS, (b) with every page component also delivered over HTTPS, (c) referencing no active content from the site that could have been loaded and cached previously without HTTPS, (d) absolutely free of cross-site scripting flaws. Otherwise, the attacker you are considering when using SRP can trivially snarf users passwords.
Javascript cryptography sucks. SJCL is a very nice library, and it might even be useful in a setting like Node.js, but it does nothing to make content-controlled code a safe place to do crypto.
This system is, right now, strictly worse than an HTTPS login prompt that simply sends a username and password. I don't understand your idea well enough to say whether it can be better than asymptotically as good as that same HTTPS login system.
I get it, by the way. The idea is just "make it easier for sites that are scared by Coda Hale's blog post to implement better - than - Gawker authentication". But even stipulating that all of this scheme can be made to work securely (I don't think it can): this is an awful lot of moving parts for an awfully small value proposition.
Wow, longer than a single line comment. I'm impressed. :-)
I agree totally on all your points, and this still needs work, as I said.
But that age old boogeyman from the 90's of "javascript cryptography is flawed" has to go. It works just fine, and most of the complaints people have you can leverage against any language. Sure, it blows, but the SJCL has really good solutions to many of the encoding issues. After that it's pretty much just as lame as most languages.
Also, your attacks are valid on all existing sites, and I'm not claiming it solves any of those. If an attacker can get to the browser, then you're screwed always. I am not even trying to claim this solves any attack in the browser, and in fact I'm saying that all websites are vulnerable no matter what people use. Even with OpenID I can use evil UI tricks to get your password.
What this is solving is only the problem of people not wanting to setup their own auth system and get it right. It doesn't stop a determined evil web site from abusing it, because no solution would. It doesn't stop an idiot from using it wrong, because no solution would. It just helps them not store passwords, and that's it.
I know that serving up ribeyes carved off sacred cows is your schtick and all, but on this issue you're just wrong. Browser javascript is the most hostile environment crypto is deployed in today; it's worse even than microcontrollers that have to use CBC-MAC because SHA1 won't fit in code space. It doesn't work.
I'm writing up a document about this now, as luck would have it, but in the meantime you could try not taking my word for and instead read Nate Lawson, who is smarter than both of us put together:
Here's a hint: it's not about "encoding issues". SJCL is nice work, but SJCL is to a working cryptosystem what mixed oxide U/Pu fuel pellets are to a working nuclear reactor. Don't be like that boy scout who irradiated his whole suburb building something in his garage.
I had it coming. But for what it's worth: I'm a net admirer of your work. Call me out for being unfair any time, but don't think I'm throwing darts at a Zed Shaw picture on my wall.
Yeah, very very true. I've said for a while that the quality of example code and the "linguistic usability" of a service or API is a major influence on what a programmer does.
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.
Need I point out the irony of an authentication site containing an XSS attack?
Login Name: " onfocus="alert(1)" foo="
Submit form. Get error. Click input box again. XSS. Now, if I was an attacker, I would create a form which does this by myself and then post to that URL to get that javascript there when they visit the page, so as soon as they click the username it runs my JS.
But that's all kind a moot point because you're delivering this over Javascript. Making sure g doesn't generate a tiny subgroup, or that N isn't (say) 2 is past the point, because how can a client trust any of this?
You're not delivering the Javascript over HTTPS, but that'd be a fig leaf anyways, because the idea is to embed this in other people's websites. Every one of those those sites would need to load this script on a page that is (a) itself HTTPS, (b) with every page component also delivered over HTTPS, (c) referencing no active content from the site that could have been loaded and cached previously without HTTPS, (d) absolutely free of cross-site scripting flaws. Otherwise, the attacker you are considering when using SRP can trivially snarf users passwords.
Javascript cryptography sucks. SJCL is a very nice library, and it might even be useful in a setting like Node.js, but it does nothing to make content-controlled code a safe place to do crypto.
This system is, right now, strictly worse than an HTTPS login prompt that simply sends a username and password. I don't understand your idea well enough to say whether it can be better than asymptotically as good as that same HTTPS login system.
I get it, by the way. The idea is just "make it easier for sites that are scared by Coda Hale's blog post to implement better - than - Gawker authentication". But even stipulating that all of this scheme can be made to work securely (I don't think it can): this is an awful lot of moving parts for an awfully small value proposition.