Question

Obviously depending on the type/context of data returned to a web front-end (in my case the setup is HTML/Javascript, .NET Csharp back-end and JSON as the data transport), if I have to return an ID say of a message that is an auto-generated primary key (Int64), what is the best way to “hide” this real ID?

For most things of course, I can understand it doesn’t make too much difference, however an application I am working on means if a user “guesses” an ID in the URL to pull back another record, it could prove to be a security issue..

There seems to be lots of ideas/commentary about methods, but nothing has quite clicked.

I was thinking of having an auto-generated primary INT, but also a secondary alternate GUID too. It would be the GUID returned to any front-end process, and of course the auto-generated primary ID would still be used in the backend..

The thinking of course is the GUID would be far more difficult to guess/obtain another one to access a record?

Any ideas or best practices people use?

Thanks in advance,
David.

Answer 1

Regarding security you have several aspects:

• Session hijacking
• Accessing/Modifying/Creating/Deleting records the user is not authorized to
• Non-Authenticated access
• Cross-Site* attacks
• Man-in-the-middle attacks
• etc.

The measures to deal with these depend on your architecture and security needs.

Since you don’t say much about your arhcitecture and security needs it is really hard to give any specific advice…

Some points regarding “ID shouldn’t be guessable”:

• “Correct” solution
  The problem goes away in the moment you implement authentication + autherization properly
  because properly implemented these two make sure that only authenticated users can access
  anything at all AND that every user can only access things he is allowed to. Even if an authenticated user knows the correct ID of something he is not allowed to access this would be secure because he would prevented from accessing it.

• “weak solution”
  create a ConcurrentDictionary as a thread-safe in-memory-cache and put the real IDs plus the “temporary IDs” (for example upon first record access freshly generated GUIDs) in there. You can combine that temporary ID with some salt and/or encryption and/or hash of some connection-specific aspects (like client IP, time etc.). Then on every access you check with the ConcurrentDictionary and act accordingly… one positive effect: after app restart (for example app pool recycling) the same record gets a different ID because this is only an in-memory-cache… though this is hardly usable in a web-farming scenario