The wording you propose is unacceptable. It is a rehash of the
same misleading nonsense that is in there now. In particular #1 and
#3 that say in effect "bad guys really should be good" are silly
and unhelpful. #2 has possibilities, but in its current form gives
absolutely no guidance as to what might be done; mine at least
explicitly said that the status quo is unacceptable.
I also completely object to the notion that the authentication
service has no part in protecting itself. It has complete control
over who it allows to register as a client, and as written Eran's
text contradicts #2's possibility of mitigation -- even if William
thinks it's hopeless (as I read him). If William is right the
appropriate guidance is that authentication services MUST NOT
enroll clients that use untrusted browsers. Putting this on the
end users shoulders is useless and should be a reason that the
IESG should just reject the protocol.
I also object to not *explicitly* pointing out that native apps
mean apps from App stores, markets, etc. and the general problem
that users cannot know a priori whether an app is malicious or not. I
don't see why this is even controversial -- unless your aim is to hide
that uncomfortable fact.
This is a threat document, not a marketing puff piece. Downplaying
threats does nobody any good. Except bad guys.
Mike
On 01/05/2012 06:01 AM, Mark Mcgloin wrote:
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
oauth-boun...@ietf.org wrote on 05/01/2012 00:05:04:
From:
Eran Hammer-Lahav<e...@hueniverse.com>
To:
Michael Thomas<m...@mtcc.com>, Torsten Lodderstedt
<tors...@lodderstedt.net>
Cc:
Barry Leiba<barryle...@computer.org>, oauth WG<oauth@ietf.org>
Date:
05/01/2012 00:05
Subject:
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec
2011
Sent by:
oauth-boun...@ietf.org
-----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.
EHL
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
