Problem with nonces and HTTP GET

John Bradley john.bradley at wingaa.com
Thu Jan 28 11:24:45 UTC 2010


Nat the problem is that the RP is performing correctly and preventing replay.

In some cases users perform replays on themselves, by using the back button.

Rather than throw out replay checking nonce, timestamp checking, it is better to detect that a session has replayed its own authentication token and allow that without throwing an error.  While still rejecting replays from other sessions.

Until someone convinces me differently this is more a RP library UX issue than a protocol one.

John B.
On 2010-01-28, at 3:44 AM, Nat Sakimura wrote:

> (2010/01/28 14:41), Andrew Arnott wrote:
>> 
>> John,
>> 
>> Can you help me understand the risk of a replay if SSL protected the message such that you have very high confidence that the only person who could be replaying it is the person who should be able to log in anyway?
> Browser is a default MITM. Browser plug-in type of thing can look at the traffic, and send it to the attacker, and the attacker can use is later to impersonate the user. 
> 
> For MITM for HTTPS, refer to something like http://www.sans.org/reading_room/whitepapers/threats/ssl_maninthemiddle_attacks_480
> 
>> 
>> IOW, what's the problem with replay if there's no chance of MITM attacks?  
>> 
>> On the other hand, I'm not entirely convinced that nonces are all that useful, since any MITM could also conceivably preplay the message, and get in anyway.  Encryption seems to really be the best/only mitigation.
> 
> Assertion is signed and given that nonce has sufficient level of entropy and randomness, it should be pretty hard to preplay, is it not? 
> 
>> --
>> 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
>> 
>> 
>> On Wed, Jan 27, 2010 at 5:22 PM, John Bradley <john.bradley at wingaa.com> wrote:
>> I think it has been increased.  It would probably be a boon to the internet if all versions of IE prior to 8 are deprecated.
>> 
>> However I have a hart time seeing websites turning people away due to old browsers.
>> 
>> It is possible for a IdP to detect the browser and use GET up to 4K + if it is safe.
>> 
>> That won't solve the problem that nonces do what they are supposed to and prevent token resubmission.
>> 
>> John B.
>> On 2010-01-27, at 10:12 PM, Henrik Biering wrote:
>> 
>> >
>> > John Bradley wrote:
>> >>
>> >> The other alternative is to ban IE because it is the source of the 2K limit for GET.
>> >> Not a problem for FF or other browsers.
>> > Although I cannot find any official documentation, it seems that the traditional 2K  limit for IE GET requests has been increased significantly in IE8
>> >
>> > =henrik
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>>   
> 
> 
> -- 
> Nat Sakimura (n-sakimura at nri.co.jp)
> Nomura Research Institute, Ltd. 
> Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100128/4e6ab32c/attachment.htm>


More information about the specs mailing list