Thanks, Skylar. Eran's and your comments do alleviate my concerns somewhat. In reviewing the security considerations text, which I hadn't seen this morning when writing my earlier email, I feel *much* better. My favorite part is this:
Authorization servers MUST NOT automatically process (without user interaction) repeated authorizations without authenticating the client. > > > By the way, a colleague at Microsoft pointed out that my email signature may lead others on this list to believe I represent Microsoft in my participation on this list. I *do not represent Microsoft* in my participation here. I act as a lone developer. I apologize for any confusion. -- 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 On Tue, Apr 12, 2011 at 3:25 PM, Skylar Woodward <sky...@kiva.org> wrote: > 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: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) > > 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> > 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] On Behalf > Of Andrew Arnott > > Sent: Tuesday, April 12, 2011 7:28 AM > > To: OAuth WG (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: > > • 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 > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
