Re:Exposing sequential IDs is bad Here is how to avoid it
by xyzzy123 on Tuesday February 09, 2021 @05:16PM
(#26083125)
You can also just go ahead and use an auto-incrementing PK but have an "external" representation for it that is not stored.
One strategy (which incurs a little bloat on the wire) is to encrypt the value on the way in and out. You also have the option of incorporating per-session, per-user or per-group information into a computed ID obfuscating key so that IDs are not "shareable" across certain boundaries.
Do use a "key per table" (or "mix" the table name into a computed key) or else encrypted IDs for different types of entity will be the same (e.g. ID 1 from table A will map to the same value as ID 1 from table B).
ECB mode for this stuff is usually fine unless you are filling up a really big part of the key space. You probably do want an integrity mode if you are planning to use something like this to "pre-compute" access control checks (e.g. skip access control on an item lookup because that was done during item listing). Generally do not recommend skipping access control + visibility checks without a compelling reason even if your IDs are in theory unguessable / unforgeable.
The rub is key rotation, and how much you care about it. If your IDs tend to end up being stored permanently external to your system (e.g. it's a blog post ID or something) then a stored random ID is probably better.
For IDs which are not primary entry points to your application then the keyed approach can offer good flexibility, performance and storage characteristics.
One strategy (which incurs a little bloat on the wire) is to encrypt the value on the way in and out. You also have the option of incorporating per-session, per-user or per-group information into a computed ID obfuscating key so that IDs are not "shareable" across certain boundaries.
Do use a "key per table" (or "mix" the table name into a computed key) or else encrypted IDs for different types of entity will be the same (e.g. ID 1 from table A will map to the same value as ID 1 from table B).
ECB mode for this stuff is usually fine unless you are filling up a really big part of the key space. You probably do want an integrity mode if you are planning to use something like this to "pre-compute" access control checks (e.g. skip access control on an item lookup because that was done during item listing). Generally do not recommend skipping access control + visibility checks without a compelling reason even if your IDs are in theory unguessable / unforgeable.
The rub is key rotation, and how much you care about it. If your IDs tend to end up being stored permanently external to your system (e.g. it's a blog post ID or something) then a stored random ID is probably better.
For IDs which are not primary entry points to your application then the keyed approach can offer good flexibility, performance and storage characteristics.