

Zed Shaw & Dan Kaminsky Talk About Autho.me on Twitter - seanplaice
http://www.curated.by/splaice/zed-shaw--dan-kaminsky-talk-about-authome
I have been intrigued by the autho.me project. Last night it was great to see a conversation between Dan Kaminsky and Zed Shaw about specifics of autho.me.
======
tptacek
So for a whole long bunch of messages you have two people talking past each
other about how the world uses passwords and the semantics of SSO and then "Is
your SRP math constant time with respect to the passwords in use". Zed,
seriously? This is making me sad.

Best to make sure your HMAC implementation is constant time with respect to
the key, too!

If you think for just a little while, I think you can spot the "semantic"
difference between using RSA and SRP in this scenario, and why using one
instead of the other would change this system from a curiosity to a danger.

Has it occurred to you that this is the best conversation you've had about
AUTHO.ME so far because it appeared authoritative but _didn't challenge you at
all_? Is that what you want? Preening isn't going to make your system better.
I'm trying hard to believe that you're better than that.

~~~
zedshaw
No, it's the best conversation because, unlike conversations with you, it
brought legit testable things to test for and questioned basic assumptions I
had based on actually looking at the code I'd made. E.g. A timing attack based
on password length in SRP is legit. Everything you bring up is just yelling
and screaming about browser security issues every login system has, then
claiming your proposed login solution doesn't have them.

Even in this comment you're all over the map. HMAC? I'm not using HMAC. RSA
vs. SRP? One is an asymmetric cryptography algorithm and the other is a
authentication protocol, which are very different. You can't just slap RSA on
something and then it's an auth algorithm. There's a whole range of protocol
analysis to do in addition to just using RSA.

But why am I telling you that? You're a real cryptographer. How come you
didn't mention the possible timing attack against SRP?

~~~
tptacek
No, Zed. A timing attack based on password length in SRP is not really
legitimate.

As you know, I read your code, and I know you're not using HMAC. I'm saying
that timing SRP based on passwords is like timing HMAC based on the key: ie,
not how a timing attack on SRP would actually work.

I'm going to let someone else chime in and add details to this, because when
you and I argue, it just becomes a crazy personality-driven soap opera. I have
approximately the same issue with Kaminsky, so don't think that's somehow a
criticism of you.

For the record: I'm _not_ a real cryptographer. We do have some on HN. Colin
Percival is really a cryptographer; he has been published multiple times in
the literature. What I do is get paid to break systems, and I've been on a
tear through crypto features in the last couple years. I am a second-rate Nate
Lawson. That's all the background needed to sniff-test this Twitter dialog.

------
gst
I still don't get the reason why I should use autho.me over OpenID.

With OpenID the site to which I want to login redirects me to my OpenID
provider. So the advantages are:

\- I login on the site of my OpenID provider and the site to which I want to
login does not learn my password.

\- I can check the identity of the OpenID provider before disclosing my
password (e.g., by checking the SSL certificate).

\- The OpenID provider does not need to use a password-based login system, but
can use other things (like secure tokens or OTP-based auth) instead.

