4 ms·

Autho.me API And Python Demo

20 points by delano 16y ago

Semiapies 16y ago
Interesting; I appreciate the many, large warnings not to use this in anything serious.
tptacek 16y ago
Here's what you're thinking when you see this: "Oh, neat, this is Zed Shaw telling me he's made something that will get me secure login that doesn't send passwords to my service using crypto that he feeds users through Javascript! I can't wait until it's ready to use!" Here's what Zed Shaw says this is for: application developers who are so uncertain as to whether they can hash passwords properly that they'd rather outsource that service to someone who can hash passwords properly... and nothing else. Here's what I think: if every piece of this is served via SSL, or if you don't really care about account security but just don't want to be keeping a database of passwords just so people can leave comments on a CMS, you stand a chance of not making your service less secure by using it --- not a very good chance, but a chance. If, by the way, you serve every piece of content on any page that touches this API or that could ever be cached and touched by a page that touches that API through SSL --- which is what you have to do for this to stand any chance of being secure --- you already have a secure channel to send passwords to your application. Personally, I think it's so easy to safely store passwords† and there are so many moving parts in this design that I can't fathom why anyone would opt into it. This is a project that at first glance appears to offer immense value, but really offers a truly marginal bit of value. I'm really tired of being down on Zed Shaw. It's really nothing personal. I'll go a step further and say that this is one of the very few SRP implementations I've seen that didn't have a variant of a common auth bypass flaw. It's not bad code. But unfortunately, Zed is wading into the fever swamp of Javascript crypto, and it's worth calling this out just so other people don't have the impression that This Is Something We Do Now. † http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- delano 16y ago
  For websites/apps this is true. There's already a straightfoward solution (which you point to): store passwords with bcrypt (or scrypt) and use HTTPS for all pages that send/receive the session cookie. For authentication APIs, it's less clear. The default right now seems to be basic or digest auth + HTTPS. There's also OAuth but it's a mess to implement/integrate with. I personally like the Amazon Web Services approach with signed requests. It's helpful to separate the two usecases because they are very different.
  - tptacek 16y ago
    The difference between OAuth and Javascript SRP (what AUTHO.ME implements) is that OAuth does the crypto (what little there is of it) serverside, and AUTHO.ME does the crypto (crypto of the most intense and fragile kind) clientside. This isn't a small difference.
    - delano 16y ago
      That's good to know. I just wanted to separate the two usecases from the developer's perspective. I'm not qualified to make any authoritative conclusions about any particular solution.
      - zedshaw 16y ago
        Actually, he's incorrect. The crypto is calculated in javascript, and in a C library written by the author of SRP: http://srp.stanford.edu/download.html http://srp.stanford.edu/download.html I'm using 2.1.2 with one slight modification to use SHA256 instead of SHA1+MGF1. That means that, should there be a failure in the javascript, it has a chance of getting caught in the C code written by the author of SRP.
        tptacek 16y ago
        I'm not incorrect. I did actually read your code, Zed. You think I've made a claim that I haven't made: that you wrote a serverside implementation of SRP. I know you're using the original SRP library. That was a good call. You know SRP is mutual auth, right?
srean 16y ago
It appears that Zed Shaw does not like openId. I agree with him that it is certainly no panacea, but the risks can be minimized to a large extent if used properly. I use openId to login to HN. So when I submit my Google openID, in principle, HN can redirect me to a fake Google site where I may unknowingly type in my password. The big loophole is that I have no control over which site I am redirected to by HN. However if I were to log into google first and then visit the HN login page that problem disappears. If all goes well HN redirects me to Google which remembers that I am already authenticated and directs me back to HN. OTOH if HN sends me to a malicious site it will ask for my password and give itself away as a malicious site. I am no security expert, and corner cases of vulnerability surely exists. But some simple guidelines can mitigate the risks quite a bit. One point raised in the article is that By comparison, OpenID assumes the User and a Third Party is more trustworthy than the Customer. I personally find this bizarre since it's saying that someone is going to log into a potentially dangerous site, and simply using OpenID makes that alright. I wont go on to claim OpenID makes everything alright. But I like the feature that I as a user get to choose who I trust with my password, 2nd party, third party or some N^{th} party. So it does not seem that "bizarre" to me.
- zedshaw 16y ago
  I don't have any problem with OpenID itself, and in fact I worked on the PIP project at Verisign briefly. That statement is more about the difference in design, that OpenID has been marketed as some kind of protection against evil sites. It's an evil site, no amount of OpenID is going to protect you. I also disagree with the idea that OpenID protects against phishing, since well, if one site can be phished then an OpenID site can too. Phishing is a failure of usability in the browser, so all websites are vulnerable to it. Basically, my objections with OpenID are more in how it's marketed as some protection against things which really aren't a protocol problem or can't be solved by OpenID.
  - srean 16y ago
    Ok that clears the air :) I agree that if as an user I trust the "customer" to take me to my OpenId provider then it provides no protection against phising. I totally agree that phishing is not a protocol problem and cannot be solved at a protocol level.Thankfully I wasn't exposed to that marketing, so to me OpenId was mostly an issue of convenience. However the common modality of breaking OpenId security can be mitigated if I login to my OpenId provider first. I think your concern is that my OpenId provider itself might be a phishing trap. Yes, if I fall for that, then all bets are off. But ideally I should be typing its url on my browser or going from a bookmark.
sdghjrjyt 16y ago
Happy New Year◎,◎appy shopping ●---------------------------------------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●---------------------------------------● Happy New Year◎,◎appy shopping

