Autho.me API And Python Demo

http://sheddingbikes.com/posts/1294445127.html

by delano • 16 years ago

20 23 16 years ago

Semiapies• 16 years ago

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

tptacek8• 16 years 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/

delano2• 16 years 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.

tptacek8• 16 years 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.

zedshaw9• 16 years ago

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.

tptacek8• 16 years ago

Why not read Nate Lawson's blog post? This will be the second time I've recommended it to you. One of the reasons I'm not going into too much depth is, why would I recap all of Nate Lawson? You're doing crypto dev, you should be reading him already.

Your invocation of SJCL is also a bit of a straw-man. SJCL doesn't do straight-up number-theoretic crypto; even the AE cipher modes it offers avoids it. You're doing SRP in Javascript. You also keep calling it "Tom Wu's SJCL". You're saying that because "Tom Wu" is the name on SRP. Tom Wu didn't write SJCL. The SJCL authors, for what it's worth, claim "the best security which is practically available in Javascript", follow by a parenthesis, followed by the word "Unfortunately", followed by more words you should read.

The two factor stuff, by the way? News to me as of this post. Twilio and 2-factor auth is a good idea (note though that I'm biased, as my friend Dug is doing something very similar --- http://www.duosecurity.com).

srean3• 16 years 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.

zedshaw9• 16 years 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.

srean3• 16 years 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.

Autho.me API And Python Demo

Related Stories