12 ms·

A secure way to store website users "offsite" but still own them.

72 points by self 16y ago

Udo 16y ago
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.
- zedshaw 16y ago
  The source I have is just like the Lua that runs the website. Everything else is standards based and totally open source. As I say in the about page, I'm using: http://srp.stanford.edu/ 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 http://srp.stanford.edu/download.html as the actual implementation. Yes, I'm using that C library. http://crypto.stanford.edu/sjcl/ 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.
  - bobds 16y ago
    I've collected a few links related to JS cryptography, might be useful: http://disattention.com/13/javascript-cryptography/ http://disattention.com/13/javascript-cryptography/ There is another SRP implementation in JS+PHP: http://www.denksoft.com/wordpress/web-development/secure-ajax-channel-srp-hermetic/ http://www.denksoft.com/wordpress/web-development/secure-aja... We definitely need more SRP implementations, glad to see more people working on it.
    - tptacek 16y ago
      Clipperz also has a PHP SRP implementation, but it accepts any A = 0 mod N and thus allows people to log in without knowing their passwords, which is a nice feature but maybe not what you want in a secure auth scheme.
      - deleted 16y ago
        [deleted]
blub 16y ago
Nice choice of words. Web sites usually own your accounts, even if the internet is open. 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.
- qjz 16y ago
  It's not just that. While there is much justified concern about user privacy and security, it's easy to forget that the site also has assets to protect. Giving up control to a third party is a very scary prospect for some organizations.
mooism2 16y ago
I don't understand. 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.
- zedshaw 16y ago
  I'm not sure yet since I haven't got the API designed, but I will aim for autho.me to be a centralized web service that your clients and/or webservers use to auth people. Most likely you wouldn't even know they're using it unless they choose to tell you. 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.
  - mooism2 16y ago
    Ah, so it's not single sign-on really. It makes more sense now, thanks.
    - deleted 16y ago
      [deleted]
    - zedshaw 16y ago
      Yeah, SSO but not for the entire world, just potentially one organizations gang of sites.
JonnieCache 16y ago
Pink on yellow. Nice. On an unrelated note, I'm off to satiate my sudden urge for Battenberg cake.
- qjz 16y ago
  From the page footer: The crazy colors should tell you that this is only for the brave.
- zedshaw 16y ago
  You like that? I was going for a "this shit is crazy" motif. Just to make sure it's clear that it's new and not tested yet.
  - JonnieCache 16y ago
    No. It is horrific. You have done your job. Maybe chuck in a few blink tags.
dangrossman 16y ago
You can tell a website was designed on a Mac when its fonts are nearly unreadable in Windows browsers other than Safari.
- deleted 16y ago
  [deleted]
- jaskerr 16y ago
  No need for the snark. 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.
  - dangrossman 16y ago
    Why is there no need for the snark? Do you think there is never a need for snide remarks? Choosing to use fonts that don't render well as your body font deserves contempt! It is bad for the people reading the site, and it's bad for the site owner. 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.
- stevelosh 16y ago
  As jaskerr said, the font stack looks like this: "Adobe Caslon Pro", "Hoefler Text", Georgia, Garamond, Times, serif The first two fonts don't come with Windows, so if it's using one of them and looks bad then you have a shitty version of it installed. Not his fault. 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.
JoachimSchipper 16y ago
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.)
- tptacek 16y ago
  Help me out here, Joachim, because you know where I'm coming from: what's the setting in which this Javascript SRP implementation could improve things over stock-standard HTTPS login?
  - JoachimSchipper 16y ago
    I replied to your top-level comment: http://news.ycombinator.com/item?id=2034926 http://news.ycombinator.com/item?id=2034926.
  - zedshaw 16y ago
    You'd use both HTTPS and this, as I mentioned before. This just means that a site using the service, if they use it right (big if), doesn't have to worry about password storage or securing them and leaves it to autho.me. Otherwise, everything else is pretty much the same as what you got on existing websites.
    - tptacek 16y ago
      You read my whole comment. You know you can't just use HTTPS for your part of it; that you have to have clean-room purity for every piece of content that builds any page that ever deals with any of the mechanics of this code. 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.
      - zedshaw 16y ago
        Like I keep telling you, this isn't any more or less secure than any existing solution because the browser is not secure in the face of an attack. Even with HTTPS if I can inject some javscript then it's a one-liner to get your password. So no, even with HTTPS and your proposed solution you'd still be screwed.