If I get this correctly (please correct me if I'm wrong) with autho.me I enter
my password directly on the site to which I want to login, but some JavaScript
in the background does some cryptographic magic with the password. So:

\- A malicious site can just read my password. It's nearly impossible to
ensure that the correct code is running in the background.

\- I do not only need to trust that my ID-provider has took precautions
against XSS & Co., but I also need to trust each single website to which I'd
want to login. A single compromised website and my password is compromised.

\- Not really any advantage in comparison to OpenID.

Did I miss any obvious points/advantages?

~~~
ihodes
You missed that you're not going to be using the same password for each
website.

Autho.me isn't a spin-off of OpenID, it's basically outsourcing signing-
in/password "storing" for websites that don't want to risk fucking it up. The
point isn't to have a single ID to use across all websites.

~~~
tptacek
If you are worried about fucking up password storage (and, good for you), it's
not that hard. Read:

<http://codahale.com/how-to-safely-store-a-password/>

Not that it's Zed's fault that this is true†, but it's actually harder to
safely host something like AUTHO.ME on a website than it is to simply use a
reasonable hashing algorithm.

† _I both believe this and also have to say it to avoid a sharks/jets rumble
with him on HN._

~~~
gst
I just want to add that nowadays "scrypt" (see
<http://www.tarsnap.com/scrypt.html>) might be a better solution than bcrypt
(suggested in the link).

("might" because scrypt is relatively new and therefore missing the numerous
peer reviews bcrypt has seen).

~~~
tptacek
I think most anyone who looks at KDFs probably both likes scrypt and also
doesn't obsess too much about them. The problem with scrypt is that it doesn't
have a lot of language bindings; you can get bcrypt anywhere.

Personally, I think _any_ serious KDF is better than just using SHA1 (or
SHA256, and note that the difference between SHA1 and SHA256 is not super
relevant to SRP), so as long as you're doing something --- PBKDF1, PBKDF2,
bcrypt, scrypt, hand-hacked 1000-iterations-of-SHA1 --- I'm happy.

------
dotBen
The only thing I took away from this is proof that Twitter is not a
_conversation_ tool, no matter how much people say otherwise. Unless your
conversations never have more than a handful of exchanges.

Must have been hell for those who follow both parties and thus would have
triggered Twitter's mechanism which ensures you receive tweets that begin with
the @name of another user you follow.

~~~
mfukar
I follow all three (tptacek, @dakami, zedshaw), and at times I want to kill
myself for using Twitter.

------
cmelbye
I don't understand autho.me, how is it supposed to be better than OpenID? In
my opinion, it's worse than OpenID because with OpenID you can at least throw
up a webpage at <http://openid.yourcustomdomain.com/> and just edit a few meta
tags when you need to switch to a different provider. I would personally only
consider this if it were open source, and it's not so I can't see the draw.

~~~
zedshaw
Basically what Steve said in reply to you, but I'll also add that it _is_ open
source. I'm using the following library from the author of SRP:

<http://srp.stanford.edu/download.html>

as the backend implementation, and then you can see the full javascript I've
written with view source. The javascript isn't free to use, but you can
evaluate it to see if you trust it.

The only thing I'm not releasing is the Lua code that implements the HTTP API,
and all the other glue.

Also, I very seriously doubt you go around demanding you see the
authentication implementation of every auth system you use. It's rather unfair
to say you need to see mine when you don't demand you see Google's.

~~~
tptacek
It's not unfair to say that if he's got to pick between a clunky but
mainstream standard for authentication and something entirely custom, the
entirely custom option would need to be (really) open source for him to
consider it.

------
troutwine
That is incredibly hard to read.

~~~
JeffJenkins
Is this what all of twitter is like? I tried reading both this and that less
ambitious movie titles page and it was really hard.

------
marshray
Does Javascript have so much as a secure memory overwrite function? Documented
constant-time operations?

If not, how is it that knowledgeable professionals and hackers are seemingly
tossing around the term "Javascript Crypto" with a straight face?

~~~
tptacek
No. No. I don't know. They should stop, Marsh.

------
jacobolus
Reformatted and put in forward order:

* * *

Zed Shaw & Dan Kaminsky Talk about autho.me

Dan Kaminksy (<http://en.wikipedia.org/wiki/Dan_Kaminsky>) and Zed Shaw
(<http://en.wikipedia.org/wiki/Zed_Shaw>) chat on Twitter about Shaw's new
project <http://autho.me>

Z: In my research on "Javascript Crypto Not Secure" I can't find any exploits
of the actual _math_ available in javascript. Anyone got link?

D: You're probably going to be vulnerable to timing attacks, but it's not the
math that worries at least me.

D: Your general problem is you can't trust the initial deployment in the first
place.

Z: Right, now compare that to a regular login. If you can't trust the
deployment, then _all_ login systems are vulnerable. Right?

D: Yeah, but it's your job to move the ball. The generic attack against JS
crypto is to just add a js sniffer that grabs txt

D: The argument is basically, JS crypto can't be any better than a simple form
login, because the simple form can be sniffed

D: You can get around that using HTTPS, but then, why use the JS crypto? Just
run a simple form inside of HTTPS

Z: No, my contention is that any attack against the autho.me SRP is an attack
against any browser login. Nothing can stop that.

D: What you're trying to do is vaguely different, in that you've got some
third party stuff going on. So I'm reserving judgment

D: Yeah dude, all browser login not encapsulated in HTTPS is known to be owned
(see: the Tunisian .gov)

D: And honestly, almost all HTTPS login itself is owned too, because it falls
back to HTTP (see: Firesheep)

Z: Yes, and https+bcrypt is the option for DIY. The crypto is for getting 3rd
party auth and not having to store. Not encryption.

D: Your stuff ready to be looked at, btw?

Z: Exactly, and if you can get XSS on the page, then you're double screwed.
There's just nothing to do about it without a plugin.

Z: Oh yeah, totally. <http://autho.me/start.html>. BREAK IT MY BROTHER! I'll
buy you a beer for each flaw you find. :-)

D: So, autho.me is a SSO solution where there's no popup window or redirect to
the main site?

Z: Yep. Pretty simple.

D: So, if I log into chat.com and auction.com, I put in the same username and
password to both?

Z: No, different passwords, so chat.com has its own users/passwords separate
from auction.com.

Z: Then there may be a feature for partners to trade user accounts, but not
sure about that.

D: So how is this SSO? That sounds like status quo.

Z: Oh my bad. If ZedShaw,LLC owned chat.com and auction.com then they could do
that, but they set it up for that, not the user.

Z: Otherwise, yes, it is pretty much status quo. It's not like it's a major
revolution in authentication.

D: Can you explain in a nutshell what scenario autho.me seeks to improve? (You
have my attention!)

D: What does autho.me improve/prevent/change?

Z: 1) Easy setup like OpenID but own the users. 2) Sharing users with
partners. 3) Simple 2-factor auth. 4) Central management.

Z: And it proposes to prevent someone getting onto your server and getting all
the passwords, ala Gawker.

