Problem with nonces and HTTP GET

John Bradley john.bradley at wingaa.com
Thu Jan 28 11:16:27 UTC 2010


There is a real threat of interception at the browser.

Encryption in itself is not sufficient to mitigate agains replay.

Without a nonce to prevent replay.  openID would need to be reassessed against SP-800-63.
It may not qualify for LoA 1 without adequate replay protection.

Without seeing a whole proposal I can't say definitively.

The reality is that if query parameters on GET's are not allowed to effect the server then most of the web 2.0 apps would break.

The problem is that RP are not tying the received assertion to the browser session the first time they receive the token.

If you get the same token from the same browser session multiple times that should not be a problem.

If you get the token from a different browser session that is a problem and it should be rejected.

I don't think nonce processing in the spec is broken.   Perhaps RP implementations need to improve there handling of authentication tokens.

eg set a cookie with the nonce from the last authentication so that if the user hits the back button and resubmits you can detect it.

John B.


On 2010-01-28, at 2:41 AM, 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?
> 
> 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.
> --
> 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
> 

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


More information about the specs mailing list