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

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-bounces@ietf.org wrote on 15/12/2011 18:15:45:

> From:
>
> Michael Thomas <mike@mtcc.com>
>
> To:
>
> Phil Hunt <phil.hunt@oracle.com>
>
> Cc:
>
> Barry Leiba <barryleiba@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-bounces@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
>