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> 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> >> Date: Wed, Mar 17, 2010 at 5:45 PM >> Subject: Re: [OAUTH-WG] Device Profile >> To: Brent Goldman <br...@facebook.com> >> Cc: "OAuth WG (oauth@ietf.org)" <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> 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 >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> <ATT00001..txt> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
