The below is unfortunately probably a no-go:
> Given these threats, authentication servers MUST NOT give clients access
> to authentication services -- and by extension to resource services -- unless
> the
> authentication service can thoroughly vet the trustworthiness of the client.
> How
> that vetting is achieved is outside of the scope of this document, but the
> current
> practice of freely giving client keys to any would-be OAUTH client is not
> sufficient."
It's unfortunately not really a solved problem for widely distributed clients.
I attack this by spoofing a known client and the resource server or auth server
can't tell the difference. That's why I was falling back to the more brutal
"this doesn't protect you from ..." statement.
Native mobile clients where the default experience is likely to be not to spawn
a browser for the interaction are going to be a real problem too.
Auth servers (I think that's where you get the best control) can do their best
to keep track of what clients a user has authenticated and prompt the user on a
new client, but it's still up to the user to make sure they're not being lied
to, and in practice this is only marginally effective (and tends in fact to
slow adoption with a "scary" message, so product type folks don't like it).
-bill
________________________________
From: Michael Thomas <m...@mtcc.com>
To: Eran Hammer-Lahav <e...@hueniverse.com>
Cc: oauth WG <oauth@ietf.org>; Barry Leiba <barryle...@computer.org>
Sent: Wednesday, January 4, 2012 4:39 PM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
On 01/04/2012 04:05 PM, Eran Hammer-Lahav wrote:
>
>> -----Original Message-----
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Michael Thomas
>> Sent: Wednesday, January 04, 2012 3:40 PM
>> My concern is that putting on a veneer of "security" will lull people into
>> thinking "Oh, it's safe to enter my credentials here because this is really
>> twitterbook, not evilapp!". When I had to ask them directly to put their
>> twitterbook credentials into my app, there at least wasn't any confusion that
>> I had access to them.
> This is ridiculous (e.g. the fact we are still discussing this).
>
> First, end users know nothing about security or OAuth. Second, evil apps can
> create this veneer of security by faking a redirection flow with or without
> OAuth. Suggesting that OAuth (which is a de-facto web pattern for over a
> decade) makes anything worse is patently false.
>
> The only thing we can possibly add to the threat model document is to mention
> that "OAuth does not provide any protection against malicious applications
> and that the end user is solely responsible for the trustworthiness of any
> native application installed". That is accurate (and completely obvious to
> the target audience of this document). It is not very helpful but if it will
> make you feel better (since no one else here seems to share your concerns), I
> have no objection to such one line added.
>
> And again, to highlight the absurdity of your security claim, it is equally
> important to warn developers in earthquake-prone countries to put enough
> distance between the Approve and Deny buttons so that the user will not
> accidentally hit Approve during a tremor.
>
It's this kind of hostility and ad hominem that leads me to believe that
you have forgotten some of your lessons in charm school.
For one, I am not the only one and even if I were that would still not be
a reason to shoot the messenger. Secondly it is *not* the sole responsibility
of the end user: the authentication server absolutely has a part to play
here too. They have to give out client keys, after all, and its their service
that could be hacked. So they have as much if not more responsibility
than the end user.
So to Bill's request here is the text I would propose.
"Native apps, not limited to, but including apps which are available on popular
mobile app stores, have the potential for gaining access to the end user's
credentials.
This can be accomplished by gaining access to browser UI components and key
logging,
spoofing the look and feel of an authentication server's authentication page,
and
potentially many other social engineering attacks. The potential for these
attacks
exist in many existing OAUTH2 deployments including but not limited to Facebook
and Twitter.
Given these threats, authentication servers MUST NOT give clients access
to authentication services -- and by extension to resource services -- unless
the
authentication service can thoroughly vet the trustworthiness of the client. How
that vetting is achieved is outside of the scope of this document, but the
current
practice of freely giving client keys to any would-be OAUTH client is not
sufficient."
Mike
_______________________________________________
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
