Autho.me API And Python Demo | Hacker News Reader

Autho.me API And Python Demo

sheddingbikes.com

20 pointsdelano23 comments

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/

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.

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.

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

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.

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?

Yes, I do, but claiming I wrote the crypto in javascript is false. I wrote one part in javascript, and the other part is in C. That means, if there's an attack against the Javascript cryptography not the browser environment, then the mutual aspect of the cryptography will mean that the C side will catch the error.

That's why you're wrong when you say I did in javascript. Only 1/2 of it is in javascript, and I only wrote a minimal amount of that.

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.

"Turing completeness" does not mean "safe environment in which to run cryptography". There are in fact math problems in Javascript environments, but they are far from the worst problems you face there.

Again, you say javascript cryptography is flawed, and then say it's a browser environment problem. Let's break this down.

If the flaw is in how javascript does math, then that's something Autho.me has to deal with and I'd like to know about it.

If however, this is a flaw in browser environment, then all methods that use a browser are equally flawed. That includes OpenID, Oauth, SRP, and your own proposed solution of bcrypt. That's because, once I can exploit the browser environment, then I have access to anything the user submits.

That's the crux of my question: If you say there's an exploit against cryptography because of javascript math then demonstrate it. If you have exploits against the browser environment, then I can't fix those and they apply to your proposed solutions.

Let's take an example: An attacker can inject XSS code onto the login page and get the SRP password. Well, an attacker that can XSS the login page and get the password from your SSL/bcrypt solution. They've got access to the whole page.

So, if you find demos of failed math in javascript I'd like to see those.

Look, I'm just not wading into this. You and I should, as much as possible, avoid arguing; because of our personality types, we're just going to end up at the nerd equivalent of pistols at dawn.

You're telling people to use SSL with this. That is good. With SSL in the mix, my only real issue with AUTHO.ME is that it's a lot of moving parts for (what I think is) minimal value. You think "not having to implement bcrypt or PBKDF2" is major value. Guess what: this point is not worth a huge argument. And it's absolutely not worth a line-by-line evaluation of your crypto code, so I'm just not going to do it.

If you're planning on a doing an indie two-factor auth project, that value may be less minimal. I have no coherent opinion that stuff. Good luck with it. If you do something crazy, I'll call you on it, which is I think what you want.

Ignore Kaminsky, by the way. I can't imagine how using RSA instead of SRP could possibly make this safer, but I can imagine lots of ways in which it could make you much less safe.

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.

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

I did read his post, but there isn't a single actual demonstration of his claims that javascript math is flawed:

http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...

All of his exploits talk about attacks that are just browser attacks, but nothing that says what you're saying about an actual exploit in the math of javascript. His attacks also assume an infinitely capable attacker who can always alter content, which is pointless because all browser based security, even your own proposed bcrypt, is vulnerable to all of his attacks.

Also, my invocation of SJCL is not straw man, it's the actual library I'm using, so if you're going to do an exploit that takes advantage of a flaw in javascript math, then that's what you'd use. It's a concrete thing to focus on as an attack vector. That's sort of the inverse of "straw man".

Finally, if you are saying that this is the first time you're hearing about the Twilio 2-factor auth then you didn't even read the blog post.

No, Zed, I'm saying the post we're commenting on is the first time I've heard about you doing 2-factor auth. Why would you think I would comment on a post I hadn't read?

You keep talking about "the math of the Javascript". You're a smart guy. I think you know that we're not saying the math in SJCL is wrong. I don't know what "just browser attacks" mean; you're asking the browser to implement cryptography, the browser is relevant.

Nate does talk about "the math of Javascript", by the way.

I know he talks about it, but he doesn't really. He starts talking about it, and then switches to a browser environment attack.

The main crux of my disagreement with you is that you say: Doing javascript in the browser makes it more vulnerable to an exploit than just doing bcrypt+ssl passwords. However, if someone can exploit the browser (XSS, content modification, etc) then no login system is safe.

In other words, you're pimping bcrypt+ssl as a better alternative because it's NOT vulnerable to browser environment exploits, but it is. Every browser is.

A browser environment exploit is all the things you keep bringing up: cache poisoning, SSL exploits, phishing, XSS attacks, content modification, etc.

You think maybe he's making it up?

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.

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.

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.

You're also forgetting that the OpenID provider could be storing passwords and things wrong too, or that they've been hacked and someone's collecting them in-transit. Really, any attack against a non-OpenID site is available to an OpenID site, but with the added problem that nobody has to know.

For example, if google had a security breach (ehem China?) and passwords got snarfed for a period of time, how would you or a customer site know?

In addition to those attacks, there's economic attacks available from the provider. One day Google can just decide they don't like you and poof there go your users. For a customer this is a pretty big problem that they all must worry about.

And, all of those attacks are pretty much available to any login system.

Yeah that's what I meant by "phishing trap". In retrospect not a good choice of words, "compromised" would have been better. I am letting it remain as it is because you commented on it.

I think a better way to express my opinion about OpenId is this: say I trust that the probability a particular site will not be compromised is (1 - \epsilon). Then OpenId lets me maintain and transfer that value of trust over authentication transaction with other sites. As the saying goes, it is as strong as the weakest link.

There are protocols by which one can boost the level of trust beyond that (1 - \epsilon) but I have not come across a easy to use deployment of one such.

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

Reply on news.ycombinator.com