7 ms·

OAuth1, OAuth2, OAuth..? (2013)

139 points by neverminder 12y ago

ryusage 12y ago
My understanding from my research into OAUTH2 is that most of the vulnerabilities in it are only issues in a naive implementation. They can be made secure, but it's not easy and you have to know to do it in the first place. Doesn't OpenID Connect address those issues? I know that's what Google is using now.
thomasfl 12y ago
This article is just technical enough for me. As a developer implementing security can be a pain in the ass. All I wan't is someone to tell if a protocol is secure, and get done with it.
- smt88 12y ago
  That's the kind of attitude that leads to massive security flaws. Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people.
  - IgorPartola 12y ago
    Agreed, but there is a difference between understanding, let's say, how PKI works and how it applies to HTTPS vs knowing how to implement AES. Sometimes, we just need to know that SSL 3 is broken, and don't need to know the exact details. All we then need to know is to stop using it.
    - smt88 12y ago
      My comment was more generalized, as it was responding to a general comment. However, I will say that HTTPS is not too complicated to understand and that it's not a magic bullet. You still need to understand, for example, how a certificate can be compromised and what the pros/cons are of different implementations. It's not a simple "yes or no", even though it's close.
  - untog 12y ago
    I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.
    - smt88 12y ago
      See my comment above. There's a lot more to protecting a site from man-in-the-middle attacks than enabling HTTPS. The most important things people need to know are the pros/cons of different types of certificates, how to keep certificates safe, and whether they have a vulnerable SSL library installed. Again, it's not a binary.
    - rcxdude 12y ago
      "Secure or not" is not a meaningful distinction. "Secure" means a lot of different properties which may be of varying importance to different people and applies to the whole system, not individual components. So the only meaningful interpretation of 'secure' for a subcomponent is "Does it achieve the security properties it aims to?". It does not excuse from learning what those properties are, what they mean, and their implications for the security of the system as a whole.
      - binky56 12y ago
        Valid point. Even encryption is only "secure" for a limited time. I could sniff the traffic, store the data and wait until the encryption is crackable. For most transactions that is good enough as our passwords are probably not relevant in 10 years. For some transactions it may not be enough because you probably would have the same bank account in 10 years. Granted the cost to capture and save for a later date probably outweighs the potential to exploit. At the same time I would not expect a front end JS/CSS developer to know the specifics of the entire system, only the parts of his/her subsystem. That is to say they should know XSS/CSRF like the back of their hand, but probably don't need to fully understand a stack overflow. On the other hand if you write C/C++ or any other low/mid level language XSS probably means nothing to you and stack overflow is highly important.
    - adamtj 12y ago
  - smt88 12y ago
    To the downvoters: if you stick your head in the sand, you'll do things like using MD5 for password hashing and logging into remote servers as root. I see basic mistakes like that all the time. I'll reiterate (and this is a general comment, not necessarily about HTTPS): if you aren't willing to understand how software works and how people attack it, don't write it professionally. It's part of your job and your responsibility to your customers and their users. When systems are cracked, it can leak financial info, passwords, addresses, children's names, medical info, etc., etc. You may have a totally innocuous site that helps someone get into one of your user's more sensitive accounts. Security is really important and failing to understand it can ruin people's lives. I've personally seen it happen. It worries me that saying something as simple and unassailable as "understand the security implications of your code" got downvoted on a "hacker" site so many times.
    - new299 12y ago
      I think it's because you wrote: "Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people." Which is a very direct and negative comment. Not all software significantly touches on security. People write one off programs for generating musical compositions, one off pieces of data analysis. Proof of concepts that aren't designed to ship and any number of non-internet connected programs where the security considerations are less significant. If you didn't mean those applications, then your comment amounts to "people writing security sensitive software should be mindful of security". Which is so redundant as to be meaningless. Telling people "you have no right to be programming" on a hacker forum is unlikely to make you many friends.
      - smt88 12y ago
        Yes, I was being direct and negative. I was responding to someone who wanted to be a developer and not have to understand security. That kind of attitude/culture is what makes so many thousands of widely-used applications vulnerable. Security shouldn't be an afterthought. People trust us to write secure software, and few of us do. The key word in my comment was "professionally". I'm not telling someone experimenting for fun to learn detailed security implications. I'm talking to someone who is charging someone (clients or employers) for their work. And what I said is, sadly, not so redundant as to be meaningless because I was responding to someone who said "I don't want to be mindful of security, just tell me if [XYZ] works." So obviously it DID need to be said!
  - thomasfl 12y ago
    You are probably right. I would be pleased to be directed to some good sources about cryptography.
