Please note: I am not claiming that OAuth is insecure in any way. It is a secure protocol for the purposes of data access authorization, for which it was designed. I am just expressing serious doubts that it can be re-targeted for another purpose: authentication.
It is very rarely the case that a protocol designed to provide some security property can be re-targeted for another purpose. On Fri, Apr 17, 2009 at 7:54 AM, Breno <breno.demedei...@gmail.com> wrote: > Example attack: > > Example.com accepts authentication from Example-Provider.com > > User A wants to login as any other user at Example.com to steal the > data that those users have saved at Example.com. > > User A goes to Example.com and clicks on 'sign in using > example-provider.com'; He receives a well-formed request but his > browser has a proxy, so the request is cached instead and his browser > does not follow the redirect. > > User A posts on some blog: You can now login to Example.com using > Example-Provider.com: Click on this URL. The URL points to > Example-Provider.com's authentication endpoint. > > User B clicks on the link and sees a page at Example-Provider.com > asking him/her to authorize Example.com. EV SSL certificates match, > everything looks just fine. User B authorizes. However, the page that > loads at Example.com (after the redirect) is an error message. bummer. > > Later, User A crafts a response from Example-provider.com and visits > Example.com. He is signed as User B. > > The attack is possible because _two_ things hold simultaneously. > > 1. The authentication protocol is not completely executed over a > trusted channel between Example.com and Example-Provider.com: the > browser channel exposes it to the user. > > 2. The authenticator does not issue a signature, so attackers can > craft responses. > > Either (1) or (2) would be sufficient to secure the authentication, > but both fail in OAuth. > > In OpenID authentication is secure because 2 holds. Even in stateless > authentication there is a signature, and the verification of the > signature occurs over a channel that satisfies property 1. > > I am pretty sure it is possible to prove that a protocol that does not > satisfy 1 or 2 is always insecure. I left some details of the attack > above left out, but I doubt there are significant technical hurdles to > make it work. > > On Fri, Apr 17, 2009 at 7:39 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> >> And how is it any different from an OpenID request without association? The >> RP has to go over to the IDP and ask it if the signed request is valid (as >> opposed to if the token/secret pair is valid and authorized). >> >> EHL >> > > > > -- > Breno de Medeiros > -- Breno de Medeiros --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
