[security] OpenID Security Best Practices Doc

[SitG Admin]

>I think it's quite appropriate to make a recommendation for 
>expires_in in this document.  But I'm not convinced that such an 
>automated attack that results in a long-lived session is really 
>mitigated by a narrow timeframe.

You have to assume that the session *will* be compromised, then, and 
prepare accordingly.

>I'm just referring to explanatory text of the issues surronding 
>persisting non-secure session cookies after session establishment,

Normally we would say "the user's privilege level has changed, 
regenerate their session". But what we *want* to do is alert the user 
when someone else is trying to replay their login, so they can try 
again from a more secure location. From there it's just a matter of 
detecting multiple logins (or multiple visitors sharing the same 
cookie) and terminating both. Replay attacks require the attacker to 
let the user get in first, so regenerating their session could leave 
us in a tricky situation for detecting when the attacker comes along 
with that *old* session (or just kill the old session when creating 
the new). Tricky attackers, though, could block the user's final 
redirect (intercepting it for their own use), or steal the user's 
session ID and then kill their connection. To be even trickier, if 
rather inconvenient to the user, we can say that the off switch is 
another login: if a successful login comes from the OP while the user 
was already logged in, they all terminate. Users who find their 
connection dead at one location, before they logged out, can move to 
another location for logout. The question is how they know what 
they're doing; perhaps if OpenID supported a "logout authentication", 
users could be certain they were only telling their OP to log them 
out, and replay attacks would not be able to achieve another login?

-Shade