Sandboxing user data

Inf51

This is may be a stupid question so please humour me!

I'm creating a multi-user site and want to keep each user's data separated from other users even though the records will all be in common tables. I'm just curious as to what the best practice is to do this securely?

I won't be storing anything like credit card numbers but do need each user to be sandboxed so they can only see and edit their own data. Storing a user id (not user name!) against each record is the way I've done it in the past and then assigning the user id to a session variable when they login so all queries against the tables include the user id as a parameter.

Is this best way of handling it? I was thinking maybe a random SHA256 hash for each user might be safer too rather than an incremental user id to link users to records but I'm just not sure if this is the best method or whether it's open to abuse?

Thanks,

Steve

bradgrafelman

Inf51;11029237 wrote:
Is this best way of handling it?

I'm not sure if it's the "best" way, but it certainly sounds like the way I personally would do it.

Inf51;11029237 wrote:
I was thinking maybe a random SHA256 hash for each user might be safer too rather than an incremental user id to link users to records but I'm just not sure if this is the best method or whether it's open to abuse?

I'm not sure how that's any "safer" than the previous method you defined. You mentioned session data, and session data is stored on the server - not the client (i.e. cookie data). Thus, once a user logs in and you retrieve his/her user ID, there's no way for that user to alter the ID value you use in your SQL queries to get his/her specific data since it's always retrieved from the session. (This, of course, is assuming that we're excluding the possibility of session hijacking; if we aren't, it still wouldn't matter if it's an AUTO_INCREMENT'ing integer or a randomly-generated hash.)

Weedpacket

Linking tables by referencing the primary key of the owning table (in this case, the user id in the user table) is the standard way of operating. As long as Fred can't impersonate Barry by tricking you into using Barry's ID to look up Fred's information.

Creating a hash won't be much help. It would certainly slow things down. Sure, user 214 might guess the existence of user 213, and if you used ID numbers supplied by users, then user 214 could give you "213"; if you then used the user-supplied number to look up information then 214 would get 213's information. But you don't do that anyway, do you?

Besides, a Session ID is already a random hash - one that is regenerated for each session without any need to depend on user ID or user name or what-have-you. Session data is not available to users - all they get is the session ID - unless you give it to them.

Inf51

Thanks guys.

No I don't use user supplied IDs - I have separate usernames, passwords and database generated user IDs and as I use them in sessions the user actually doesn't even know their own ID.

I guess I just wasn't sure if users could interfere with session data or find a way around the session day but from what you say it's safe to use and my 'home made' user hash is just an uneccessary complication.

Thanks again!

Steve