Jump to content
Larry Ullman's Book Forums

Why Is It Bad To Display A User's Id Publicly?


Recommended Posts

Larry,

 

I just had a quick question.  I remember you saying that it is not recommended to show a user's ID on a page, but I was wondering why this is so bad?  If you have taken the necessary precautions like validation, using prepared statements, aren't concatenating strings in queries, etc... then there is absolutely no way that a user could do anything to manipulate his record in the database.  Second, I think that in certain situations displaying the user's ID (or at least a unique ID that can be connected to that user) is almost necessary.  For the site Jon and I are working on now, customers can add users to a private list.  When the customer is adding a user, they must click on a link next to the user's picture.  This could not be achieved without embedding some kind of unique ID in the link that is associated with the user.

 

The only other solution I can think of to try and hide the user ID would be to add integers of a predefined length to both ends of the user's actual ID and then strip them off when it has to be processed.

 

Example:

 

user id: 00237

 

Number displayed in the link:  6253623774838

 

When the id needs to be retrieved, the 4 numbers at the beginning and end are stripped off and the remaining number is padded with zeros.

 

Another way would be to encode the date the user registered and use that instead.  However, all of this seems a bit convoluted to me!

 

What do you think?

 

Thanks,

 

Matt

Link to comment
Share on other sites

I think almost anything that's supposed to be a HTTP GET request both could and should have visible IDs. There's nothing wrong, in theory, getting a user profile by a call to profile.php?id=X. The same holds true for any actions that should be publicly available to do against a user. message.php?user_id=X is totally OK in my book.

 

That said, editing information or permission restricted actions is another case. That's pretty obvious though.

 

To talk concretely, I would say adding a user to a private list through a ID GET param is a good solution. As long as the user should be able to add the other, there's no need to add anything to the mystery. Other measures could be applied here.

- Can you disable other users adding you to their lists?

- Should there be a limit to the number of added users?

- A maximum number of friend request per minute/hour/day?

- Can users only add certain types of other users?

 

All of the above should be quite simple to implement checks for. Those can be real restrictions. Using "invisible IDs" are security through obscurity. It doesn't work.

 

To talk consequences, is the application "hacked" if a user manages to add the "wrong" user though bad input? A user is allowed to add user ID 15, but not if it's written "ABC" as input? There's no security concern there.

Link to comment
Share on other sites

Antonio,

 

Thank you very much for the informative advice!

 

I agree with you that obscuring the id doesn't do anything to improve security and will use more processing to encode/decode it.

 

In our case, only paid customers can "add" users, so users can't add other users.  Also, there limit to the number of users a customer can add, so that won't cause any problems.

 

Thanks again,

 

Matt

Link to comment
Share on other sites

 Share

×
×
  • Create New...