- cobralibre 12y ago
  I don't know about that — it helps to have more than superficial knowledge of the topic at hand so that you can adequately assess rants such as this one. Personally, while I feel that Igor Homakov has done good work, this article is the product of frustration and is a disservice to its audience. Most if not all of his criticisms of OAuth 2 come down to implementation problems, and a more positive contribution would be an implementers' guide or a threat model document. For example, https://tools.ietf.org/html/rfc6819 https://tools.ietf.org/html/rfc6819 and http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabilities-and-mitigation-techniques/ http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabi....
deleted 12y ago
[deleted]
higherpurpose 12y ago
Will this be of any help once browsers implement it? http://cowl.ws/ http://cowl.ws/
ademarre 12y ago
With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did. Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec. Vector #6 (Phishing by spoofed client) has always been particularly interesting to me, and it applies to both OAuth2 and OAuth1. I dont see it as a protocol flaw but an attack vector service providers need to be more aware of. While OAuth2 was in draft, I reported it to Facebook, Google, Twitter and the OAuth WG. Facebook addressed it by displaying the domain name of the client on their authorization dialog, but they eventually got rid of that. Google also acknowledged the vulnerability and said they would rely on policing registered clients to catch it. Twitter never responded. The WG asked me to propose text for the security considerations document, but I dropped the ball (too swamped) and couldn't do it in time.
- nijiko 12y ago
  Thank you for this, was about to post the exact same reply.
- dmak 12y ago
  How does Google police registered clients? Does anyone else do this?
  - ademarre 12y ago
    Good question. I dug up the e-mail from 2012 and here's what the Google Security Team told me: > We're deploying some abuse detection and reactive measures to deal with impostors that might try to abuse this sort of attack. Surely any OAuth2 service provider will disable clients that are caught misbehaving.
- homakov 12y ago
  > this is pretty much a list of implementation flaws, not protocol flaws I can agree with that but problems outlined are very common so it doesn't really matter. Say, Facebook is major oauth2 provider and doesn't follow most of the spec. As well as lots of popular libraries.
paulannesley 12y ago
Article looks familiar, and was published March 1, 2013.
- sctb 12y ago
  Thanks, we updated the title.
cratermoon 12y ago
OpenID-Connect (which is really OAuth2 with a specified auth/profile flow)
peter_l_downs 12y ago
I've written an OAuth2 server implementation and to be honest, I still don't really understand why people use OAuth2 instead of OAuth1.0a. The minimum amount of work you have to do to write an implementation that complies with the spec leaves you open to all sorts of security issues (as Homakov continues to detail), no two providers implement the same parts of the spec so writing clients isn't really all that easy, and the "security" features don't really seem all that secure. For example, refresh tokens, what the fuck? If an attacker can steal your access token why would you assume that your refresh tokens are safe? How is it ok to say "well, even if your access token is stolen at least it will expire eventually, so don't worry"? /rant.
- nijiko 12y ago
  It requires the client id and secret to obtain a refresh token, some also choose to skip this and ask the user to re-authenticate completely. I agree that people implement it differently so vastly different that it takes almost 40 sources to compile a decent down-to-earth explanation of common practices (same for OAuth 1.0a). However, that doesn't make the protocol bad, it makes the implementation bad, you can avoid XSS, OOS Origin Attacks, and the others with the exception of Vector attacks, but both are vulnerable to this.
  - peter_l_downs 12y ago
    That's fair, I guess what I'm trying to say is that if the spec leads to broken/vulnerable implementations in the majority of cases there might be reason for concern. One thing I think OAuth 2 gets right is the entire concept of scoped authorization; although not unique to OAuth2, it's now familiar to users largely because Facebook and Google adopted it through OAuth 2.
- tboyd47 12y ago
  I had to write one too, and feel exactly the same way. The common argument for OAuth2 seems to be, "Well, Google and Facebook are doing it, so it must be worth something." Of course Google and Facebook are doing it; it lets them play the role of the official identity keepers of the internet. Those companies are known to pick the best and the brightest engineers, yet exploits were found in even their versions of OAuth2. If they couldn't produce a secure implementation, then can anyone?
