views:

1182

answers:

3

One of the requirements proposed for an ASP.NET application is that we have Session state disabled globally. (This is not negotiable.)

Another requirement is that we have some means for user authentication. I'm thinking of using ASP.NET's membership provider model.

Is it possible to have user authentication without Session State?

The specific user-authentication examples we're looking for are:

  • User goes to website unauthenticated
  • User enters registration information (contact fields, etc)
  • For the remainder of their session, user has access to certain content thanks to their registered status

Is there a way to do this with cookies?

Can this be done securely, so the cookie can not be easily spoofed?

Is there built-in functionality in ASP.NET to support this, or will we need to roll our own method?

+5  A: 

ASP.NET Forms authentication does not use SessionState. It uses a cookie to store the authentication ticket.

You can also force the authentication ticket to be sent over SSL channel by editing the web.config file.

All the functionality you need is available built-in in ASP.NET.

http://msdn.microsoft.com/en-us/library/aa480476.aspx

Mehrdad Afshari
Great... looks like I need validationKey and decryptionKey need to be identical on all servers on the web farm for this to work.
frankadelic
if you are on a Web farm, yes.
Mehrdad Afshari
A: 

Yes, you can use cookies.

The problem with cookies, is you can't persist much data to them. For wizard type registration I store the data in the database and then store the row key/Id in an encrypted cookie. This way when the user moves to the next step you can retrieve the data from the database.

For cookies, you can timestamp and encrypt the cookie values. I typically don't manage the user's authentication state. I use the built in FormsAuthentication classes manage that aspect of my web applications.

Large sites such as: Myspace and Live Search Club, solely rely on cookies as state management.

Chuck Conway
+2  A: 

Sure, a cookie will do this.

Think of the fundamentals. Session State is managed by cookies anyway.

Here's what you do.

When they log in, you take their userid, and a timeout (so the login only lasts for, say, 30 minutes or whatever).

Take that string, and hash it.

(java, not important tho)

String cookie = userid + ":" + timeString + ":" + md5(userid + ":" + timeString + ":" + "secretpassword");

Then, when the request hits your site, check the cookie. First check it for integrity.

String parts[] = cookie.split(":");
String newHash = md5(parts[0] + ":" + parts[1] + ":" + "secret password");
if (!newHash.equals(parts[2])) {
    // boom, cheater!
}

Then check the time string to see if they're still "logged in", and go from there.

Make sure if you do the time thing to update the cookie on every request.

Will Hartung
this is a pretty bad practice though, security wise. If secret password leaked once anyone can login into the app. And if it's weak it can be cracked (especially while MD5 is fading out). If you gonna do this way at least use a different random "secret" for every user. That'd be so much more safer.
dr. evil
How would you manage a different key-per-user-per-authenticated-session?
Justice
That's a key control issue, you have the same problem with any encryption. Don't like MD5, pick SHA. It's an example of technique.
Will Hartung
@Justice - simply generate a random password for each user when you create them, and put it in their user record. Since you have the userid here, it's simple to look it up for each user.
Will Hartung