Autho.me API And Python Demo
sheddingbikes.com
Autho.me API And Python Demo
1–10 of 25 posts
Re: Autho.me API And Python Demo
#2Interesting; I appreciate the many, large warnings not to use this in anything serious.
Re: Autho.me API And Python Demo
#3Here'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.
Re: Autho.me API And Python Demo
#4Here'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 o…
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.
Re: Autho.me API And Python Demo
#5Here'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 o…
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 approa…
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.
Re: Autho.me API And Python Demo
#6Earlier quoted context omitted.
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 approa…
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.
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.
Re: Autho.me API And Python Demo
#7Here'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 o…
Actually, no that's not the point of autho.me. I know you keep thinking it's about me making a secure authentication that competes with bcrypt+ssl. It's actually for the purposes I laid out in the blog post:
1. An easy to setup secure auth system that's at least as secure as the others available. Not more secure, but just as secure. For example, your attack of protecting against content modification applies to all login systems. Every last one. Phishing also applies to all of them. I'm trying to tease out what ones are particular to autho.me and cover those.
2. The ability to manage users across multiple domains and organizations.
3. The ability to share or trade accounts with other trusted partners. This one is dubious because I don't know how users will like it. Really gotta figure out the usability of this.
4. An easy way to do 2-factor authentication with phones.
So, don't be blinded by the SRP. That's just there to make the other features work. I'd also say if you're going put up specific attacks, then you should give ones that aren't also attacks against the things you promote. If you evaluate autho.me from the point of view of an infinitely capable super hacker who can always modify content, then all logins are vulnerable.
I'd also like demonstrations of actual javascript turing completeness or mathematic failures that aren't handled by Tom Wu's SJCL. If there's flaws in Javascript's math such that it causes failures, then I'd like some concrete examples that don't require "infinit super hacker injects code" attacks.
In otherwords, I'd like demonstrations of the SRP data that's publicly sent and an attack against it because of a failure in javascript mathematics, sjcl, or my code.
Anyway Thomas, I don't take it personally, even if you are a bit sensationalist about it.
Re: Autho.me API And Python Demo
#8Earlier quoted context omitted.
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 approa…
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.
Again, if there's an actual demonstration of Javscript maths calculating incorrectly, then please give it. I'd like to make sure it's covered in the SJCL.
Otherwise, this claim basically says that Javascript is either not turing complete or doesn't have math sufficient to do the crypto, yet the SJCL does it. It also assumes that other languages somehow have "magic" math, when really nearly all cryptography is giant bignum hacks that exploit how binary math works.
If you've got a counter to this, then by all means, I'd like to see it.
Re: Autho.me API And Python Demo
#9It 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.
Re: Autho.me API And Python Demo
#10It 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…
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.