The SP could optionally add a "buffer" to account for mistypes. Maybe allow 2, 3, 4, etc attempts. To the consumer it doesn't really matter how many attempts are allowed, they can just keep trying until they are notified the request token is no longer valid. The spec should outline how the client will be notified when a token becomes invalid (status code, parameter?).
On Tue, Apr 28, 2009 at 5:21 PM, Breno de Medeiros <br...@google.com> wrote: > Sometimes users may hit the 'reload' button in the consumer page and that > may result in the request token swap being sent twice. So, this implies a > requirement on consumers to immediately redirect users to a different page > so that the "back" and "reload" buttons won't re-submit the request. > > In practice, with the new changes, it would be hard for an attacker to get > hold of the user's response within a short time frame. Since the request > tokens are single time use already, I believe there is no reason for > additional spec changes, though probably a discussion on a security > considerations section of the spec (which should be moved from appendix to > main document) may well be indicated. > > > On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver <leah.cul...@gmail.com>wrote: > >> Actually, I think it's a pretty small change to the spec. >> >> In section 6.3.2 Service Provider Grants an Access Token ( >> http://oauth.net/core/1.0/#auth_step3), it says: >> >> The Service Provider MUST ensure that: >> >> - The request signature has been successfully verified. >> - The Request Token has never been exchanged for an Access Token. >> - The Request Token matches the Consumer Key. >> >> ... >> If the request fails verification or is rejected for other reasons, the >> Service Provider SHOULD respond with the appropriate response code as >> defined in HTTP Response Codes (HTTP Response >> Codes)<http://oauth.net/core/1.0/#http_codes> >> . >> >> >> Perhaps an updated version could say something like (changes in red): >> >> The Service Provider MUST ensure that: >> >> - The request signature has been successfully verified. >> - The Request Token has never been exchanged for an Access Token. >> - There have been no prior attempts to exchange this Request Token for >> an Access Token. >> - The Request Token matches the Consumer Key. >> >> ... >> If the request fails verification or is rejected for other reasons, the >> Service Provider SHOULD invalidate or delete the request token andrespond >> with the appropriate response code as defined in HTTP >> Response Codes (HTTP Response Codes)<http://oauth.net/core/1.0/#http_codes> >> . >> >> >> >> >> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver <leah.cul...@gmail.com>wrote: >> >>> >>> Hmm... I feel like this has been lost in all the hubbub about >>> callbacks. >>> >>> I strongly advocate saying something in the spec about making the >>> token exchange (access token endpoint) one-time use only. >>> >>> By one-time only, I mean that the first time there is an attempt to >>> exchange a request token for an access token, if the request token has >>> not been authorized, then that request token should be marked as >>> invalid. This will make a session fixation attack nearly impossible >>> without a callback. >>> >>> If a service provider allows multiple attempts to exchange the request >>> token a callback is not even necessary for the attack to work! The >>> attacker must only keep trying to exchange the token. >>> >>> I know it's up to the service provider to implement one-time only >>> token exchange, but putting it in the documentation (and libraries) >>> will make it much easier for service providers to do the right thing. >>> >>> Am I missing the discussion about this? Is it on the wiki and I just >>> can't find it? Or is everyone in agreement that this should be added >>> to the docs? >>> >>> Thanks, >>> Leah >>> >>> >> >> >> > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
