Hopefully by the end of the week. My farm took all my free time this weekend.
EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Tuesday, April 12, 2011 8:54 AM To: Eran Hammer-Lahav Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] client authentication for implicit grant type The proposed text already does (http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02). When will you post the new revision of the core draft that includes the proposed text? regards, Torsten. Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav: It should include a section on phishing-like attacks. EHL From: Andrew Arnott [mailto:andrewarn...@gmail.com] Sent: Tuesday, April 12, 2011 8:30 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] client authentication for implicit grant type Thanks, Eran. Will the security considerations section discuss this and recommend that auth servers warn the users of the potential phishing attack? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: I don't think there is much we can do either way to prevent these phishing-like attacks with or without the client identifier. The key to security here is the ability of the end-user to keep track of how it got there, and based on that decide if they want to grant access to whoever sent them to the authorization endpoint. This is the same problem with phishing - the user ends up in a login page and unless they pay attention how they go there (and where they are if its possible to assert), they will give the attacker their password. If you don't include the client identifier and won't give them a hint "John's App wants access", they will just get used to approving it without the hint. At the end of the day, if there is value in approving such unidentified clients, end-users will do it regardless of security. EHL From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of Andrew Arnott Sent: Tuesday, April 12, 2011 7:28 AM To: OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: [OAUTH-WG] client authentication for implicit grant type I brought this concern up about a year ago. Now reviewing the latest drafts, I still have a concern with it. It is regarding the use of client_id without a password. I agree with section 3, as included below: Section 3. Client Authentication The client identifier is not a secret, it is exposed to the resource owner, and MUST NOT be used alone for client authentication. Client authentication is accomplished via additional means such as a matching client password. The above tells me (rightly so IMO) that considering the client_id alone (without real authentication) is dangerous. Yet the Implicit Grant type accepts a client_id, but no authentication: Section 4.2 Implicit Grant client_id REQUIRED. The client identifier as described in Section 3. Now here me: I am not advocating for a client_secret in this case. I fully understand that some clients, particularly javascript widget clients that are embedded in others' web pages, can't keep secrets. What I am advocating is that clients that can't keep secrets shouldn't have IDs either. This is a wide-open door for clients to obtain access to protected user data by lying about their identity to authorization servers. They can achieve this in either of two ways, given some popular client_id we'll arbitrarily call 'facebook' that users are accustomed to authorizing access to: 1. An evil client can redirect the user to the authorization endpoint, requesting an implicit grant, and including client_id=facebook in the URL. The authorization server may ask the user "Do you want to give Facebook access?" along with (perhaps) a warning that most users won't know what to do about (honestly, most technical users wouldn't know how to verify either. The user, who trusts Facebook, will click Accept, and offer whatever rogue client was running on the page they were visiting the access that they requested. 2. In scenario 2, which is far worse, an evil client can redirect the user to the authorization endpoint, requesting an implicit grant, and including client_id=facebook in the URL. Same so far, but in this case, the authorization server sees that access has already been authorized by the resource owner to this client in the past and immediately redirects back with the requested access token, no user involvement whatsoever. Again, the client obtains access. Now, one might say to #2 that authorization servers shouldn't automatically authorize implicit requests. That person would be absolutely right. I'm concerned that enough clients will complain about the user experience though that authorization servers will yield to them and begin auto-authorizing these, justifying it by making the "limited" access tokens. No go. Either you have protected data or you don't. To #1, there's no way that I can think of to properly educate the user to be able to detect a phishing attack of this nature, such that if they see a "do you want to authorize facebook?" when there is no facebook widget on the page, that they should deny access. Between those two, I see only negative impact to including client_id in implicit grant requests. Please, will someone either address my concerns (tell me where I'm wrong) or remove that parameter from this grant type? Thanks for your time. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
