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 <m...@mtcc.com>
*To:* Barry Leiba <barryle...@computer.org>
*Cc:* oauth WG <oauth@ietf.org>
*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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
