Zed Shaw & Dan Kaminsky Talk About Autho.me on Twitter

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.

The difference in design is that OpenID assumes that the Customer is less trustworthy than the OpenID Provider+User. They've done a good job marketing this idea that you can't trust sites and so you, the User, should use OpenID. If you think about that it's kind of idiotic to assume that you're going to log into an untrusted site using another site (which could also be untrusted). It also assumes that most web users are savvy enough to know what this is, but if you were up on the ReadWriteWeb/Facebook fiasco you know most users can't tell their ass from a hole in the ground. OpenID is just confusing to them.

The truth is, if I can phish and XSS one site I can do it to another site. If someone can hack soawesome.com, they can hack your OpenID provider of choice too. All the attacks you have against one auth system apply to all auth systems because security in the browser is fairly broken. It's really completely a usability problem, and no amount of redirecting and bouncing around with crypto is going to solve that.

However, this mistrust of the Customer means that there's a huge risk for the Customer against the Provider. At any moment the Provider can decide they hate the Customer and turn off all the users. This actually happens often enough that it worries people to the point they put links to about 10 OpenId sites.

I'm trying to offer a solution that assumes the Customer is trusted and should own their Users, but that gives them a simple enough setup process that it competes with OpenID for simplicity of configuration (which isn't hard because OpenID is a pain in the ass). It should also give the Customer plausible deniability on password storage so, in the event of a breach, they don't lose anything. I'm also focusing on making this mobile/desktop device friendly, something that OpenID and OAuth totally fail at.

This Customer v. User contention is the most likely the point of contention you have in your comment: you believe you own your user account, but customers believe they own it. I'm actually not sure what's the answer, but autho.me is kind of an experiment in doing it the other way.

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.

* * *

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

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.