deleted 12y ago
[deleted]
- scrollaway 12y ago
  Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this situation. I get sad trying to promote it. I get the feeling that whoever is in charge of decisions around Persona has no idea how important a project like it is for the web. Everybody is tying a core and extremely security-sensitive part of their websites, authentication, to other websites in a non-decentralized way. And every time there's a damn post about "Facebook auth is down!", "Twitter auth is down!"... how long is it going to be until those are down for good and people just can't log in anymore? Blergh. Sad.
  - scott_w 12y ago
    I agree with you. I looked into Persona to implement an SSO for our products (provider and client). I've never been able to understand OAuth in the context of an authentication mechanism so I left it. However, Persona has very poor library support, especially for providers. The support channels are also very small, so you're not likely to find other people fixing the same issues. I ended up just hacking an OpenID provider libary to get the result I wanted. It's a real shame because Persona seemed to be designed for circumstances very similar to what I wanted to do.
    - dorfsmay 12y ago
      If you want to talk more about persona and try to promote it (brand new mailing list): persona.advocacy atsign librelist dot com send an email to subscribe, the first email will be
      - scrollaway 12y ago
Luker88 12y ago
I have written an implementation for OAuth1 and OAuth2. I liked the protocol/framework so little that I started implementing a new one. But soon I realized that a lot of the difficulties come from having this thing run on top of HTTP, and that I could not access any security feature of the lower levels. So (IMHO) everything implemented on top of HTTP, or the whole idea of having isolated layers of security is doomed to have problems and will cause headaches to anyone working with it, aside from requiring developers to be security experts. But I still didn't stop and my master thesis now is a complete secure rewrite of protocols from tcp, tls to OAuth. The project is on fenrirproject.org if you want to comment it. Lots of work, I am aiming to an implementation in half a year. Please feel free to drop me a line.
sandstrom 12y ago
I know Homakov is very talented, I really like his work! But I find the article difficult to parse. Anyone know of a technical but more accessible article on the 5-6 points he mentions?
- homakov 12y ago
  Check oauthsecurity.com
chris_wot 12y ago
A comment was made the other day here: https://news.ycombinator.com/item?id=8831504 https://news.ycombinator.com/item?id=8831504 I was confused as to whether OAuth was authentication or authorization... so which is it?
homakov 12y ago
This is relevant oauthsecurity.com

139 points by neverminder 12y ago

My understanding from my research into OAUTH2 is that most of the vulnerabilities in it are only issues in a naive implementation. They can be made secure, but it's not easy and you have to know to do it in the first place. Doesn't OpenID Connect address those issues? I know that's what Google is using now.

thomasfl 12y ago

This article is just technical enough for me. As a developer implementing security can be a pain in the ass. All I wan't is someone to tell if a protocol is secure, and get done with it.

smt88 12y ago
That's the kind of attitude that leads to massive security flaws. Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people.
- IgorPartola 12y ago
  Agreed, but there is a difference between understanding, let's say, how PKI works and how it applies to HTTPS vs knowing how to implement AES. Sometimes, we just need to know that SSL 3 is broken, and don't need to know the exact details. All we then need to know is to stop using it.
  - smt88 12y ago
    My comment was more generalized, as it was responding to a general comment. However, I will say that HTTPS is not too complicated to understand and that it's not a magic bullet. You still need to understand, for example, how a certificate can be compromised and what the pros/cons are of different implementations. It's not a simple "yes or no", even though it's close.
- untog 12y ago
  I only partly agree with you. Every developer does not need to know exactly how HTTPS encryption algorithms work, just whether they are secure or not.
  - smt88 12y ago
    See my comment above. There's a lot more to protecting a site from man-in-the-middle attacks than enabling HTTPS. The most important things people need to know are the pros/cons of different types of certificates, how to keep certificates safe, and whether they have a vulnerable SSL library installed. Again, it's not a binary.
  - rcxdude 12y ago
    "Secure or not" is not a meaningful distinction. "Secure" means a lot of different properties which may be of varying importance to different people and applies to the whole system, not individual components. So the only meaningful interpretation of 'secure' for a subcomponent is "Does it achieve the security properties it aims to?". It does not excuse from learning what those properties are, what they mean, and their implications for the security of the system as a whole.
    - binky56 12y ago
      Valid point. Even encryption is only "secure" for a limited time. I could sniff the traffic, store the data and wait until the encryption is crackable. For most transactions that is good enough as our passwords are probably not relevant in 10 years. For some transactions it may not be enough because you probably would have the same bank account in 10 years. Granted the cost to capture and save for a later date probably outweighs the potential to exploit. At the same time I would not expect a front end JS/CSS developer to know the specifics of the entire system, only the parts of his/her subsystem. That is to say they should know XSS/CSRF like the back of their hand, but probably don't need to fully understand a stack overflow. On the other hand if you write C/C++ or any other low/mid level language XSS probably means nothing to you and stack overflow is highly important.
  - adamtj 12y ago
