3

I read the documentation of Nancy Forms Authentication. As far as I can tell, the approach recommended there leads to lifelong session IDs:

"The identifier is the token that will be put in the authentication cookie which will be used to re-establish the identity of the user that is performing the request, so that you do not need to enter your credentials for each request."

As far as I understand, that "identifier" is what most people call a session ID.

It is also important to know that the identifier should be treated as permanent for the user that it was generated for and will be reused across requests and application sessions.

Is this really the recommended approach? If I understand correctly, this means that session IDs never change and never expire. So the session ID is the equivalent of a password, which

  • is retransmitted in a cookie with every request
  • is probably stored in clear-text in the DB, if you follow the docs to the end

I know that I could implement this differently with Nancy, but my point is that such an approach should not be explained in the docs as reference.

So if an attacker ever succeeds in stealing that session ID, e.g. by an XSS attack, he gains lifelong access to the system.

Please correct me and show me the mistake in my thoughts!

theDmi
  • 17,546
  • 6
  • 71
  • 138

2 Answers2

3

The identifier you are referring to isn't a session id, it's an unpredictable user identifier, which is then mapped (if necessary) to the real user identifier in the back end. This is so if someone logs in as user X, and somehow manages to decrypt, re-encrypt and re-sign the cookie they can't just change the user ID to "admin" or something similar and gain admin access (which is how the ASP.Net Oracle attack worked). It's also HttpOnly, so not really capturable via XSS, although technically it could be captured using XST.

Creating and expiring a session (and deleting the auth cookie if necessary) is a different task altogether - how and when you determine if an auth cookie should be accepted, removed, or confirmed with an additional password request is application specific. This is a common pattern now where a site will consider you "logged in" eternally, until you do something "secure", in which case it will ask you to revalidate if you haven't done so recently.

Hope that makes sense.

Steven Robbins
  • 26,441
  • 7
  • 76
  • 90
  • Thanks for the clarification, that helped a lot. I'm going to read that documentation once more now :-) . So that means there really is no session ID, am I correct? The only thing I have to worry about is the auth cookie, which I control through the Login(), Logout() etc. extension methods. – theDmi Jan 31 '14 at 06:57
2

that "identifier" is what most people call a session ID.

It's not. It's something like UserId. as the documentation states:

We have chosen to use a GUID as the identifier. The reason for this is that using something like the username of id is a potential vulnerability, because, if the cookie encryption was somehow compromised, it would be easy to spoof the identity of another user by guessing their username or id.

They're just using a GUID assigned to the user for more security. Of course, (cookie based) FormsAuthentication has all the disadvantages of cookies. If someone can get access to your auth cookie, they can authenticate themselves as you. But session cookies and forms authentication cookies are completely different things, This answer states the differences pretty clearly.

Community
  • 1
  • 1
Kamyar
  • 18,639
  • 9
  • 97
  • 171
  • Ahh - this has nothing to do with Nancy. This is to do with ASP.NET, the OP is asking about Nancy. – Phill Jan 31 '14 at 05:05
  • @Phill: That's why I should never visit SO after 1AM. Thanks for the heads up! – Kamyar Jan 31 '14 at 05:16
  • 1
    Even though the link is for ASP.NET, you pointed me in the right direction (auth cookies vs. session cookies), thanks. – theDmi Jan 31 '14 at 06:59
  • 1
    @theDmi: I edited the post and removed ASP.Net specific stuff about session fixation attack. However, You can always find out more about Nancy's authentication cookies using Firebug and running `Nancy.Demo.Authentication.Forms` project and inspecting cookies. It creates an encrypted cookie named `_ncsa`. – Kamyar Jan 31 '14 at 15:40