2

I have a login system that I have to code. But what I don't understand is do I have to store cookies on client machine even if there is no Remember me? Wouldn't it be just better and "secure" if I store all required information in Session itself and use that to check in my BasePage to see if the user is authenticated or not?

If the remember me functionality was to be built then it would have required cookies, right? Please throw some light on this.

Jaggu
  • 6,298
  • 16
  • 58
  • 96
  • 1
    The first rule of coding authentication systems is to lean as much as possible on the features provided to you by your platform... in this case, the ASP.Net membership provider. You never want to write too much authentication code yourself, because it's so easy to write something the _seems_ to work -- even passes all your unit tests -- but has a subtle flaw that has your system getting hacked after six months and you not finding out for a year. – Joel Coehoorn May 09 '12 at 04:47
  • @Joel: I can't use Asp.Net Membership provider. My database tables are entirely different from the one which Microsoft provides. So, in any case I would have to write my authentication code myself. – Jaggu May 09 '12 at 04:49
  • 1
    Your database tables have nothing to do with it... that's the point of using a provider model at all... you take a base model and inherit from it to talk to whatever data store you need. – Joel Coehoorn May 09 '12 at 04:50
  • @Joel: Writing custom authentication provider means I "can" still make mistake :). – Jaggu May 09 '12 at 04:51
  • Yes, you could. But it's somewhat less likely. – Joel Coehoorn May 09 '12 at 04:52
  • Yes, but your statement about " getting hacked after six months and you not finding out for a year." still holds true :) – Jaggu May 09 '12 at 04:52
  • Again, it's just a little bit less likely, and move in that direction is a good one. – Joel Coehoorn May 09 '12 at 04:54
  • @Jaggu, why not separate your authentication database from your application database? That way, you can take full advantage of ASP.NET Membership and also serve your application's need. – Ray Cheng May 09 '12 at 04:56
  • @Ray: That is not at all feasible. Storing Users in different database? If I ever do that, that would mean I can't use foreign keys for constraints because atleast SQL server doesn't support cross database referential constraints. Eg. I have UserId from authentication database and UserID in my application table's post table. I have no way to set referential integrity between them. – Jaggu May 09 '12 at 04:59

3 Answers3

5

Yes you will, or you will have to carry something on the querystring of every single link you create. Programming for the web is completely stateless. You really have no idea what user is requesting what page, or is logged in, unless you give the client (browser) something to send back to the server every time.

If all you get for a request is "www.example.com/page.aspx", then you have no idea if that was me, my brother, my cat, some other random person. In order to know that it is ME that requested that page (and is therefore authorized to use it) you have to use a session cookie or pass a value on the querystring.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Matt Dawdy
  • 19,247
  • 18
  • 66
  • 91
  • Sorry, my question was not clear. I am talking about authentication cookie. To identify who I am I would obviously have a session cookie which would store session ID. I am not talking about session cookie. – Jaggu May 09 '12 at 04:46
  • Sorry. I read the wording of your question as someone new-ish to .net. As I re-read it, I see where you are coming from. And you are right. If you don't need to save state between sessions (ie, have to know if you should pre-populate any info like a "username" textbox) then no, you don't have to persist any sort of info on the client. So, no, no cookie would be needed. – Matt Dawdy May 09 '12 at 04:49
  • Using querystring to pass session / id information may cause security problems, as the user accidentally sharing the url would allow the other user to log on behalf of the original user unless you implement anti session hijacking techniques. – Ramesh May 09 '12 at 04:52
  • Ramesh, yes it can. I was more speaking to the generality of somehow providing a state-ful experience. I didn't mean to endorse using the querystring to keep login state. – Matt Dawdy May 09 '12 at 04:54
  • @MattDawdy It is always advisable to not to keep Authentication / Authorization information in session for security reasons. – Ramesh May 09 '12 at 04:57
  • @Ramesh: Please explain how? Sessions are most secure and on the server. How will somebody visiting our website know the Session contents. If sessions can be a security problem then nothing can be secure in a website. Unless someone hijacks your Session cookie, I don't see any problem with it. Even if someone bychance hijacks the cookie, he can't know the contents of the session which is on server unless our Asp.Net page shows it. – Jaggu May 09 '12 at 05:01
  • @MattDawdy Session cookie contains the session identifier and its not safe, while the forms authentication cookie contains more details regarding the user and is securely encrypted. Using Session cookie to identify the user might result in Denial of Service. See my answer for explanation. – Ramesh May 09 '12 at 05:04
  • 1
    @Jaggu, Ramesh has an extremely narrow view. He is taking ridiculous edge case scenarios and using those to develop a completely black and white view. Now, that being said, I personally always do use the Forms Auth cookie. But that's more often than not because it's just easier. I don't know your business requirements, and neither does Ramesh. I'm sure you'll find the right solution for you. – Matt Dawdy May 09 '12 at 05:09
  • @MattDawdy I respect your views. But I have been dealing with this for security purposes. To me how small it is, use the best practices to be safe. I agree to Disagree. – Ramesh May 09 '12 at 05:16
2

The problem is, HTTP protocol is stateless, so sessions (and any type of persistence between requests) require each consecutive request to prove to server that it's really from the previous client. That way, you must send additional information with the request. For sessions, session id-s are used, usually implemented via cookies or passing session ids as a GET/POST parameter (very unsafe/not recommended). So you need cookies for sessions.

Luka Ramishvili
  • 889
  • 1
  • 11
  • 20
  • Sorry, my question was not clear. I do have session cookie. What I am really talking about is do I have to do FormsAuthentication.Encrypt and store the Cookie in Response? – Jaggu May 09 '12 at 04:47
  • Then no, you were right, you can save everything in session, which is server-side only. You won't need cookies. – Luka Ramishvili May 09 '12 at 04:53
  • Authentication & Authorization is security related and is different from state management. Use things for what they have been made for. Also note that SessionIds can be reused and might result in security problems. – Ramesh May 09 '12 at 04:56
  • That's a different problem. To avoid that, use session id regeneration (hand a request session id, and when it comes back, change again). However, That doesn't entirely solve a problem. heuristics is another measure (checking IP address/useragent/etc between subsequent requests). Use SSL when security is a top priority. But then again, everything can be breached. – Luka Ramishvili May 09 '12 at 05:03
1

Authentication & Authorization is different from session management. At least that is the way ASP.NET team sees it. In case of authentication / authroization failure, the system should not be hitting any of the resources for security reasons as it might result in a DOS attack. If you are using the Session to store the details for authentication and/or authortization and session is from DB then for even an invalid user a DB call is made which is not good from security perspective. Hence use things for what they have been made for.

Ramesh
  • 13,043
  • 3
  • 52
  • 88
  • Sorry, I don't understand your answer. I never said I am storing session is in DB and which invalid call is made? – Jaggu May 09 '12 at 04:57
  • Session can be modified using the provider and for scalability purposed if DB is used in future, then to check if the user is valid or not you need to make a DB call to fetch session information. So, if a invalid user keeps hitting your site you would make DB calls for those requests also, which will cause Denial of Service. For security reasons. The bottom line is use forms authentication for security reasons. – Ramesh May 09 '12 at 05:00
  • I don't have any need to store session in future also. But thanks anyways. If at all the need, I can use OutProc for scalibility. Sql Server should be my last choice. – Jaggu May 09 '12 at 05:09
  • Also, that is one for the security reasons. Please check this SO answer for more detail http://stackoverflow.com/a/2656834/30594 – Ramesh May 09 '12 at 05:12