You can't expect the user to type a URL with a signature in it, in the case of a device that can't run a web browser. Sorry if I confused the case we were talking about.
On Sat, Apr 25, 2009 at 1:43 PM, Josh Roesslein <[email protected]> wrote: > How can the attacker use that flow? He can't set a callback in that URL > since it can't be signed by him unless he has the consumer secrete. > If there is no signiture, the provider ignores any parameters. It can lookup > to see if a default callback has been registered and use that. If there is > no default callback, the provider just displays the token for the user to > manually enter. > > On Sat, Apr 25, 2009 at 3:39 PM, Jonathan Sergent <[email protected]> > wrote: >> >> On Sat, Apr 25, 2009 at 1:38 PM, Josh Roesslein <[email protected]> >> wrote: >> > As for the timing to apply this change, I think it would be worth it >> > taking >> > the extra time to get it right. Most providers I think have already >> > found >> > quick fixes >> > to block this session fixation attack. >> >> Really? The only "quick fix" I have seen is a scary warning message >> on the approval page telling users not to use OAuth. >> >> > So I don't think we are in immediate >> > danger, but I could be wrong. Just by adding callback URL signing and >> > limiting request token swapping to one try should be enough to stop the >> > session fixation. >> > >> > On Sat, Apr 25, 2009 at 3:35 PM, Josh Roesslein <[email protected]> >> > wrote: >> >> >> >> Well this callback is short lived since it is swapped by the consumer >> >> almost right away. So you don't have much time for a brute force attack >> >> to >> >> guess the callback URL. >> >> Plus we can require that you only get once try to swap the callback for >> >> an >> >> access token. After that it is invalidated and no longer useful. >> >> >> >> On Sat, Apr 25, 2009 at 3:30 PM, Brian Eaton <[email protected]> wrote: >> >>> >> >>> On Sat, Apr 25, 2009 at 1:04 PM, Brian Eaton <[email protected]> >> >>> wrote: >> >>> > On Sat, Apr 25, 2009 at 12:26 PM, Josh Roesslein >> >>> > <[email protected]> >> >>> > wrote: >> >>> >> Thanks for posting that Brian. >> >>> >> >> >>> >> I'm leaning towards signed approval URLs. Seems the best way to go >> >>> >> IMO. >> >>> >> Seems to solve the issues and also helps simplify the OAuth flow. >> >>> > >> >>> > The major pain point of signed approval URLs is that we would lose >> >>> > support for devices that either >> >>> > a) can't open a web browser (because the signed approval URL is >> >>> > really >> >>> > long) >> >>> > or >> >>> > b) can't receive a callback URL (because the callback token is >> >>> > really >> >>> > long). >> >>> > >> >>> >> >>> Err, I should have pointed out that the other objection I've heard to >> >>> signed approval URLs is that they are a major departure from the >> >>> current protocol, and thus will slow down deployment of fixes. I'm >> >>> not sure that's true, but it seems plausible. >> >>> >> >>> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
