With a normal SRP implementation, I'd ask questions like "why aren't you checking <i>B</i> mod <i>N</i>" (you're using Wu's libs so thankfully you're not automatically boned on the server) and "why don't you hardcode <i>N</i> and <i>g</i> 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.<p>But that's all kind a moot point because you're delivering this over Javascript. Making sure <i>g</i> doesn't generate a tiny subgroup, or that <i>N</i> isn't (say) 2 is past the point, because how can a client trust any of this?<p>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.<p>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.<p>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.<p>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.
It's an interesting concept, but I am concerned about the closed-source nature of the project. OpenID and OAuth have gotten as far as they did because they use a verifyable mechanism, all parts of which can be re-implemented and checked at will. Autho.me on the other hand is just asking for the trust of users and developers. I'm not insinuating that the code can't be trusted, but there are issues to be aware of such as very sparse documentation and the risk of investing a lot of work and goodwill in a single, private provider.
I created an account for a user with a common name. Obviously, such names will be used up quickly. If a user wants multiple accounts, it would be nice to support realms, so the user portion of the name can be reused. But when I tried "user@example.com" I got an error: <i>Only letters and numbers in your login.</i> Any chance of supporting "@" & "." so I can have easy-to-remember logins for different sites/purposes?
Hi Zed, I had this idea recently which might somehow be related to yours (or complement it, to be more precise).
I was thinking about making various password managers (KeePassX, etc.) work better with web sites and about
storing your passwords on your mobile device and use this device to easily log into services (for example
when you're away from your PC). So the idea was basically this:<p>- show me a 2d barcode (QR-code, datamatrix, whatever) on your Sign-in page;<p>- I scan this code with my mobile phone application (or simply use desktop application that takes a screenshot);<p>- this application (password manager) makes a request to your service and authenticates me (using SRP);<p>- your Sign-in page uses AJAX in the background to check if I'm already authenticated;<p>- if the auth process was finished - I'm redirected to login-only area of your site;<p>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).<p>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).<p>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.
Zed, you really should jslint your javascript code. Not trying to be overly critical, but it's really a mess- not even sure where to begin- well, I would start by not defining everything in the global namespace. Take a look at "Javascript, the Good Parts" for info on javascript's quirks and best practices or Pro Javascript Design Patterns.<p>On the more positive side, congrats on releasing yet another useful project. This is definitely an interesting concept.
I don't understand.<p>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.<p>OR<p>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.
Nice choice of words. Web sites usually own your accounts, even if the internet is open.<p>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.
This has existed for some time already - FOAF+SSL. It uses X509 certificates and user owned FOAF files that can be provided by themselves or served from another resource. What's even more cool, is, the user doesn't need to "log in" nor create a "profile" since the cert authenticates the user against their FOAF file and the FOAF file provides their profile and friend connections.
Maybe I'm missing some information, but if there was a library for plugging in SRP easily, why would a page want/need to use autho.me to do this? Why not just use the same mechanism locally? (apart from the ability to change the password for multiple services in one place, I'm not sure if that's a great feature really...)
Nice to see someone actually using SRP. And understanding what's actually possible in Javascript (note that Zed very carefully doesn't say that this is "host-proof" or something along those lines.)