On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivst...@gmail.com] >> Sent: Thursday, August 18, 2011 10:16 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> > Can you provide another example with the same level of detail as you provided > below?
The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, to finally receive an access token/authorization code in the redirection. > CAPTCHA and password entry are two completely difference measures and are > rarely interchangeable. CAPTCHA does nothing more than increase the > likelihood that the entity on the other side is a human. Any attack prevented > by CAPTCHA must be one in which automation and speed are crucial. I still > don't understand what it *solves*. CAPTCHAs are used for human testing and passwords for identity testing, but in this case they both serve the same purpose of decreasing the likelihood that the flow is automated. > Two-factor authentication is good, but completely impractical for most web > authorization scenario. You need to remember that the authorization page is > used for both the initial grant, but also for delegated login (by far a more > frequent use). An access token can be issued almost automatically if the > client has been previously authorized. You're right, sometimes there's a trade-off between better security and user experience. I think it should eventually be up to the implementer to choose what is right for their applications' security requirements. I think it is in the scope of the specification to bring this issue up for developers to consider. > I don't understand this "family of attacks". I don't know how to put it any differently than I already have; simply a class of attacks (the three scenarios described in this thread are examples thereof) in which a malicious client takes the role of both the client and the resource owner. -- Niv _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
