Form Authentication – Cookie replay attack – protection

I am being asked about cookie replay attacks with my ASP.NET websites forms authentication.

I have followed the advice below to protect against any attack but think that the site is still vulnerable if somebody manages to get at the cookie (albeit only for a short time). Is there a way to completely destroy the forms authentication session on logout so that even if someone had stolen the cookie there would be no chance of using it maliciously

Advice followed was

We believe we have taken all responsible steps we can to protect against this within the confines of ASP.NET. Please see detailed response below.

However we have implemented the recommended steps from Microsoft to defend against this (see;en-us;900111)

· The authentication cookie is never written to a client machine making it hard to steal.

· The application is run-able via SSL so a cookie is never issued over a non secure connection

· We enforce absolute expiration with a 15 minute timeout meaning that any issues cookie is useless after that time limit

· We use httpOnly cookies so that no-one can pro grammatically intercept or alter this cookie.

So even if the above precautions were broken, which we think highly unlikely, a malicious user would only have 15 minute window to break the precautions and successfully log in


Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

A simple idea is to generate a random guid and store it in the user data section of the cookie. Then, when a user logs out, you retrieve the guid from the user data and write it in a server side repository with an annotation that this “session” has ended.

Then, have an http module that checks upon every request whether or not the guid from the userdata section of your cookie doesn’t point to a ended session. If yes, terminate the request with a warning that expired cookie is reused.

This comes with a cost of an additional lookup per request.

Method 2

Is there a way to completely destroy the forms authentication session
on logout so that even if someone had stolen the cookie there would be
no chance of using it maliciously

The way is to keep track on your server that the user is logged out and what time, so even if its going to see a page using a valid authenticated cookie, you double check if this user is also logged on your server records or not.

This means that you must have an extra table on your database to keep and check the login logout of your users status and not been 100% count on the authentication cookie.

Is there a way to completely destroy the forms authentication session
on logout

In the worst scenario that the cookie is stolen, you actually can’t.

Why is that, because the form authentication is actually keep on the cookie all the data (like when is expired, who user is, etc). So you can not delete that, is on the cookie, and the alternative is to synchronize that with your custom data on the server and have an extra level of security.

Related: Can some hacker steal the cookie from a user and login with that name on a web site?

Method 3

You can easily invalidate forms auth tickets that are “older than date X”.

A FormsAuthenticationTicket has a built-in property called IssueDate that allows you to do that.

You can, for example, do this:

  1. store a date in user’s database record, you can name it ValidSince
  2. read the token date inside Application_AcquireRequestState (in global.asax)
  3. if the token’s IssueDate is older than the database date – logout!

When you want to invalidate a particular user – just reset that date in the database to the current date.

I blogged about it here if you need some actual code samples.

One very common use case is to “invalidate all sessions created before the last password-change”.

Method 4

I implemented a system that stores the SessionID in the auth cookie on the first authenticated request and then verifies the active SessionID matches the cookie on subsequent requests. Details on this answer. This avoided the server side tracking suggested in @WiktorZychla’s answer.

This could probably be improved by storing a hash of Incoming IP + Request.Browser + SessionID in the session and the auth cookie, rather than just the SessionID.

All methods was sourced from or, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x