20 points by delano 16y ago

Interesting; I appreciate the many, large warnings not to use this in anything serious.

Here's what you're thinking when you see this: "Oh, neat, this is Zed Shaw telling me he's made something that will get me secure login that doesn't send passwords to my service using crypto that he feeds users through Javascript! I can't wait until it's ready to use!" Here's what Zed Shaw says this is for: application developers who are so uncertain as to whether they can hash passwords properly that they'd rather outsource that service to someone who can hash passwords properly... and nothing else. Here's what I think: if every piece of this is served via SSL, or if you don't really care about account security but just don't want to be keeping a database of passwords just so people can leave comments on a CMS, you stand a chance of not making your service less secure by using it --- not a very good chance, but a chance. If, by the way, you serve every piece of content on any page that touches this API or that could ever be cached and touched by a page that touches that API through SSL --- which is what you have to do for this to stand any chance of being secure --- you already have a secure channel to send passwords to your application. Personally, I think it's so easy to safely store passwords† and there are so many moving parts in this design that I can't fathom why anyone would opt into it. This is a project that at first glance appears to offer immense value, but really offers a truly marginal bit of value. I'm really tired of being down on Zed Shaw. It's really nothing personal. I'll go a step further and say that this is one of the very few SRP implementations I've seen that didn't have a variant of a common auth bypass flaw. It's not bad code. But unfortunately, Zed is wading into the fever swamp of Javascript crypto, and it's worth calling this out just so other people don't have the impression that This Is Something We Do Now. † http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/

delano 16y ago
For websites/apps this is true. There's already a straightfoward solution (which you point to): store passwords with bcrypt (or scrypt) and use HTTPS for all pages that send/receive the session cookie. For authentication APIs, it's less clear. The default right now seems to be basic or digest auth + HTTPS. There's also OAuth but it's a mess to implement/integrate with. I personally like the Amazon Web Services approach with signed requests. It's helpful to separate the two usecases because they are very different.
- tptacek 16y ago
  The difference between OAuth and Javascript SRP (what AUTHO.ME implements) is that OAuth does the crypto (what little there is of it) serverside, and AUTHO.ME does the crypto (crypto of the most intense and fragile kind) clientside. This isn't a small difference.
  - delano 16y ago
    That's good to know. I just wanted to separate the two usecases from the developer's perspective. I'm not qualified to make any authoritative conclusions about any particular solution.
    - zedshaw 16y ago
      Actually, he's incorrect. The crypto is calculated in javascript, and in a C library written by the author of SRP: http://srp.stanford.edu/download.html http://srp.stanford.edu/download.html I'm using 2.1.2 with one slight modification to use SHA256 instead of SHA1+MGF1. That means that, should there be a failure in the javascript, it has a chance of getting caught in the C code written by the author of SRP.
      - tptacek 16y ago
        I'm not incorrect. I did actually read your code, Zed. You think I've made a claim that I haven't made: that you wrote a serverside implementation of SRP. I know you're using the original SRP library. That was a good call. You know SRP is mutual auth, right?

srean 16y ago

It appears that Zed Shaw does not like openId. I agree with him that it is certainly no panacea, but the risks can be minimized to a large extent if used properly. I use openId to login to HN. So when I submit my Google openID, in principle, HN can redirect me to a fake Google site where I may unknowingly type in my password. The big loophole is that I have no control over which site I am redirected to by HN. However if I were to log into google first and then visit the HN login page that problem disappears. If all goes well HN redirects me to Google which remembers that I am already authenticated and directs me back to HN. OTOH if HN sends me to a malicious site it will ask for my password and give itself away as a malicious site. I am no security expert, and corner cases of vulnerability surely exists. But some simple guidelines can mitigate the risks quite a bit. One point raised in the article is that By comparison, OpenID assumes the User and a Third Party is more trustworthy than the Customer. I personally find this bizarre since it's saying that someone is going to log into a potentially dangerous site, and simply using OpenID makes that alright. I wont go on to claim OpenID makes everything alright. But I like the feature that I as a user get to choose who I trust with my password, 2nd party, third party or some N^{th} party. So it does not seem that "bizarre" to me.

zedshaw 16y ago
I don't have any problem with OpenID itself, and in fact I worked on the PIP project at Verisign briefly. That statement is more about the difference in design, that OpenID has been marketed as some kind of protection against evil sites. It's an evil site, no amount of OpenID is going to protect you. I also disagree with the idea that OpenID protects against phishing, since well, if one site can be phished then an OpenID site can too. Phishing is a failure of usability in the browser, so all websites are vulnerable to it. Basically, my objections with OpenID are more in how it's marketed as some protection against things which really aren't a protocol problem or can't be solved by OpenID.
- srean 16y ago
  Ok that clears the air :) I agree that if as an user I trust the "customer" to take me to my OpenId provider then it provides no protection against phising. I totally agree that phishing is not a protocol problem and cannot be solved at a protocol level.Thankfully I wasn't exposed to that marketing, so to me OpenId was mostly an issue of convenience. However the common modality of breaking OpenId security can be mitigated if I login to my OpenId provider first. I think your concern is that my OpenId provider itself might be a phishing trap. Yes, if I fall for that, then all bets are off. But ideally I should be typing its url on my browser or going from a bookmark.

sdghjrjyt 16y ago

Happy New Year◎,◎appy shopping ●---------------------------------------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●------ http://goo.gl/l5v0b http://goo.gl/l5v0b ------● ●---------------------------------------● Happy New Year◎,◎appy shopping