Storing user-id in session variable

Question

When a use is logged in (Through open-id) we are creating a session variable named "UID" and storing the unique user-id in it. Later we are checking the session to see if the user is logged in. I think this is not the right way, but I could not force the team to change this, as I cannot show how this implementation can be cracked. Can anybody show me why (If yes) this implementation is bad?

Answer 1

I can see no situation where you should worry about a server-side Session value being obtained through a client-side exploit. There has been some concern about fake OpenID providers tricking users into passing credentials because of the lack of stature to OpenID, but generally it's unwarranted.

The implementation seems acceptable, but given that you are using ASP.NET you should consider using IIdentity and this ASP.NET OpenID provider:

http://code.google.com/p/dotnetopenid/

It's well tested and has quite a bit of security code and API support built into it.

Answer 2

As Nissan Fan stated, I can see no reason you should be fearful of a server-side session value being exploited.

Just out of curiosity, what are some of your reasons for thinking it's not the right way to go?

Answer 3

My first question would be, what is making you think this is not the right way?

Storing data in this way is very common, secure and it's localized specifically to a user. If you don't like using the session for other reasons such as handling sessions over multiple servers or having to serialize / deserialize the session to a data store (assuming non-memory session) then that is a different arguement but the security part shouldn't be the issue.

Also keep in mind the simplicty of using the session as well. It makes data access to user specific data that you need to access constantly, standard and consistent throughout your application.

EDIT based on comments:

I was wondering the same thing when I started using MVC as well and it seems to be totally fine. I couldn't find anything against the idea. I even asked this question because my custom authorize attribute had to access the session and I stored special role types in it that the out of the box authorization didn't quite fit.