Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011

[Michael Thomas <[e-mail]>]

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