When we are using ASP.NET Forms Authentication in any of ASP.NET frameworks (ASP.NET MVC, Web Forms, etc.), we persist the authentication cookie in client’s browser. As a best practice, we set the cookie as HttpOnly and secure. We also make all transactions over SSL. No matter what kind of mechanism we use to authenticate the user (OAuth, ASP.NET Membership Provider, etc), we still need to persist the authentication for better user experience.
With all those in place, I am assuming that someone can still get the cookie out of the client browser and issue requests with those auth cookie values. This cannot be detected by the server and we would be giving protected data to someone else.
One think I have in mind to lower the risk here is to ask client’s password everytime when s/he tries to take some serious actions (such as changing the e-mail address, accessing profile info, etc.) but this doesn’t solve anything and can be pretty annoying for the client.
Do you have any approach that you are actively following for this kind of issues? Or what would be the best possible way to persist the authentication in clients browser?
You’re pretty much doing everything right to being with.
If you’re using the membership provider then the cookie is flagged as HTTP only (as you said) so it’s not going to be accessible via client script such as a malicious piece of XSS.
If you’ve got the cookie flagged as secure then I assume you’ve set the “RequireSSL” flag on forms auth to true. By doing this the cookie is not going to be sent in any requests to the server that don’t go out over HTTPS so even if you accidentally slip in an HTTP request (which the browser should warn the user about anyway if it’s content embedded on an HTTPS page), the cookies won’t be sent.
The only other thing you could do – and this doesn’t offer much defence on top of what you’ve got but it’s a good practice – is to use HSTS as well. I talk about this in OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection as an additional means of ensuring requests continue to be sent over a secure channel.
Short of getting into some serious re-engineering of the membership provider, there’s really not much more you can do. You could tie the session to an IP and not accept requests if it changes but this can cause problems (i.e. IPs which change and doesn’t protect you from multiple people on the same address). You could also create a fingerprint of the browser (i.e. everything sent in the request headers) and ensure subsequent requests match but we’re getting into very fine detail here.
Ultimately though, security should be tailored to the value of the assets it’s protecting and the likelihood of malicious activity. You don’t say what it is you’re protecting, but if it’s a financial system you’re going to go to greater lengths than if it’s a simple commenting engine on a blog.
In summary, it looks like you’re doing a great job, just consider the appropriateness of the measures you’ve implemented in the context of the value of what you’re protecting. Oh – and if you’re using the SQL membership provider for credential storage, make sure you read Our password hashing has no clothes then stop doing that!