Note: one change recommended below...
With regards to 4.1.4…
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.
[Phil] I don't think we need to really add much here. We could write whole
essays on this topic and likely will.
I think the point is simply to educate the client developer that there is no
need for a client application to ever have access to a raw uid/password (or any
other user credential).
[/Phi]
[snip]
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.
[Phil] I agree, Firefox recently demonstrated how poorly users recognize the
security signals in the browser by dropping the "lock" icon without
announcement. When I found out, I had already been using it for some time and
hadn't noticed. This counter measure should be changed to:
o The OAuth flow is designed so that client applications never need to know
user passwords. Where possible Client applications SHOULD avoid directly asking
for user credentials during an authorization flow.
[/Phil]
o Client applications could be validated prior publication in a
application market.
[mat] How would this be done in practice?
[Phil] I think this needs to change to:
o Client applications could be validated for acceptable practices by the
Resource Site provider prior to issuing production Client Credentials.
[/Phil]
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?
[Phil] This is a best practice for the client developer. [Phil]
[snip]
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2011-12-15, at 6:30 AM, Barry Leiba wrote:
>> Working group last call begins today on the threat model document:
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01
>>
>> Please review this version and post last call comments by 9 December.
>
> Sorry, folks: I got a little behind here.
>
> Working-group last call is now over. There were no comments in
> response to this thread, so it looks like we're mostly done here.
> Mike Thomas pointed out to me that his message here:
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg07780.html
>
> ...was in reference to this document -- that might not have been clear
> because of the change in subject line. Torsten, et al, consider that
> message to be your only working-group last call comment, and handle it
> accordingly. When that's worked out and there's another version, we
> should be ready to send this up to the IESG.
>
> Barry, as chair
> _______________________________________________
> 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
