0

After reading through the answers of the related question (the same question but about integer primary keys), I was wondering if there is any reason to hash uuidv4 primary keys and sending the hash to the frontend instead.

Since uuidv4 Ids are random, exposing these ids to the frontend should not leak any information and thus there should not be a problem with sending these ids to the frontend.

So is there any reason and or scenario in which I should obscure database primary keys for the frontend even if these ids are uuidv4 Ids ?

MADforFUNandHappy
  • 103
  • 3

1 Answers1

1

Protecting the key ("obfuscation" might be the wrong word) assumes that there is some attacker which should not see the real key and/or should not be able to use the key. Without such potential attacker (which might be the user itself) there is no need to protect the key in the first place.

Just guessing the key is in your scenario kind of impossible since the key is randomly chosen and large enough. But the key might somehow leak to somebody who should not be able to see the key in the first place or who should not be able to associate multiple uses of the key with each other.

For example it could be that the key represents some user, and that user details could be accessed just by knowing the key. In this case it might be a problem if the key gets exposed in the URL and ends up inside a Referer header when doing some cross-site request. Or it might be that the key represents a user profile. Here would it be a problem if the same key is used on different sites, so that the user can easily realize that it gets tracked.

In these cases it might be useful to somehow protect the original database key. But simply using a fixed hash will not help: a specific key will always be mapped to the same hashed key. And when every access to the database will be based on the now protected key, then knowing the hashed key allows the same kind of access or associations than with the original key.

It would be different if the protection of the key was based on some additional and variable context. Such a context could for example be the current session id, in which case the protected key could only be used if the session id is also known. This would help against accidental leaking the key inside a Referer. Or the context could be the current web site. This would help against the user realizing that no matter which web site they visit they will be tracked and it will always add up to the same user profile. Or the context could be the time so that the key could only be misused within a short time frame etc. If such protection is needed and how it should be implemented depends on the details of the specific use case.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • In my current application I use JWT (json web token) to authenticate the users, I want to avoid having to use server side sessions in this project. So I'm thinking I will just add another table which matches a hash composed of the current date + id to the actual id. I update the JWT every 5 minutes so basing it on the JWT id would mean that the current user might end up with invalid hashes in a displayed table of data mapped to these hashes. – MADforFUNandHappy Nov 19 '20 at 19:01