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.
Yeah, what on earth... it seems to be in reverse order, so to start reading I have to scroll down and click more until the entire thing is loaded, then read back up? This is... what.
Yes, this is why Twitter without intelligent clients reformatting all of this garbage (I have to read this backwards to make any sense of it) is unenjoyable for most power users.
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.
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?
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.
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.
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.
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.
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.
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.
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.
I'm not worried, I was merely clarifying what the OP didn't quite understand. The article (and sentiment) is good though, and I've read it before, but apparently there's some interest in a product like Autho.me. Time will tell.
That's fair but I'm using OpenID (and developing a new Django OpenID authentication system) partially because I'm reasonably sure I've kept up with crypto best practices to store passwords safely but I'm also reasonably sure that most developers haven't. I'd rather people just use OpenID rather then fuck everything up.
Best practices for secure password storage really --- and I'm not being hyperbolic --- haven't changed much since the '90s. Poul Henning-Kamp wrote the FreeBSD MD5-based password hash and captured the main problem with secure password storage on his first try. The requirement here is not really evolving.
The reason people (mostly me, admittedly) raise such a stink about this is that using SHA1 or MD5 directly to create password hashes is SO. BAD.; it's actually worse than the original DES crypt(3) function. Web apps created a new instance of the original vulnerability, of people creating terrible new password hashes all the time that are vulnerable to problems addressed in the 1970s.
I can see why, given that stink, you might think it's hard to store passwords. bcrypt is new-ish (it's roughly a decade old), but you don't have to use bcrypt; it's just the best recommendation you can give someone starting from scratch on this problem.
Sure, but I still think you overestimate the general security knowledge of web developers. I wouldn't be terribly surprised to see that most people aren't even hashing the passwords.
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.
1. Remove the worry of security. Look at 90% of the security/password questions on SO/reddit. Almost all the answers are SHA1+Salt.
2. Remove the resource requirement from development. Writing these things takes time and research if you don't know the proper solution. These services can reduce it to an install or a copy and paste.
3. Removing needless database structure. We manage the database (including any sort of movement or upgrading), the customer doesn't have to.
This comes down to the contention between, using the terms I'm going with, a Customer and a User. Let's say you're logging into soawesome.com as a User of soawesome.com. That makes soawesome.com the "Customer", and you the User. Just to setup some terms. Also, let's say I'm not picking on OpenID but really any of the "redirect based" auth methods that transfer ownership of users to a 3rd party.
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.
Query, with regard to paragraph #3: If someone can hack soawesome.com while the User is logged in, does she unconditionally gain the User's login credentials on soawesome.com, ie. can she impersonate the User on soawesome.com from that point on?
[edit]PS. Also, on a different subject, just to see if I got autho.me straight: in the SRP protocol description [1], autho.me would be Steve, correct?
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.
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.
37 comments
[ 2.2 ms ] story [ 63.2 ms ] threadBest 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.
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?
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.
"I'm scared to handle people's passwords. Here's a library that just does it for me, does the right thing, and lets me not worry about it."
That's it. Think of it like installing a plugin to handle your user accounts.
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.
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?
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.
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.
The reason people (mostly me, admittedly) raise such a stink about this is that using SHA1 or MD5 directly to create password hashes is SO. BAD.; it's actually worse than the original DES crypt(3) function. Web apps created a new instance of the original vulnerability, of people creating terrible new password hashes all the time that are vulnerable to problems addressed in the 1970s.
I can see why, given that stink, you might think it's hard to store passwords. bcrypt is new-ish (it's roughly a decade old), but you don't have to use bcrypt; it's just the best recommendation you can give someone starting from scratch on this problem.
("might" because scrypt is relatively new and therefore missing the numerous peer reviews bcrypt has seen).
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.
1. Remove the worry of security. Look at 90% of the security/password questions on SO/reddit. Almost all the answers are SHA1+Salt.
2. Remove the resource requirement from development. Writing these things takes time and research if you don't know the proper solution. These services can reduce it to an install or a copy and paste.
3. Removing needless database structure. We manage the database (including any sort of movement or upgrading), the customer doesn't have to.
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.
[edit]PS. Also, on a different subject, just to see if I got autho.me straight: in the SRP protocol description [1], autho.me would be Steve, correct?
* * *
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...
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.
http://news.ycombinator.com/item?id=2035617
I'm not yet of the legal drinking age, so I'll pass on the beer.
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.
If not, how is it that knowledgeable professionals and hackers are seemingly tossing around the term "Javascript Crypto" with a straight face?