Michael, I will review the comments from Phil where he suggests some changes in section 4.1.4 of the threat model
I am unclear exactly what you are proposing. If you want to propose a clearly worded revamp of that section in the next couple of days, I am willing to review and accept legitimate changes. Clearly worded means concise, technically accurate and devoid of alarmist phrases and words used out of context, such as existential. Can I suggest you review with a colleague before posting here. Regards Mark oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45: > From: > > Michael Thomas <m...@mtcc.com> > > To: > > Phil Hunt <phil.h...@oracle.com> > > Cc: > > Barry Leiba <barryle...@computer.org>, oauth WG <oauth@ietf.org> > > Date: > > 15/12/2011 18:16 > > Subject: > > Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 > > Sent by: > > oauth-boun...@ietf.org > > On 12/15/2011 09:54 AM, Phil Hunt wrote: > > Note: one change recommended below... > > > > With regards to 4.1.4… > > 4.1.4. 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). > > > > > > [mat] I think it's also worth mentioning either here, or in another > > threat that there is a further social engineering misuse/attack where an > > app offers/demands to keep your credentials so that you don't have to go > > through the authorization rigmarole. Users are already conditioned to > > give their credentials up to do things -- just this morning I > noticed facebook > > asking for my email password which they promise with sugar on top to not > > store. It might be worth mentioning that things like CAPTCHA could be > > deployed to defend against that sort of attack/misuse. > > > > [Phil] I don't think we need to really add much here. We could > write whole essays on this topic and likely will. > > > > I think the point is simply to educate the client developer that > there is no need for a client application to ever have access to a > raw uid/password (or any other user credential). > > > > [/Phi] > > > > Remember: I came here not understanding whether this threat was real or not. > A threat document that can't be bothered to elaborate on one of the biggest > existential threats to the protocol is worthless. The way it is worded > now does > not make it crystal clear that, yes, this means UIWebView's in iPhone > apps, etc too. > It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH > SERVER. > > > > [snip] > > > > Countermeasures: > > > > o Client developers and end-user can be educated to trust an > > external System-Browser only. > > > > > > [mat] I assume that this is in here just for the amusement factor because > > it is not a credible countermeasure. > > > > [Phil] I agree, Firefox recently demonstrated how poorly users > recognize the security signals in the browser by dropping the "lock" > icon without announcement. When I found out, I had already been > using it for some time and hadn't noticed. This counter measure > should be changed to: > > > > o The OAuth flow is designed so that client applications never > need to know user passwords. Where possible Client applications > SHOULD avoid directly asking for user credentials during an > authorization flow. > > [/Phil] > > > > The basic problem here is that the client app is not trusted. So if it's > a bad > actor this admonition will be ignored. If it's a good actor, there > wasn't a threat > in first place. So the mitigation completely misses the mark. > > > o Client applications could be validated prior publication in a > > application market. > > > > [mat] How would this be done in practice? > > [Phil] I think this needs to change to: > > > > o Client applications could be validated for acceptable practices > by the Resource Site provider prior to issuing production Client Credentials. > > > > When, exactly, can we expect to see this in the field? Neither Twitter > or Facebook > do this. And even if they were so inclined, the draft provides exactly > zero guidance > as to what exactly that "validated" might mean in practice. The way I > read this is: > "we don't know how to mitigate this". > > [/Phil] > > o Client developers should not collect authentication information > > directly from users and should instead use redirects to and back > > from a trusted external system-browser. > > > > > > [mat] How would the resource/authentication server enforce such a thing? > > > > [Phil] This is a best practice for the client developer. [Phil] > > > > > > I don't even know what that means in the context of embedded apps. > Has anybody even tried this? At the very least, an example flow might > be useful for the uninitiated client developer. > > Mike > _______________________________________________ > 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