- smt88 12y ago
  To the downvoters: if you stick your head in the sand, you'll do things like using MD5 for password hashing and logging into remote servers as root. I see basic mistakes like that all the time. I'll reiterate (and this is a general comment, not necessarily about HTTPS): if you aren't willing to understand how software works and how people attack it, don't write it professionally. It's part of your job and your responsibility to your customers and their users. When systems are cracked, it can leak financial info, passwords, addresses, children's names, medical info, etc., etc. You may have a totally innocuous site that helps someone get into one of your user's more sensitive accounts. Security is really important and failing to understand it can ruin people's lives. I've personally seen it happen. It worries me that saying something as simple and unassailable as "understand the security implications of your code" got downvoted on a "hacker" site so many times.
  - new299 12y ago
    I think it's because you wrote: "Understanding security is more than just "yes or no". You must understand the concepts. If you don't, stop professionally writing software, because you're doing something irresponsible that will do real harm to real people." Which is a very direct and negative comment. Not all software significantly touches on security. People write one off programs for generating musical compositions, one off pieces of data analysis. Proof of concepts that aren't designed to ship and any number of non-internet connected programs where the security considerations are less significant. If you didn't mean those applications, then your comment amounts to "people writing security sensitive software should be mindful of security". Which is so redundant as to be meaningless. Telling people "you have no right to be programming" on a hacker forum is unlikely to make you many friends.
    - smt88 12y ago
      Yes, I was being direct and negative. I was responding to someone who wanted to be a developer and not have to understand security. That kind of attitude/culture is what makes so many thousands of widely-used applications vulnerable. Security shouldn't be an afterthought. People trust us to write secure software, and few of us do. The key word in my comment was "professionally". I'm not telling someone experimenting for fun to learn detailed security implications. I'm talking to someone who is charging someone (clients or employers) for their work. And what I said is, sadly, not so redundant as to be meaningless because I was responding to someone who said "I don't want to be mindful of security, just tell me if [XYZ] works." So obviously it DID need to be said!
- thomasfl 12y ago
  You are probably right. I would be pleased to be directed to some good sources about cryptography.
cobralibre 12y ago
I don't know about that — it helps to have more than superficial knowledge of the topic at hand so that you can adequately assess rants such as this one. Personally, while I feel that Igor Homakov has done good work, this article is the product of frustration and is a disservice to its audience. Most if not all of his criticisms of OAuth 2 come down to implementation problems, and a more positive contribution would be an implementers' guide or a threat model document. For example, https://tools.ietf.org/html/rfc6819 https://tools.ietf.org/html/rfc6819 and http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabilities-and-mitigation-techniques/ http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabi....

deleted 12y ago

[deleted]

higherpurpose 12y ago

Will this be of any help once browsers implement it? http://cowl.ws/ http://cowl.ws/

ademarre 12y ago

With the exception of vector #6, this is pretty much a list of implementation flaws, not protocol flaws. It's as if he's trying to say that the protocol isn't written defensively enough or foolproof enough for implementors, and he might have a good point if he simply said that, but he never did. Even with an OAuth library for the nuts and bolts, to implement an OAuth2 authorization server requires grokking the spec. Vector #6 (Phishing by spoofed client) has always been particularly interesting to me, and it applies to both OAuth2 and OAuth1. I dont see it as a protocol flaw but an attack vector service providers need to be more aware of. While OAuth2 was in draft, I reported it to Facebook, Google, Twitter and the OAuth WG. Facebook addressed it by displaying the domain name of the client on their authorization dialog, but they eventually got rid of that. Google also acknowledged the vulnerability and said they would rely on policing registered clients to catch it. Twitter never responded. The WG asked me to propose text for the security considerations document, but I dropped the ball (too swamped) and couldn't do it in time.

nijiko 12y ago
Thank you for this, was about to post the exact same reply.
dmak 12y ago
How does Google police registered clients? Does anyone else do this?
- ademarre 12y ago
  Good question. I dug up the e-mail from 2012 and here's what the Google Security Team told me: > We're deploying some abuse detection and reactive measures to deal with impostors that might try to abuse this sort of attack. Surely any OAuth2 service provider will disable clients that are caught misbehaving.
homakov 12y ago
> this is pretty much a list of implementation flaws, not protocol flaws I can agree with that but problems outlined are very common so it doesn't really matter. Say, Facebook is major oauth2 provider and doesn't follow most of the spec. As well as lots of popular libraries.

paulannesley 12y ago

Article looks familiar, and was published March 1, 2013.

sctb 12y ago
Thanks, we updated the title.

