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

Answer 1

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.

Answer 2

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.