Having read the suggested wording from Eran, William and Michael, I think Eran's description is the most succinct and relevant: "OAuth does not provide any protection against malicious applications and that the end user is solely responsible for the trustworthiness of any native application installed" @William: The threat has been described in the context of installing malicious apps so the wording above it more applicable @Michael: It has been repeated many times that we should only address security issues specific to Oauth, and Oauth does not make things worse if a user installs a malicious client. If you want to continue the discussion, please email me directly and we can revert to this forum if you still think your point is relevant
Section 4.1.4 of the threat model will be updated as below. Remember the threat model is just offering advice on best practices. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/password). Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password. Countermeasures: 1. The OAuth flow is designed so that client applications never need to know user passwords. Client applications SHOULD avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed 2. Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way 3. Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser. Regards Mark oauth-boun...@ietf.org wrote on 05/01/2012 00:05:04: > From: > > Eran Hammer-Lahav <e...@hueniverse.com> > > To: > > Michael Thomas <m...@mtcc.com>, Torsten Lodderstedt <tors...@lodderstedt.net> > > Cc: > > Barry Leiba <barryle...@computer.org>, oauth WG <oauth@ietf.org> > > Date: > > 05/01/2012 00:05 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > Sent by: > > oauth-boun...@ietf.org > > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Michael Thomas > > Sent: Wednesday, January 04, 2012 3:40 PM > > > My concern is that putting on a veneer of "security" will lull people into > > thinking "Oh, it's safe to enter my credentials here because this is really > > twitterbook, not evilapp!". When I had to ask them directly to put their > > twitterbook credentials into my app, there at least wasn't any > confusion that > > I had access to them. > > This is ridiculous (e.g. the fact we are still discussing this). > > First, end users know nothing about security or OAuth. Second, evil > apps can create this veneer of security by faking a redirection flow > with or without OAuth. Suggesting that OAuth (which is a de-facto > web pattern for over a decade) makes anything worse is patently false. > > The only thing we can possibly add to the threat model document is > to mention that "OAuth does not provide any protection against > malicious applications and that the end user is solely responsible > for the trustworthiness of any native application installed". That > is accurate (and completely obvious to the target audience of this > document). It is not very helpful but if it will make you feel > better (since no one else here seems to share your concerns), I have > no objection to such one line added. > > And again, to highlight the absurdity of your security claim, it is > equally important to warn developers in earthquake-prone countries > to put enough distance between the Approve and Deny buttons so that > the user will not accidentally hit Approve during a tremor. > > EHL > > > > > > _______________________________________________ > 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
