On 01/04/2012 05:16 PM, William Mills wrote:
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.
So what you're saying is that it's even worse than what I wrote, which
is pretty confining as to what clients an auth server should have a
relationship with. I guess that's progress.
A known client whose client keys are compromised is certainly a threat,
but it at least requires one more step beyond just freely getting client
keys from the auth service. On phone apps with no backend, for example,
it's problematic to keep that key secret, but for clients that have backend
servers it's not as bad. Part of the vetting process could be "clients MUST
NOT store client keys in a program that can be disassembled trivially like
a phone app". This may already be in this draft though, so apologies if
I didn't see it.
I guess I'd rather there not be a blanket MUST NOT -- I hope it doesn't
come down to that -- but they way I'm reading you is that it will come
down to just that.
Mike
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>
[mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
