Should I obscure primary key values?

Question

I\'m building a web application where the front end is a highly-specialized search engine. Searching is handled at the main URL, and the user is passed off to a sub-directory wh

Answer 1

PostgreSQL provides multiple solutions for this problem, and that could be adapted for others RDBMs:

• hashids : https://hashids.org/postgresql/

  Hashids is a small open-source library that generates short, unique, non-sequential ids from numbers. It converts numbers like 347 into strings like “yr8”, or array of numbers like [27, 986] into “3kTMd”. You can also decode those ids back. This is useful in bundling several parameters into one or simply using them as short UIDs.

• optimus is similar to hashids but provides only integers as output: https://github.com/jenssegers/optimus

• skip32 at https://wiki.postgresql.org/wiki/Skip32_(crypt_32_bits):

  It may be used to generate series of unique values that look random, or to obfuscate a SERIAL primary key without loosing its unicity property.

• pseudo_encrypt() at https://wiki.postgresql.org/wiki/Pseudo_encrypt:

  pseudo_encrypt(int) can be used as a pseudo-random generator of unique values. It produces an integer output that is uniquely associated to its integer input (by a mathematical permutation), but looks random at the same time, with zero collision. This is useful to communicate numbers generated sequentially without revealing their ordinal position in the sequence (for ticket numbers, URLs shorteners, promo codes...)

• this article gives details on how this is done at Instagram: https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c and it boils down to:

  We’ve delegated ID creation to each table inside each shard, by using PL/PGSQL, Postgres’ internal programming language, and Postgres’ existing auto-increment functionality. Each of our IDs consists of: 41 bits for time in milliseconds (gives us 41 years of IDs with a custom epoch) 13 bits that represent the logical shard ID 10 bits that represent an auto-incrementing sequence, modulus 1024. This means we can generate 1024 IDs, per shard, per millisecond