4 ms·

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 ad

by gst 16y ago

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 16y ago
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 16y ago
  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/ 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.
  - ihodes 16y ago
    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.
  - Locke1689 16y ago
    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.
    - tptacek 16y ago
      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.
      - Locke1689 16y ago
        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.
        tptacek 16y ago
- gst 16y ago
  Thanks for the explanation.
zedshaw 16y ago
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.
- mfukar 16y ago
  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?

by gst 16y ago

ihodes 16y ago

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 16y ago
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/ 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.
- ihodes 16y ago
  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.
- Locke1689 16y ago
  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.
  - tptacek 16y ago
    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.
    - Locke1689 16y ago
      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.
      - tptacek 16y ago
gst 16y ago
Thanks for the explanation.

zedshaw 16y ago

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.

mfukar 16y ago
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?