The proposed text already does
(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02).
When will you post the new revision of the core draft that includes the
proposed text?
regards,
Torsten.
Am 12.04.2011 17:50, schrieb Eran Hammer-Lahav:
It should include a section on phishing-like attacks.
EHL
*From:*Andrew Arnott [mailto:[email protected]]
*Sent:* Tuesday, April 12, 2011 8:30 AM
*To:* Eran Hammer-Lahav
*Cc:* OAuth WG ([email protected])
*Subject:* Re: [OAUTH-WG] client authentication for implicit grant type
Thanks, Eran. Will the security considerations section discuss this
and recommend that auth servers warn the users of the potential
phishing attack?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo
On Tue, Apr 12, 2011 at 7:48 AM, Eran Hammer-Lahav
<[email protected] <mailto:[email protected]>> wrote:
I don't think there is much we can do either way to prevent these
phishing-like attacks with or without the client identifier. The key
to security here is the ability of the end-user to keep track of how
it got there, and based on that decide if they want to grant access to
whoever sent them to the authorization endpoint. This is the same
problem with phishing -- the user ends up in a login page and unless
they pay attention how they go there (and where they are if its
possible to assert), they will give the attacker their password.
If you don't include the client identifier and won't give them a hint
"John's App wants access", they will just get used to approving it
without the hint. At the end of the day, if there is value in
approving such unidentified clients, end-users will do it regardless
of security.
EHL
*From:*[email protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>] *On
Behalf Of *Andrew Arnott
*Sent:* Tuesday, April 12, 2011 7:28 AM
*To:* OAuth WG ([email protected] <mailto:[email protected]>)
*Subject:* [OAUTH-WG] client authentication for implicit grant type
I brought this concern up about a year ago. Now reviewing the latest
drafts, I still have a concern with it. It is regarding the use of
client_id without a password. I agree with section 3, as included below:
Section 3. Client Authentication
The client identifier is not a secret, it is exposed to the resource
owner, and MUST NOT be used alone for client authentication. Client
authentication is accomplished via additional means such as a
matching client password.
The above tells me (rightly so IMO) that considering the client_id
alone (without real authentication) is dangerous. Yet the Implicit
Grant type accepts a client_id, but no authentication:
Section 4.2 Implicit Grant
client_id
REQUIRED. The client identifier as described in Section 3.
Now here me: I am /not/ advocating for a client_secret in this case.
I fully understand that some clients, particularly javascript widget
clients that are embedded in others' web pages, can't keep secrets.
What I am advocating is that clients that can't keep secrets
shouldn't have IDs either. This is a wide-open door for clients to
obtain access to protected user data by lying about their identity to
authorization servers. They can achieve this in either of two ways,
given some popular client_id we'll arbitrarily call 'facebook' that
users are accustomed to authorizing access to:
1. An evil client can redirect the user to the authorization
endpoint, requesting an implicit grant, and including
client_id=facebook in the URL. The authorization server may ask
the user "Do you want to give Facebook access?" along with
(perhaps) a warning that most users won't know what to do about
(honestly, most technical users wouldn't know how to verify
either. The user, who trusts Facebook, will click Accept, and
offer whatever rogue client was running on the page they were
visiting the access that they requested.
2. In scenario 2, which is far worse, an evil client can redirect
the user to the authorization endpoint, requesting an implicit
grant, and including client_id=facebook in the URL. Same so
far, but in this case, the authorization server sees that access
has already been authorized by the resource owner to this client
in the past and immediately redirects back with the requested
access token, no user involvement whatsoever. Again, the client
obtains access.
Now, one might say to #2 that authorization servers shouldn't
automatically authorize implicit requests. That person would be
absolutely right. I'm concerned that enough clients will complain
about the user experience though that authorization servers will yield
to them and begin auto-authorizing these, justifying it by making the
"limited" access tokens. No go. Either you have protected data or
you don't.
To #1, there's no way that I can think of to properly educate the user
to be able to detect a phishing attack of this nature, such that if
they see a "do you want to authorize facebook?" when there is no
facebook widget on the page, that they should deny access.
Between those two, I see only negative impact to including client_id
in implicit grant requests. Please, will someone either address my
concerns (tell me where I'm wrong) or remove that parameter from this
grant type?
Thanks for your time.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
We're hiring! My team at Microsoft has 7 open slots. http://bit.ly/fZBVUo
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
