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 _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