qjz 16y ago
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: Only letters and numbers in your login. Any chance of supporting "@" & "." so I can have easy-to-remember logins for different sites/purposes?
- zedshaw 16y ago
  Sure. I'm thinking it'd probably be up to the site using the service what their login policy is.
miGlanz 16y ago
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: - 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.
- zedshaw 16y ago
  I'd have to look at it more, but I think doing the 2nd factor auth before a simple password auth will have problems. What you really want is they login like normal, but then they get a txt message or use an app on their phone to do the 2nd factor. 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!
  - miGlanz 16y ago
    I wasn't thinking about second factory actually (unfortunately I can't easily express my ideas in English, I haven't made it clear enough). The barcode would make a first (and only) factor. Of course username/password would stay there for backwards compatibility. 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_number_here 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_same_nonce_used_above 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.
bstar77 16y ago
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. On the more positive side, congrats on releasing yet another useful project. This is definitely an interesting concept.
- zedshaw 16y ago
  I'll do that, and have read that.
viraptor 16y ago
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...)
- zedshaw 16y ago
  It took me a week+ to get this far with it, and it's still not totally right. It is definitely not "easy" to do. 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.
tptacek 16y ago
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.
- JoachimSchipper 16y ago
  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.
krainboltgreene 16y ago
Argh! Well, he managed to get something tangible out first, but I still think I've got a shot with V13.
- zedshaw 16y ago
  Haha, suck it! :-)
  - krainboltgreene 16y ago
    My design totally looks cooler though, my mom said so.
Ixiaus 16y ago
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.

72 points by self 16y ago

Udo 16y ago

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.

zedshaw 16y ago
The source I have is just like the Lua that runs the website. Everything else is standards based and totally open source. As I say in the about page, I'm using: http://srp.stanford.edu/ 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 http://srp.stanford.edu/download.html as the actual implementation. Yes, I'm using that C library. http://crypto.stanford.edu/sjcl/ 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.
- bobds 16y ago
  I've collected a few links related to JS cryptography, might be useful: http://disattention.com/13/javascript-cryptography/ http://disattention.com/13/javascript-cryptography/ There is another SRP implementation in JS+PHP: http://www.denksoft.com/wordpress/web-development/secure-ajax-channel-srp-hermetic/ http://www.denksoft.com/wordpress/web-development/secure-aja... We definitely need more SRP implementations, glad to see more people working on it.
  - tptacek 16y ago
    Clipperz also has a PHP SRP implementation, but it accepts any A = 0 mod N and thus allows people to log in without knowing their passwords, which is a nice feature but maybe not what you want in a secure auth scheme.
    - deleted 16y ago
      [deleted]

blub 16y ago

Nice choice of words. Web sites usually own your accounts, even if the internet is open. 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.

qjz 16y ago
It's not just that. While there is much justified concern about user privacy and security, it's easy to forget that the site also has assets to protect. Giving up control to a third party is a very scary prospect for some organizations.

mooism2 16y ago

I don't understand. 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.

zedshaw 16y ago
I'm not sure yet since I haven't got the API designed, but I will aim for autho.me to be a centralized web service that your clients and/or webservers use to auth people. Most likely you wouldn't even know they're using it unless they choose to tell you. 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.
- mooism2 16y ago
  Ah, so it's not single sign-on really. It makes more sense now, thanks.
  - deleted 16y ago
    [deleted]
  - zedshaw 16y ago
    Yeah, SSO but not for the entire world, just potentially one organizations gang of sites.

