Indie-Resource.com

Previously, I though of having both a "user id" and a "public user id". The public user id is essentially the user id hashed with a salt.

The idea was so that when I included the "public" user id in a get or post, the actual user id used to make database changes would not be disclosed.

Theoretically it should be safer, but is it actually needed assuming that the database is secure? If the database was not secure, someone with access to it could just search the public userid.

So it is redundant or not? And to what degree is revealing the user id a security threat?

ita Stet.

What exactly are you trying to make more secure?

I don't think exposing a user id is really much of a threat, unless you are blindly accepting post and get data without any validation. If you have a function that deletes a user for example, and it is executed by going to the URL at: site.com/user/[user_id]/delete_user/, you should be matching the user id with the session to make sure that the user that is logged in is the one trying to perform that action. So, I would just say that you should be making sure that you validate data correctly and you should be okay.

Without knowing the full situation/structure you are working with, I would agree with Kaos. You don't have to keep every bit of data out of the hands of your users. Provided you are taking lots of precautions with the other segments in your application, you should be fine.