
Autho.me API And Python Demo - delano
http://sheddingbikes.com/posts/1294445127.html
======
tptacek
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/>

~~~
zedshaw
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.

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

~~~
zedshaw
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...](http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/)

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.

~~~
tptacek
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.

~~~
zedshaw
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.

~~~
tptacek
You think maybe he's making it up?

:)

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

~~~
zedshaw
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.

~~~
srean
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.

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

