8

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?

tugberk
  • 57,477
  • 67
  • 243
  • 335

3 Answers3

7

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!

Troy Hunt
  • 20,345
  • 13
  • 96
  • 151
  • Thanks Troy, very nice answer and good suggestions. I should admit that I overlooked to set `slidingExpiration` to `false`. I am assuming this enables an expired ticket not to be able reactivated. This also puts one more confidence to the system. What do u think? – tugberk Aug 03 '12 at 09:36
  • What sliding expiration does when it's on is applies the session timeout against the *last request* but when it's off, it applies it against *the start of the session*. Say you have a 20 min timeout and actively use the system for 10 mins. When sliding expiration is *on* the timeout will happen at 30 mins. When it's *off* the timeout will happen at 20 mins. Turning it off reduces the window of opportunity to hijack the account but adversely affects the usability. If your system is one where people get in, do what they need quickly then leave, turn it off. – Troy Hunt Aug 03 '12 at 10:05
  • Then, in either way, an expired auth cookie cannot be use and reactivated, right? – tugberk Aug 03 '12 at 10:13
  • That's correct, once it's expired you'll need to log back in. – Troy Hunt Aug 03 '12 at 11:06
2

With extra on all that you have done, and having in mind this question I extra suggest, to keep more information's on the server about the user together with the authentication cookie, so if some one steal the cookie and try to use it, is also must meet and all the rest characteristics of the client to be able to use it.

Some of the rest information's that I keep and check is they are the same together with the authentication cookie.

  1. session cookie connected with the authentication cookie.
  2. Browser id connected with
  3. Ip of the user is connected with
  4. Javascript must be enable

I know that some one can say that all that can be clone by a hacker - if the hacker can take the cookie why can not get and the rest of them. Well nothing is 100% guarantee in the scenarios and if some one can take all that information's is actually can have and the password its self and login - at least you make it a little bit more secure.

Community
  • 1
  • 1
Aristos
  • 66,005
  • 16
  • 114
  • 150
1

You're already using HTTPS and encrypting the cookies, which is fairly secure.

If you're still worried, I would suggest storing additional information about the user's session on the server (IP address, User Agent, etc) and verifying that against the information provided during the session.

If the user changes their email address, you could send a revoke link to the original email address, so if that change is unauthorised, the true owner is alerted to the change.

podiluska
  • 50,950
  • 7
  • 98
  • 104
  • Compromising the IP address is hard but User Agent can be provided by the attacker pretty easily. I admit that it might make things harder to hack. On the other hand, checking against the IP address can be very annoying for the client if s/he is on the move (changing her/his location pretty often with his machine (laptop, tablet etc.)). But I still +1. – tugberk Aug 03 '12 at 09:26