I’ve been reading a lot about sessions and security, trying to learn as much as possible before writing too much code. I’ve read about limiting session replay by including a timestamp within the cookie or data sent by the server:
{timeStamp, sessionID, HMAC({timeStamp, sessionID}, Key)}
limiting the valid time with the timestamp and keeping everything over a TLS connection will minimize replay. But what happens if the user who authenticates and receives this cookie (or data) is complicit in an attack whereby he immediately sends this cookie out to others (who now have perhaps a half hour according to the timestamp). Of course, the credentials would remain limited to whatever the initial user is privileged to do.
Is this a real concern in the wild? Is there a name for it?
Is it realistic, since this is TLS, to assume the client’s IP won’t change, and thus use that IP as a check to make sure this cookie is always played from the IP it was originally sent to?
The situation that you are referring to would happen if the client is compromised. This is a real concern, but in that case any protection that you implement is trivially bypassable by having the compromised client do whatever needs to be done. So you can do an IP address check, but it won’t actually help much.
That said, the data structure that you have proposed has a red flag. Why are you sending a timestamp to the client? Are you going to trust what the client says? The session ID should map to a data structure that you control which will, among other things, know when the timestamp expires. There is therefore no need to pass that information to the client.
6