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