0

If someone is logging in, I save 2 sessions.

Session["userid"]
Session["nickname"]

The Session["userid"] is used to retrieve data about the user from the database.

The Session["nickname"] is used to redirect the user to his profile page

(Example: www.test.com/mike(in this case, ''Mike'' is the nickname).

I would like to know if this idea is safe? Is it recommended to do it this way, or are there other better options?

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
Swag
  • 2,090
  • 9
  • 33
  • 63
  • You mean that "in this case, ''Mike'' is the *nickname* " , right? – opalenzuela Nov 06 '13 at 15:41
  • Woops, yes I meant nickname, not username. Thanks. – Swag Nov 06 '13 at 15:44
  • You don't need to store the user id, it can be retrieved once logged in on any page using Membership.GetUser(HttpContext.Current.User.Identity.Name).ProviderUserKey – Paddy Nov 06 '13 at 15:47
  • possible duplicate of [Hacking session variables in Asp.NET](http://stackoverflow.com/questions/955130/hacking-session-variables-in-asp-net) – CodeCaster Nov 06 '13 at 16:10
  • @andleer sessions are not _inherently safe_. Grab the cookies directly or sniff the network and you can impersonate another user. – CodeCaster Nov 06 '13 at 16:10

4 Answers4

1

You are not storing two sessions, but rather two variables in the session. There is nothing fundamentally wrong with having two variables, my only thoughts are around what happens if nickname is updated? Wouldn't it better to look up the nickname from the DB each time using userid as a key rather than have a static variable that is fixed after login has taken place?

Having said that, it is more secure to use a Forms Authentication Ticket for this rather than Session. See here for some good reasons: https://stackoverflow.com/a/18077422/413180

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
0

I don't see a big problem there, except if the nickname for a certain user can be changed later on. In that case, the URL to the user's profile will change, and you should adapt properly all the links.

For the URL, I'd use the UID. And to store it in the SESSION variables too. For instance, what happens if the user changes the value of one of the SESSION variables? Will you validate it in every page load?

opalenzuela
  • 3,139
  • 21
  • 41
  • _"what happens if the user changes the value of one of the SESSION variables"_ - how would the user do that? – CodeCaster Nov 06 '13 at 16:08
  • We don't see the entire code of the page, so we don't know how these variables are set and modified. Maybe by sending a POST/GET parameter this value is changed in the SESSION variable but not in the DB, ... – opalenzuela Nov 06 '13 at 16:12
0

Either the data is secure or insecure, it does not really matter if the data is stored in two separate Session objects or not. So if user ID or nickname can be used maliciously by someone, then it is is insecure; otherwise not.

I generally store user information in a single Session object named something like LoggedOnUser, which represents an instance of a class. In your case, it might be overkill to create a class to hold just two pieces of information.

I would advise against using nickname solely as a URL, because what if the nickname value changes? User ID seems more appropriate, as that is less likely to change, if ever. This is how StackOverflow does it with your user profile (stackoverflow.com/users/YOUR_USER_ID/YOUR_NICKNAME), if you have previous nicknames, then the old nicknames will map to the current nickname, based upon your user ID value.

Karl Anderson
  • 34,606
  • 12
  • 65
  • 80
  • To add, a common way to handle this is make a URL like www.test.com/123/mike where 123 is the userid, and mike is the nickname. Your application would then ignore the mike part, and just look at id... but the URL is still human readable. The url of this page is like that: /questions/123/user-with-two... etc. If you edit your address bar and change the plain text part at the end, the page still loads since it's ignored. – John Gibb Nov 06 '13 at 15:52
  • @JohnGibb - agreed and good point about the human-readable, REST-like URLs. – Karl Anderson Nov 06 '13 at 15:54
0

Short answer: it's insecure

User sessions can be hijacked specially if you are not using SSL, it's only the matter of time and depends on some factors such as how professional the hacker is, what facilities does she have, etc. As a solution I'd suggest you to use Forms Authentication.
If you are still insisting on using Session to store kind of this sensitive information, then I'd suggest to generate a temporary key (a GUID for example) and associate that key for a specific amount of time to user object (you would need to store this key in db). You can also bind some more information to this key such as IP address of client. Store this temporary key in Session and handle requests only if this key is valid and IP address had no suspicious change.

Farzan
  • 745
  • 10
  • 25