Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OAuth1, OAuth2, OAuth..? (2013)

homakov.blogspot.com

Post reply on HN
Print view View original

1–10 of 50 posts

Re: OAuth1, OAuth2, OAuth..? (2013)

#3

Post by smt88 »

thomasfl wrote: post #2

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.

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.

Re: OAuth1, OAuth2, OAuth..? (2013)

#4

Post by IgorPartola »

smt88 wrote: post #3
thomasfl wrote: post #2

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.

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.

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.

Re: OAuth1, OAuth2, OAuth..? (2013)

#5

Post by untog »

smt88 wrote: post #3
thomasfl wrote: post #2

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.

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.

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.

Re: OAuth1, OAuth2, OAuth..? (2013)

#7

Post by cobralibre »

thomasfl wrote: post #2

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.

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 and http://leastprivilege.com/2013/03/15/common-oauth2-vulnerabi....

Re: OAuth1, OAuth2, OAuth..? (2013)

#9

Post by ademarre »

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.

Post reply on HN