cratermoon 12y ago

OpenID-Connect (which is really OAuth2 with a specified auth/profile flow)

peter_l_downs 12y ago

I've written an OAuth2 server implementation and to be honest, I still don't really understand why people use OAuth2 instead of OAuth1.0a. The minimum amount of work you have to do to write an implementation that complies with the spec leaves you open to all sorts of security issues (as Homakov continues to detail), no two providers implement the same parts of the spec so writing clients isn't really all that easy, and the "security" features don't really seem all that secure. For example, refresh tokens, what the fuck? If an attacker can steal your access token why would you assume that your refresh tokens are safe? How is it ok to say "well, even if your access token is stolen at least it will expire eventually, so don't worry"? /rant.

nijiko 12y ago
It requires the client id and secret to obtain a refresh token, some also choose to skip this and ask the user to re-authenticate completely. I agree that people implement it differently so vastly different that it takes almost 40 sources to compile a decent down-to-earth explanation of common practices (same for OAuth 1.0a). However, that doesn't make the protocol bad, it makes the implementation bad, you can avoid XSS, OOS Origin Attacks, and the others with the exception of Vector attacks, but both are vulnerable to this.
- peter_l_downs 12y ago
  That's fair, I guess what I'm trying to say is that if the spec leads to broken/vulnerable implementations in the majority of cases there might be reason for concern. One thing I think OAuth 2 gets right is the entire concept of scoped authorization; although not unique to OAuth2, it's now familiar to users largely because Facebook and Google adopted it through OAuth 2.
tboyd47 12y ago
I had to write one too, and feel exactly the same way. The common argument for OAuth2 seems to be, "Well, Google and Facebook are doing it, so it must be worth something." Of course Google and Facebook are doing it; it lets them play the role of the official identity keepers of the internet. Those companies are known to pick the best and the brightest engineers, yet exploits were found in even their versions of OAuth2. If they couldn't produce a secure implementation, then can anyone?

deleted 12y ago

[deleted]

scrollaway 12y ago
Ah, but if only people switched to Persona. If only people looked into it more than 5 minutes and realized that Persona is still maintained and is by far the best way to do authentication on the web. Really, the most correct protocol out there. But then of course, if only Mozilla had a marketing team worth a damn and didn't make it look like they gave up on the whole thing in the first place, we wouldn't have this situation. I get sad trying to promote it. I get the feeling that whoever is in charge of decisions around Persona has no idea how important a project like it is for the web. Everybody is tying a core and extremely security-sensitive part of their websites, authentication, to other websites in a non-decentralized way. And every time there's a damn post about "Facebook auth is down!", "Twitter auth is down!"... how long is it going to be until those are down for good and people just can't log in anymore? Blergh. Sad.
- scott_w 12y ago
  I agree with you. I looked into Persona to implement an SSO for our products (provider and client). I've never been able to understand OAuth in the context of an authentication mechanism so I left it. However, Persona has very poor library support, especially for providers. The support channels are also very small, so you're not likely to find other people fixing the same issues. I ended up just hacking an OpenID provider libary to get the result I wanted. It's a real shame because Persona seemed to be designed for circumstances very similar to what I wanted to do.
  - dorfsmay 12y ago
    If you want to talk more about persona and try to promote it (brand new mailing list): persona.advocacy atsign librelist dot com send an email to subscribe, the first email will be
    - scrollaway 12y ago

Luker88 12y ago

I have written an implementation for OAuth1 and OAuth2. I liked the protocol/framework so little that I started implementing a new one. But soon I realized that a lot of the difficulties come from having this thing run on top of HTTP, and that I could not access any security feature of the lower levels. So (IMHO) everything implemented on top of HTTP, or the whole idea of having isolated layers of security is doomed to have problems and will cause headaches to anyone working with it, aside from requiring developers to be security experts. But I still didn't stop and my master thesis now is a complete secure rewrite of protocols from tcp, tls to OAuth. The project is on fenrirproject.org if you want to comment it. Lots of work, I am aiming to an implementation in half a year. Please feel free to drop me a line.

sandstrom 12y ago

I know Homakov is very talented, I really like his work! But I find the article difficult to parse. Anyone know of a technical but more accessible article on the 5-6 points he mentions?

homakov 12y ago
Check oauthsecurity.com

chris_wot 12y ago

A comment was made the other day here: https://news.ycombinator.com/item?id=8831504 https://news.ycombinator.com/item?id=8831504 I was confused as to whether OAuth was authentication or authorization... so which is it?

homakov 12y ago

This is relevant oauthsecurity.com