A secure way to store website users "offsite" but still own them.
autho.me
autho.me
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.
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.
(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.
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.
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.
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.
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'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:
http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...
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.
Thanks for your comments so far.
It doesn't stop an idiot from using it wrong,
because no solution would.
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.
Edit: This is on the create-an-account form.
http://srp.stanford.edu/ as the protocol, specifically SRP6a but with a SHA256 since I couldn't get a MGF1 to work in javascript. Probably change that later.
http://srp.stanford.edu/download.html as the actual implementation. Yes, I'm using that C library.
http://crypto.stanford.edu/sjcl/ for the javascript crypto, also written by the same people doing SRP.
And you can read the javascript files on the site to see what it's doing.
So, it's based on entirely standards based (even has an RFC) open source protocols and uses implementations from the actual authors of said protocols.
The closed source part is just my lua Tir stuff and whatever else I make.
There is another SRP implementation in JS+PHP: http://www.denksoft.com/wordpress/web-development/secure-aja...
We definitely need more SRP implementations, glad to see more people working on it.
- show me a 2d barcode (QR-code, datamatrix, whatever) on your Sign-in page;
- I scan this code with my mobile phone application (or simply use desktop application that takes a screenshot);
- this application (password manager) makes a request to your service and authenticates me (using SRP);
- your Sign-in page uses AJAX in the background to check if I'm already authenticated;
- if the auth process was finished - I'm redirected to login-only area of your site;
So this 2d barcode would contain some kind of nonce that would uniquely identify current Sign-in page (we obviously can't use cookies because we're using different channels).
This whole idea could also make sign-up process much more simple (you could, for example, encode password requirements for your site, and my password manager would automatically generate the password according to these requirements, and would sign me up and record credentials in itself).
Just an idea. I'm not sure if it's viable at all (there might be some hard-to-overcome security issues), it would be nice if you let me know what you think about it.
2 factor auth though is very much possible with this, actually with any service. I may try to hack that up as a demo this week. Maybe use twilio for it and have it call you. Fun!
Once again, I'll try to express myself more clearly:
- we show a username/password input boxes and 2d barcode (QR/datamatrix);
- the user may simply enter his username/password and then everything works your way;
- he may also choose to use some kind of password manager that is compatible with this protocol;
- in this case we encode some data in the barcode (it could be some login URL, e.g. https://example.com/srp/yourservice.com/?nonce=some_random_n...);
- this password manager scans the code and performs full SRP authentication on the above URL; if it's successful we simply send some kind of notification to your service - or you poll our service for the result;
- we check the result on the actual login page as well (e.g. using AJAX): we may simply poll some other URL, like: https://example.com/srp/yourservice.com/result/?nonce=the_sa... (of cource results signing/etc. comes into play here);
- if the result is OK we simply set session data in the cookie as usual and from now on the user is authenticated;
This has additional advantage of the actual crypto going on in the password manager and on the server. It also gives the possibility to perform the sign-up process semi-automatically as well (think of password generation - the user doesn't have to know it at all). And then think of public wifi or other networks you don't trust: you may perform the auth via GSM using your mobile. But the biggest improvement, in my opinion, is the usability aspect. You could have your password manager lying in the background and when you are shown a login page you could simply double-click an icon in your tray area and you are immediately logged into the app. Or you could use password manager on your mobile phone to take a shot with its camera.
I hope this time it's clearer.
On the more positive side, congrats on releasing yet another useful project. This is definitely an interesting concept.
It's "single sign-on", but each individual website stores its own secrets, there's no centralised website, when I want to change my password I have to change it on each website.
OR
It's "single sign-on", but I have to enter my password directly into each website I log in to, and trust that they process it in javascript instead of surreptitiously logging it on their server.
As for "surreptitiously logging your password", no matter what you do, they can anyway. Just no way around it without handing all your users to some other website, and even then clever UI evil can still trick most folks into giving the password up.
Autho.me would be less about magically protecting you from some imaginary evil site, and more about making it easy for sites who aren't evil to do the right thing with their auth.
But, I still have to figure out how it will really work. This is just a test to make sure the crypto works right.
Zed used a cascade of Adobe Caslon, Hoefler, Georgia, Garamond and Times for the body. Good fonts, all of them. Whose fault is it that all except Times render poorly?*
"The crazy colors should tell you that this is only for the brave."
Maybe the same goes for the fonts.
* I checked Firefox, Chrome and IE on an XP3 system. With Chrome's Developer Tools, I removed fonts from the front of the cascade until the type looked "right", and arrived at Times. Bah.
It's neat and all that it's finally possible to use more fonts in webpages, but this is one trend that should be avoided until someone (Microsoft or the browser makers) figures out how to do the text rendering correctly.
"Adobe Caslon Pro", "Hoefler Text", Georgia, Garamond, Times, serif
The next font is Georgia. If Georgia looks bad then you just must not like Windows' font rendering. I don't blame you for that, but it's also not Zed's fault.
On a side note, I wonder if Microsoft finally fixed the idiotic "you can have normal antialiasing or sub-pixel antialiasing but by God you cannot have both" behavior in Windows 7? Anyone know?
Or you might just be talking about the tag line that's using some @font-face font that looks like ass. It looks just as bad on a Mac, so that's not the cause -- it's just an ugly font.
Magazines cater to advertisers by claiming to sell "eyeballs" and carefully picked "readers", while acting all nice to their customers. I imagine websites do the same when it comes to exiting, talking to advertisers, etc.
On an unrelated note, I'm off to satiate my sudden urge for Battenberg cake.
Maybe chuck in a few blink tags.
But, I'm thinking the main reason someone would do this is if they wanted to not be responsible if there was a break-in, and to trust a 3rd party who specializes in it.
Everybody who ever thought "oh, I'll just AES encrypt passwords in Javascript instead of using HTTPS" later came up with "oh, then I'll serve just the JS for this crypto off some HTTPS site somewhere" when someone pointed out how crazy that was. It is nowhere near that easy.
So no, even with HTTPS and your proposed solution you'd still be screwed.