D: Well, you know SRP hashes can be cracked just like any other, right?

Z: Sure, I mean people pick crap passwords so can't prevent that. The Verifier
should be as secure as other methods.

Z: The difference is nothing is stored by the customer, but by autho.me, which
reduces the risk. Then autho.me just stores SRP.

D: So, under normal circumstances, the customer stores nothing, but proxies
the SRP exchange to autho.me on the backend?

Z: Yep. Then autho.me only stores the username:verifier combo, no passwords.

D: OK. Now what do you mean by 2-factor auth?

Z: I'm toying with adding SMS verification using <http://www.twilio.com/>

D: Tell me a little more about how your "partner site" vision works?

D: OK so you're _not_ like OpenID or SSO.OpenID/SSO lets two sites share the
same user creds, without one site being able...

D: ...to log into the other site. Clearly that's not a threat model you can
ever support, because at any point chat.com can formsniff

D: and log into auction.com. You're more like outsourced auth. Take all the
normal scary parts of managing u/p and let someone else

D: handle that. malicious site can still get pw plaintext, and malicious
autho.me can crack verifiers, but autho.me can...

D: indeed refuse to process verifier without SMS validate. So basically the
crypto isn't doing too much, it's just...

D: "Keep me, under normal circumstances, from ever seeing the plaintext
password. Require an active live attack for gawker to work"

D: 99% of your functionality seems doable just by forwarding plaintext u/p to
autho.me and saying "should i let this guy in"

D: So, long story short, you might have found a use of JS crypto small enough
that it's not actually broken. But is this what you...

D: set out to build?

Z: Ha, nice, longest stream of tweets ever. Yes, just enough SRP to make it
plausible to not have to see passwords.

Z: And, SSO is a misleading term since it doesn't say who is doing the sign-
on, but outsourced auth is a good term for it.

Z: Finally, I think most folks use OpenID not for security, but for the
outsourced/low setup costs aspect of it.

D: SSO pretty consistently means being able to leverage one login across
multiple assets. You aren't really about doing that safely.

D: Most people use OpenID? :)

Z: Oh, and clear u/p didn't work because for a customer to claim they don't
see passwords they'd need to not actually see them.

Z: Well, the ones who do use OpenID, that's why they use it. Logins are
apparently super hard and shit. :-)

D: Customers can see passwords whenever they like, it's a few lines of JS. I
see where you're going with that argument, though

D: OpenID is a mess for a bunch of really fascinating reasons, all having to
do with browser session management being nonexistent

Z: Leverage one login, yes. Across multiple _untrusted_ random assets, no.
Nothing in SSO says it has to be between two random sites.

D: Not untrue, actually. SSO across Google is indeed all mutually trusting.

Z: Yes, without browser and protocol support for much stronger auth, none of
the existing methods (mine included) are really secure.

D: Outsourced auth where well-behaving nodes never learn the plaintext
password is not without value. Is your SRP math constant time?

Z: No calc time degrades exponentially. 512 right now which is the fastest
safe, but I can take it up to 4096 which is really slow.

D: I mean, constant time relative to the passwords in use?

Z: Ah, I have not checked that. I believe that passwords are hashed to equal
size keys, so in theory? Yes.

Z: Also, there's a known attack where I just return a quick 401 if the user
doesn't exist. Plan is to return bogus replies then.

D: Might as well just ask over twitter -- ultimately, isn't this just
equivalent to iframe/form to autho.me?

Z: Possibly, I haven't looked into that much yet.

D: Suppose you used JS Crypto to RSA encrypt a plaintext u/p from client to
autho.me. Would the semantics change?

Z: Yes I think they would. RSA isn't enough to reliably get auth, you also
need a protocol that establishes the identity.

D: I'm saying, it's just RSA_Enc((username,pw), autho_me.key). That's posted
to customer, customer fwds to autho.me. Equiv?

D: Isn't the username/password the identity?

Z: No, you'd need to work out the exchange protocol. There's ISO methods for
using asymmetric crypto for identity/auth.

D: SRP isn't ISO. SRP is basically password authenticated diffie-helman. What
the user knows is u/p. What autho.me proves is u/p.

D: ...and what you hide from the customer (the web server outsourcing to you)
is u/p. all accurate?

Z: BTW, you fucking rock. The first person to have a rational indepth
discussion about it since I started it. Thank you so much.

D: heh, you wrote the code, that's the hard part. glad to help

~~~
tptacek
_dakami Outsourced auth where well-behaving nodes never learn the plaintext
password is not without value. Is your SRP math constant time?_

 _zedshaw No calc time degrades exponentially. 512 right now which is the
fastest safe, but I can take it up to 4096 which is really slow._

 _dakami I mean, constant time relative to the passwords in use?_

Here's the part where you start to wonder whether both parties in this
conversation know how SRP works. I'm pretty sure Zed knows it (which is why
I'm confused by his comments on this thread).

Kaminsky does start this thread saying a lot of completely reasonable things
about web authentication schemes, for whatever that's worth.

