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

[William Mills <[e-mail]>]

There's going to be a whole class of apps tat will be in violation of "Client applications SHOULD avoid directly asking users for the their 
credentials.".  We know that already, because the password grant exists 
and we have real use cases for it.  I think we should strikes that 
sentence and move that idea to #3 (soon to be #2)


I think point 2 should be struck, it's pointless.  What would matter here is whether the user can check that the app has been validated, and 
we're not defining that.


I would change #3 (now #2?) to:
   3. It is RECOMMENDED that client applications use the web based authentication 
   flow, this takes advantage of a more trusted system component, e.g. the system 
   browser, and provides a consistent authentication experience for the user
   across applications.  The user is then always presenting their credential to a
   known and trusted web page.  Collection and use of primary authentication from
   the user by client applications is NOT RECOMMENDED.

Regards,

-bill

P.S. hit the wrong key earlier and replied only to Mark with this.  Should have hit the list.  Sorry Mark.



________________________________
 From: Mark Mcgloin <[e-mail]>
To: OAuth WG <[e-mail]> 
Sent: Thursday, January 5, 2012 6:01 AM
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
 
Having read the suggested wording from Eran, William and Michael, I think
Eran's description is the most succinct and relevant: "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"
@William: The threat has been described in the context of installing
malicious apps so the wording above it more applicable
@Michael: It has been repeated many times that we should only address
security issues specific to Oauth, and Oauth does not make things worse if
a user installs a malicious client. If you want to continue the discussion,
please email me directly and we can revert to this forum if you still think
your point is relevant

Section 4.1.4 of the threat model will be updated as below. Remember the
threat model is just offering advice on best practices.


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).

Impact: If the client application or the communication is compromised, the
user would not be aware and all information in the authorization exchange
could be captured such as username and password.

Countermeasures:

1. The OAuth flow is designed so that client applications never need to
know user passwords. Client applications SHOULD avoid directly asking users
for the their credentials. In addition, end users could be educated about
phishing attacks and best practices, such as only accessing trusted
clients, as OAuth does not provide any protection against malicious
applications and the end user is solely responsible for the trustworthiness
of any native application installed

2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for
OAuth but could include validating that the client application handles user
authentication in an appropriate way

3. Client developers should not write client applications that collect
authentication information directly from users and should instead delegate
this task to a trusted system component, e.g. the system-browser.

Regards
Mark

[e-mail] wrote on 05/01/2012 00:05:04:

> From:
>
> Eran Hammer-Lahav <[e-mail]>
>
> To:
>
> Michael Thomas <[e-mail]>, Torsten Lodderstedt
<[e-mail]>
>
> Cc:
>
> Barry Leiba <[e-mail]>, oauth WG <[e-mail]>
>
> Date:
>
> 05/01/2012 00:05
>
> Subject:
>
> Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
>
> Sent by:
>
> [e-mail]
>
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 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.
>
> EHL
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth