Just as a response to Andrew, the concern is valid, and providers should be educated to warn users about the possibility of a forged identity. This risk for forgery is actually possible for clients with and without secrets. Anyone can spoof either type if the client ID is known, thus showing the approval dialog on the authorization endpoint. The only difference is that the auth code returned will be useless to the phisher in the case of a client with a secret.
To this point, we always warn our users not to approve an app unless they trust the application that spawned the approval dialog. We emphasize this warning even more when a client_id is presented which can't later validate the identity through use of a secret. As a result of how hard it is to guarantee client identity in these cases, I think you'll find many providers downplay the identity in approval dialogs. The page title often reads something generic like "An application is requesting access to your account" followed then by details of the app. We've refrained from displaying the name or icon too prominently in the top or title of the page for this reason. Certainly, this is kind of guidance to providers is important for the security notes as well as the UI considerations. So, while identity may seem hopeless in theory, it's actually useful as a context check, as Eran suggests. (John's App? why is that asking for permission from this online pharma store?) Moreover, its useful to providers in terms of tracking app usage because in practice, there is very little to be gained in forging an app's identity. You might as well make your own convincing looking app name and icon. Regardless the challenge remains for the providers to track abuse of the API and user data, be it from well-meaning apps, sneaky malicious apps, or mischievous apps masquerading as someone else. skylar On Apr 12, 2011, at 9:28 AM, Eran Hammer-Lahav wrote: > Hopefully by the end of the week. My farm took all my free time this weekend. > > EHL > > From: Torsten Lodderstedt [mailto:[email protected]] > Sent: Tuesday, April 12, 2011 8:54 AM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG ([email protected]) > 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:[email protected]] > Sent: Tuesday, April 12, 2011 8:30 AM > To: Eran Hammer-Lahav > Cc: OAuth WG ([email protected]) > 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 <[email protected]> > 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: [email protected] [mailto:[email protected]] On Behalf Of > Andrew Arnott > Sent: Tuesday, April 12, 2011 7:28 AM > To: OAuth WG ([email protected]) > 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: > • 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. > • 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