JonnieCache 16y ago

Pink on yellow. Nice. On an unrelated note, I'm off to satiate my sudden urge for Battenberg cake.

qjz 16y ago
From the page footer: The crazy colors should tell you that this is only for the brave.
zedshaw 16y ago
You like that? I was going for a "this shit is crazy" motif. Just to make sure it's clear that it's new and not tested yet.
- JonnieCache 16y ago
  No. It is horrific. You have done your job. Maybe chuck in a few blink tags.

dangrossman 16y ago

You can tell a website was designed on a Mac when its fonts are nearly unreadable in Windows browsers other than Safari.

deleted 16y ago
[deleted]
jaskerr 16y ago
No need for the snark. 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.
- dangrossman 16y ago
  Why is there no need for the snark? Do you think there is never a need for snide remarks? Choosing to use fonts that don't render well as your body font deserves contempt! It is bad for the people reading the site, and it's bad for the site owner. 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.
stevelosh 16y ago
As jaskerr said, the font stack looks like this: "Adobe Caslon Pro", "Hoefler Text", Georgia, Garamond, Times, serif The first two fonts don't come with Windows, so if it's using one of them and looks bad then you have a shitty version of it installed. Not his fault. 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.

JoachimSchipper 16y ago

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.)

tptacek 16y ago
Help me out here, Joachim, because you know where I'm coming from: what's the setting in which this Javascript SRP implementation could improve things over stock-standard HTTPS login?
- JoachimSchipper 16y ago
  I replied to your top-level comment: http://news.ycombinator.com/item?id=2034926 http://news.ycombinator.com/item?id=2034926.
- zedshaw 16y ago
  You'd use both HTTPS and this, as I mentioned before. This just means that a site using the service, if they use it right (big if), doesn't have to worry about password storage or securing them and leaves it to autho.me. Otherwise, everything else is pretty much the same as what you got on existing websites.
  - tptacek 16y ago
    You read my whole comment. You know you can't just use HTTPS for your part of it; that you have to have clean-room purity for every piece of content that builds any page that ever deals with any of the mechanics of this code. 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.
    - zedshaw 16y ago
      Like I keep telling you, this isn't any more or less secure than any existing solution because the browser is not secure in the face of an attack. Even with HTTPS if I can inject some javscript then it's a one-liner to get your password. So no, even with HTTPS and your proposed solution you'd still be screwed.

qjz 16y ago

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: Only letters and numbers in your login. Any chance of supporting "@" & "." so I can have easy-to-remember logins for different sites/purposes?

zedshaw 16y ago
Sure. I'm thinking it'd probably be up to the site using the service what their login policy is.

miGlanz 16y ago

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: - 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.

zedshaw 16y ago
I'd have to look at it more, but I think doing the 2nd factor auth before a simple password auth will have problems. What you really want is they login like normal, but then they get a txt message or use an app on their phone to do the 2nd factor. 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!
- miGlanz 16y ago
  I wasn't thinking about second factory actually (unfortunately I can't easily express my ideas in English, I haven't made it clear enough). The barcode would make a first (and only) factor. Of course username/password would stay there for backwards compatibility. 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_number_here 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_same_nonce_used_above 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.

bstar77 16y ago

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. On the more positive side, congrats on releasing yet another useful project. This is definitely an interesting concept.

zedshaw 16y ago
I'll do that, and have read that.

viraptor 16y ago

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...)

zedshaw 16y ago
It took me a week+ to get this far with it, and it's still not totally right. It is definitely not "easy" to do. 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.

tptacek 16y ago

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.

JoachimSchipper 16y ago
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.

krainboltgreene 16y ago

Argh! Well, he managed to get something tangible out first, but I still think I've got a shot with V13.

zedshaw 16y ago
Haha, suck it! :-)
- krainboltgreene 16y ago
  My design totally looks cooler though, my mom said so.

Ixiaus 16y ago

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.