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

[Justin Richer <[e-mail]>]

I'm OK with the threat document including a line this this, or Eran's 
proposed text, in the introduction to what OAuth can and can't do. It's 
important to set scope appropriately. (and I am very sorry for that pun)

However, the contention about native apps that Mike brings up is 
misleading for one key reason: if the user's browser is compromised 
(which is the attack vector in question), then all OAuth-backed webapps 
will *also* be compromised, since the bad party can just grab the data 
on its way to the screen. And if the user downloads malware masquerading 
as a good app (which OAuth *can* protect against by using client secrets 
in some circumstances and trusted callback urls in others), and they 
approve the bad app, then they're hosed too.

So, no, OAuth won't protect you against malware-infested browsers or 
against phishing. It significantly reduces but does not eliminate 
security threats, and (a point that hasn't been brought up) it 
significantly eases the cleanup burden on users and service providers in 
the case of a breach. If this really is a confusing point to people, we 
can say that in the threat document, and Bill's text would do that, 
without the addendum about native clients. I believe that the native 
client text that speaks about embedded vs. external browsers is already 
clear on this matter -- but if someone has better text (as in, 
"paragraph X should say the following exact words", not "it needs to be 
better"), then we can incorporate it.

Even so, I do think it's clear from what text we already have. It would 
be superfluous but not burdensome to add extra text into the threat 
model document (not core) as has been proposed here by Bill and 
previously be Eran.

  -- Justin

On 01/04/2012 06:58 PM, Michael Thomas wrote:
> On 01/04/2012 03:42 PM, William Mills wrote:
>> I think the threat draft should simply say, "OAuth does not and can 
>> not protect the user against credential compromise as a result of 
>> phishing, malware, social engineering, or machine compromise."
>
> I could live with something like this, but I think it needs to be much 
> more
> explicit that it applies to any authentication service that allows 
> native apps as clients
> with no form of strong app vetting. It may even be useful to point to 
> a couple of
> large deployments who are at risk from this, like, oh say, twitterbook.
>
> If this draft doesn't take a strong stand against that practice, it's 
> doing nothing
> more than giving a wink and a nod that what twitterbook is currently 
> doing is safe.
> That's bad, but I suspect it's the elephant in the room.
>
> Mike
>
>>
>> Get rid of the fancy rhetoric, we don't need to explain a lot more 
>> than this.
>>
>> I don't agree that OAuth purports to solve these problems. What it 
>> solves is limiting the credentials granted to allow the user more 
>> control and limited damage in the event of credential misuse.
>>
>> -bill
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
> -- 
>> *From:* Michael Thomas <[e-mail]>
>> *To:* Barry Leiba <[e-mail]>
>> *Cc:* oauth WG <[e-mail]>
>> *Sent:* Wednesday, January 4, 2012 1:06 PM
>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, 
>> ends 9 Dec 2011
>>
>> On 01/04/2012 12:41 PM, Barry Leiba wrote:
>> > up being a compromised browser or a native application that the user
>> > perhaps unwisely installed, all the security in the framework goes out
>>     ^^^^^^^^^
>> > the window, because an untrustworthy UA can fiddle with pretty much
>> > everything.
>> >
>>
>> I think the "perhaps unwisely" goes to the heart of my objection. You
>> might as well be talking about "perhaps unwisely" driving a car,
>> or "perhaps unwisely" eating food: the reality is that people download
>> apps by the *billions*.  When I was initially blown off, many of the
>> participants including document editors implied that only idiots get
>> apps for their phones. That is *completely* unhelpful as the reality
>> is that OAUTH's use is hugely if not primarily deployed in that sort of
>> environment.
>>
>> This is a threat that cuts to the very heart of what OAUTH is, and 
>> purports
>> to defend against: keeping user credentials out of the hands of an
>> untrusted third party. If there really aren't any good ways to 
>> mitigate this
>> in an app environment, why is OAUTH being deployed so aggressively 
>> there?
>> Shouldn't the threat draft say in blinking bold: "DEPLOYING OAUTH
>> IN NATIVE APPS CONSIDERED HARMFUL"?
>>
>> Mike
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth