Is it dangerous to store the real User Id on client side?

Hi !

I have a user process registration consisting in three form pages. When the user submits the first form page the data is inserted into the DB, then the DB returns the User_Id number to the app. Now I am using this unique Id number and a Session variable in order to maintain state and to do several operations with the DB through the three form pages. To do this I store this unique Id user number in a hidden field (on the first form page), and then I need to pass that value through the three form pages (forward and back) to know the identity of the user on every form page. Well, I have two important doubts:

1. I know that using hidden fields, users can see the data containing in it. It can be a danger to store the real user id returned by the DB in a hidden field (for security reasons)? Or is it better that the DB gave it back another unique guide number for each user, instead of the real User_Id number?

2. To pass this data (unique Id for every user) from one page to another (forward and back), I am considering two ways: With the simple and less secure ‘Request.QueryString()’ or with the more complex but more secure ‘Server.Transfer’. In my case, What is the best way?

Thank you,
Cesar

somewhat

depends on how you store it

look into System.Security.Cyrptography. Or, do your own byte shift.

Well... thanks, but my real question was, whether this data (database User Id) is sensitive or dangerous to store on client side? If yes, which is the best way to encrypt or modify this kind of data?

Personally I pass everything by POST by using hidden form fields - but as you said, the user can see this.
The way I do it, is that I have a table in my server that stores sessionids, and their associated userid.

I store the sessionid for that user in a cookie.
Every request to the database calls the userid for that sessionid, and then queries the database based on that.


But - if the user every did get their userid - is there anything they could actually do with it?
If you told me my userid, what could I use it for?

I usually store it user id's in session state. I don't know how many users you plan on having live at one time, but then should be a viable alternative.

Plenderj,

Thank you, this is just that I am really asking, although you have answered with another question :). I suppose you think that storing database User Id on client side isn' t a danger for anything. If you have much experience on that, and with this kind of security issue, I rely on you.

On the other hand,.. After you have stored the DB User Id in a hidden field, then How you pass this data (db user id) from one page to another?



Hi Nemaroller,

I want to store the user id on client side so that after the session has finished, I can continue identifying the user in order to store other user information into the DB.

I pass everthing by POST, and then use Request.Form() on the code-behind of the asp.x page :)

Ok, thank you very much!

Okay I'm confused. What exactly are you doing? To me it sounds like you are using a UserId as a form of password?

The site I am working on has what I call Security Zones. Each section has a password. I have a User table that has a bunch of user info in it. Along with basic stuff I have a bit field for each security zone. IsAllowedZoneName. This can be added be the dba for new zones or a tool can handle adding the field and it is false by default. This actual adds an extra layer of security. You have to

1) be a user.
2) know the correct password.
3) Be marked to access this area/Security Zone/IsAllowedZoneName

all the passwords are stored in the database encrypted. I have a static/shared method that encrypts and decrypts them for me.

Are you looking for something like that are something like when you login here on the forum?

Oh in my scenario they know the username and log into the site. The password is used to direct them to a certian area. When I change the password everyone granted access to that area get an e-mail about how to get the new password. They then have to know thier maiden name or something. It's not done yet.

Well, it seems that you don’ t understand my purpose. I am going to try explaining it again, and remember the scenario, a new user process registration consisting in three form pages: (try to read my explanation slowly, and thinking every sentence)

When the user presses the submit button of the first form page, the data is sent to the DB, the User Id is returned to the app and stored in a hidden field, and the page is redirected to the next form page. On the second form page, a Session called ‘Session(“New_User”)’ starts when the page loads, as well through ‘Request.Form()’ the User Id from the first page is stored in this second page. Then, when user submits this second form page the data is inserted into the DB according to the User Id stored on the page, and the page is redirected to the third form page, and so on. But if the session ‘Session(“New_User”)’ finishes, the user can’t continue filling the form and he/she needs to login normally. But although the session ‘Session(“New_User”)’ has finished, I have the User Id permanently on client side, passing it from one page to another, in order to collect other user information, for example what pages had visited, the time the visit lasts, user preferences, etc.. and I store all this data into the DB during all its visit, regardless of she/he is authenticated or not. Then, if the user wants to access to its private account, he/she needs to login with a user name and password normally.

Well try to thinking very slowly use the session

and by the way my first post would have solved your problem because you could encrypt the data put it in the field and then decrypt it if you had done reaserch that is

Magiaus, thanks for your advice :), but if you don' t understand my case, my purpose, as I can see, I can' t follow your advise spending a lot of hours without knowing if you have understood me.

What ever you say boss. I would advise putting the name in the Session("name")/Session[""] and clearing after your done on the third page though. It's quite simple and as far as I know secure. Unless the user has a packet sniffer. Sorry to waste your time.

So really what you need is a way to seperate authenticated users(members) from non-authenticated users (guests), and allow a way for guests to step through a process to become authenticated members? Correct?

With the non-authenticated users (guests), I only want to identify them in some places, assigning a database User Id to them, and thus storing some information regardless of the session state.

This is just a suggestion but I have a hard coded account the lives in my dll in the login code. It give acces to certian ares and not others, but it is driven by my SecurityZone system. Basicly I have a guest Zone. that is hard coded not in the db. I keep all the current users login results(name, password, zone, id,..) in the session so that my base page class can check for the security before doing anything. So I have a class SecurePageBase that my secure pages inherit from. That page check the session info and handles letting people in or throwing them out. The base class knows about the guest being hard code and checks for it.

Why do you seem to hate the session? It's damn useful.