Re: [OAUTH-WG] client embedded browsers (was: I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt)

[Michael Thomas <[e-mail]>]

On 12/15/2011 09:32 AM, Mark Mcgloin wrote:
> Hi Michael
>
> We reviewed the threat model document in light of the concerns you raised
> (originally in a thread called "Problem Statement") and decided that we
> already provided enough information on threats and countermeasures from
> malicious applications.
>
> In addition, the consensus from the Oauth WG on that email thread ("Problem
> Statement") was that the issue of users installing malware or any malicious
> client is not an oauth specific problem and is not something we need to
> educate users on, over and above what is stated already in section 4.1.4 of
> the threat model. Based on that consensus, I would consider this issue
> closed and we will not be making any changes to the threat model
>
>    

Excuse me, but I was told that my comments would be better
addressed in the threats document, and now you tell me that
you can't be bothered to address them in the threats document
either. I find this completely dismissive of the real life problems
that this protocol will face.

This *is* an OAUTH specific problem because OAUTH is being
deployed massively into the threat environment it claims to
protect against. It doesn't protect them, and as far as I can
see there is nothing but hand waving dismissal rather than
advice about how to deal with the problem. The bad guys
don't care about your head-in-sand dismissal, and the
reemergence native apps are a fact of life now.

Mike


>
> Regards
> Mark McGloin
>
> On Wed, 26 Oct 2011 13:17:58 , "Michael Thomas"<mike at mtcc.com>  wrote:
>
> First, I think that this threat should be elevated to something more than
> a threat because it is a fundamental assumption of the protocol that the
> browser is trustworthy. I have heard far too many people on this list say
> that that's silly because it is "obvious" but it is not obvious to the
> uninitiated, who are the remaining 7*10^9-100 people in this world.
>
> Second, I think it's worth explicitly pointing out that this PERTAINS TO
> APPS
> too. The world has changed significantly since OAUTH was conceived, and
> native phone, etc apps continue to grow explosively after a long, long
> decline leading up to OAUTH's birth. I would venture to say that a sizable
> if not majority of uses of OAUTH will be in app settings.
>
> A few inline comments:
>
> 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.
>
>     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:
>
>     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.
>
>     o  Client applications could be validated prior publication in a
>        application market.
>
> [mat] How would this be done in practice?
>
>     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?
>
> The main problem here is that the countermeasures -- if they are practical
> at all --
> are deep and complex problems unto themselves. To just handwave them away
> does
> no justice to the seriousness of the threat. I realize that this strays
> more
> into BCP land but there isn't any B-C-P, and I'm not terribly convinced
> there ever will be. In that respect, I think this threat and its potential
> countermeasures need to be discussed in much more detail. If there is
> anything
> about OAUTH that will cause it to be junked, it's this threat.
>
> Mike
>
> ----------------------------------------------------------------------------------------------------
>
> Mark McGloin
> e-mail: [e-mail]
> Tel: [phone]
> Mobile: [phone]
> Security Architect, LotusLive and Cloud Business Support Systems
> IBM Software Group
> Building 6, IBM Technology campus, Damastown Industrial Estate, Mulhuddart,
> Dublin 15
>
> IBM International Holdings BV registered in Ireland with number 903924.
> Registered office: Oldbrook House, 24-32 Pembroke Road, Ballsbridge, Dublin
> 4
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>