Those 3 sound great. Add in clickjacking protection and I think we're set. -Brent
On Apr 1, 2010, at 9:18 PM, Allen Tom wrote: Perhaps the best (usable) solution would be: 1. The approval screen must clearly indicate to the user that they should only be seeing that screen if they are trying to provision a device. The user should not have clicked on a link to get to the screen 2. The Auth server should also check for the presence of an HTTP Referrer. There should not be a referrer, since the user should not have clicked on anything to have landed on the screen 3. The Auth server must not enable “auto approval” for the device flow. Meaning that the user must click through the approval screen, even if the user had previously authorized the same client_id previously Allen On 4/1/10 9:06 PM, "Brent Goldman" <br...@facebook.com<x-msg://37/br...@facebook.com>> wrote: Isn't there a similar attack for the reverse protocol? The attacker would socially engineer the user to give them the post-auth verification code displayed on the computer. This gives the attacker access to everything. We could make this more strict by having both a device code and verification code. That is, have the user enter the device code into the computer, which would produce a verification code that needs to be entered back into the device. But this is susceptible to the same attack: after visiting the link sent by the attacker, and clicking "approve on a strange auth screen", the user would have to send the verification code back to the attacker. This is slightly better in that for an attack to be successful, the user has to communicate with the attacker twice instead of once. I can't really think of a good way to eliminate the attack entirely, though. -Brent On Apr 1, 2010, at 8:05 PM, Eric Sachs wrote: Here is the note I sent a few weeks ago where we also noted the potential session fixation attack. However as we noted, we are still willing to start with this profile and later work on where the user has to enter a code into the device. ---------- Forwarded message ---------- From: Eric Sachs <esa...@google.com<x-msg://37/esa...@google.com>> Date: Wed, Mar 17, 2010 at 5:45 PM Subject: Re: [OAUTH-WG] Device Profile To: Brent Goldman <br...@facebook.com<x-msg://37/br...@facebook.com>> Cc: "OAuth WG (oauth@ietf.org)<x-msg://37/oauth@ietf.org)>" <oauth@ietf.org<x-msg://37/oauth@ietf.org>> Google has a similar requirement to move these types of devices to OAuth/WRAP and away from our older "ClientLogin" protocol where the user is prompted for their username/password. The proposed profile looks fine, but we are a few weeks from being able to do specific work on it, so we may have more feedback at that time. If the device can accept some user input, then there are some security advantages to requiring the user to get the code from their computer and then enter it into the device. In particular, it makes it easier to protect against a DOS attack targeted at the service-provider to request a large # of codes. That method also reduces the risk of a phishing/session-fixation type attack. However we agree that some profile is needed for devices with no user input. We also expect it will be easier to get these device vendors to use a common industry technique, so we are fine with prioritizing our support for this profile. Longer term the community could define a profile where the code is displayed on the computer. On Thu, Mar 11, 2010 at 3:27 AM, Brent Goldman <br...@facebook.com<x-msg://37/br...@facebook.com>> wrote: Over the past couple days, Luke Shepard, David Recordon, and I have been brainstorming an OAuth profile for standardizing the flow that devices such as game consoles and entertainment centers use to hook up with services such as Netflix and iTunes. The basic flow is that a device can gain authorization by directing the user to visit a URL on their computer and to enter a verification code copied from the device's screen. A draft spec is attached to this email. Any thoughts or feedback? Note: this is one of the many profiles going into the OAuth 2.0 draft that David is writing (http://daveman692.livejournal.com/349384.html). -Brent _______________________________________________ OAuth mailing list OAuth@ietf.org<x-msg://37/OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
