Preventing Cookie replay attacks in ASP.Net MVC

Question

I have been tasked with implementing point 4 in this article: http://support.microsoft.com/kb/900111

This involves using the Membership provider to add a comment to users server side records when they log in and out, and then confirming that when a cookie is used to authenticate, that the user hasn't logged out. This makes perfect sense to me. Where this starts to fall apart is that we do not currently use a membership provider, and so it seems like I face reimplementing all our authentication code to use a membership provider. We currently check authentication in a controller, and make a call to FormsAuthentication.SetAuthCookie() once we know the user exists. It would be a lot of work to force a membership provider in.

Is all this work really neccesary. Can I roll my own key value store of cookie values to logged in users and just make sure I clear this when a user hits the logout button. If this seems unsafe is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?

I guess my main problem here is that we decided a long time ago that the membership provider model doesnt fit with the model we use for locking and unlocking accounts, and chose not to use it. Now we find that the MS recommendations specifically mention a membership provider, and as this is security I need to be sure that not using it as they recommend isn't going to cause troubles.

Answer 1

Can I roll my own key value store of cookie values to logged in users and just make sure I clear this when a user hits the logout button.

Yes, you can do this. The Membership Provider keeps a small set of data about the user (username, email, password, last login, lost password question, lost password answer, etc).

If you don't want to retro fit a membership provider I would take the approach you mentioned. Whether the information is written to the comment field of the aspnet_Users table or a bit field in your own table, it shouldn't make any difference.

You also might want to consider putting an interface your Membership/Authentication code. Then you could swap your current code to a Membership Provider implementation when it's more convenient.

Answer 2

I've found the MembershipProvider to be very helpful. It allows me as a developer to use the SQLMembershipProvider against a local database of users, and then when I move it to production, to simply use an ActiveDirectoryMembershipProvider and I don't have to change a line of code (except in my web.config file).

Using their CustomMembershipProvider, you can overload any of the authentication methods and do whatever other checks you want inside of those methods.

If you decide to jump to the MembershipProvider scheme, I don't think you'll regret it. It may be painful in the short term, but in the long run, I think you'll see it paid off. Since you've already got a lot of your authentication code written in your controller, perhaps it won't be that hard to meld it into the way MembershipProvider uses it?

...is there a way of implementing a minimal Membership provider in order to make these checks without handing off all authentication code to it?

MP is one of those times when its best to let it do what it does best. If you try to use just part of it here and part of it there, while possible, will cause some headaches down the road. It knows what it is supposed to do and circumventing it, while possible, will require extra work that may turn out to be unnecessary.