6

Is there any risk if for example I let to end users to know the primary key associated to users in the database?

Handsome Nerd
  • 281
  • 3
  • 10
  • 1
    It could be a problem if you have URLs like http://example.com/user/123, and by accessing http://example.com/user/124 you can see another user's data. However, that relies on your application not checking access rights properly. Assume they know what potential IDs could be, and check before they can access the data. – Matthew Mar 02 '16 at 14:43
  • After I wrote my answer, it just occurred to me that I may have misunderstood your question. Are you asking if it's ok for users to know their own primary key, or if users can know other users' primary key? (Or both?) – TTT Mar 02 '16 at 15:51
  • @TTT Both, but primary the later one. – Handsome Nerd Mar 02 '16 at 17:54
  • @PHPst Great. My answer assumes the latter. I don't see any problem with the user knowing their own ID if it's a Guid. If it's an Integer then there could be the minor issues I mentioned in the last paragraph. – TTT Mar 02 '16 at 18:04

3 Answers3

5

It depends on what the primary key is. If the primary key is the user's email address or other personal information, then obviously you should never expose it to anyone other than the user. Even if the primary key were the username in the form of FirstName.LastName you should be weary of exposure. Typically though, the primary key will be either an integer or guid which has little meaning by itself, and so I will base the rest of this answer on the typical case.

In general, if the application is designed and secured properly, then revealing meaningless User IDs should not pose a security risk. However, this is not true for all primary key fields in the DB. For example, suppose there is an email validation table that has a guid that appears in a link that is emailed to the user. Those single-use IDs should not be made public because otherwise someone would be able to submit a fake email address and still validate it.

Their are other considerations too that are not necessarily related to security. For example, if you use integer IDs, and you have a public profile page like Matthew mentioned in his comment, then someone could iterate through all of your users and find out information that perhaps they should not know. Examples might be the demographics of your user base, or the exact number of users that your website has, etc. Note this would not be a problem if you use random guids for the primary key, or if you do not expose the public users by the primary key.

TTT
  • 9,122
  • 4
  • 19
  • 31
2

The information you are trying to keep confidential is the records in the database, not the actual labels on the columns. I think its pretty common to use PKs with names like "id", "pid", "cid"... so hiding it may be just an instance of Security Through Obscurity.

Its not something I would advertise but I wouldn't go to great lengths to hide it.

Purefan
  • 3,560
  • 19
  • 26
  • 1
    I did work on a project that **did** obfuscate all the primary keys by using a UUID along with the actual PK - allegedly to prevent enumeration of records. Working with this is a nightmare. For every query to related recordsets the other tables have to be joined in order to resolve the obfuscation. My advise: build a good permission model. This is more secure and easier to handle for everyone involved. – marstato Mar 02 '16 at 16:30
1

As a general rule, the security of an application (and its backend) should never rely on secrecy. Assume the worst case - where everything is known and your line of defense is correct code (correct coding on itself and wise choice of algorithms). Open source projects are auditable by anyone, including (to take the example you mentioned) the structure of a database.

Security by obscurity is not a bad thing on its own but only as an additional layer which has its uses (usually not in pure security, rather as a reflecting layer for some kind of scripted attacks)

WoJ
  • 8,957
  • 2
  • 32
  • 51