Question

I’m using sequential ids as primary keys and there are cases where I don’t want those ids to be visible to users, for example I might want to avoid urls like ?invoice_id=1234 that allow users to guess how many invoices the system as a whole is issuing.

I could add a database field with a GUID or something conjured up from hash functions, random strings and/or numeric base conversions, but schemes of that kind have three issues that I find annoying:

1. Having to allocate the extra database field. I know I could use the GUID as my primary key, but my auto-increment integer PK’s are the right thing for most purposes, and I don’t want to change that.

2. Having to think about the possibility of hash/GUID collisions. I give my full assent to all the arguments about GUID collisions being as likely as spontaneous combustion or whatever, but disregarding exceptional cases because they’re exceptional goes against everything else I’ve been taught, and it continues to bother me even when I know I should be more bothered about other things.

3. I don’t know how to safely trim hash-based identifiers, so even if my private ids are 16 or 32 bits, I’m stuck with 128 bit generated identifiers that are a nuisance in urls.

I’m interested in 1-1 mappings of an id range, stretchable or shrinkable so that for example 16-bit ids are mapped to 16 bit ids, 32 bit ids mapped to 32 bit ids, etc, and that would stop somebody from trying to guess the total number of ids allocated or the rate of id allocation over a period.

For example, if my user ids are 16 bit integers (0..65535), then an example of a transformation that somewhat obfuscates the id allocation is the function f(x) = (x mult 1001) mod 65536. The internal id sequence of 1, 2, 3 becomes the public id sequence of 1001, 2002, 3003. With a further layer of obfuscation from base conversion, for example to base 36, the sequence becomes ‘rt’, ‘1jm’, ‘2bf’. When the system gets a request to the url ?userid=2bf, it converts from base 36 to get 3003 and it applies the inverse transformation g(x) = (x mult 1113) mod 65536 to get back to the internal id=3.

A scheme of that kind is enough to stop casual observation by casual users, but it’s easily solvable by someone who’s interested enough to try to puzzle it through. Can anyone suggest something that’s a bit stronger, but is easily implementable in say PHP without special libraries? This is getting close to a roll-your-own encryption scheme, so maybe there is a proper encryption algorithm that’s widely available and has the stretchability property mentioned above?

EDIT: Stepping back a little bit, some discussion at codinghorror about choosing from three kinds of keys – surrogate (guid-based), surrogate (integer-based), natural. In those terms, I’m trying to hide an integer surrogate key from users but I’m looking for something shrinkable that makes urls that aren’t too long, which I don’t know how to do with the standard 128-bit GUID. Sometimes, as commenter Princess suggests below, the issue can be sidestepped with a natural key.

EDIT 2/SUMMARY:

• Given the constraints of the question I asked (stretchability, reversibility, ease of implementation), the most suitable solution so far seems to be the XOR-based obfuscation suggested by Someone and Breton.
• It would be irresponsible of me to assume that I can achieve anything more than obfuscation/security by obscurity. The knowledge that it’s an integer sequence is probably a crib that any competent attacker would be able to take advantage of.
• I’ve given some more thought to the idea of the extra database field. One advantage of the extra field is that it makes it a lot more straightforward for future programmers who are trying to familiarise themselves with the system by looking at the database. Otherwise they’d have to dig through the source code (or documentation, ahem) to work out how a request to a given url is resolved to a given record in the database.
• If I allow the extra database field, then some of the other assumptions in the question become irrelevant (for example the transformation doesn’t need to be reversible). That becomes a different question, so I’ll leave it there.

Answer 1

I find that simple XOR encryption is best suited for URL obfuscation. You can continue using whatever serial number you are using without change. Further XOR encryption doesn’t increase the length of source string. If your text is 22 bytes, the encrypted string will be 22 bytes too. It’s not easy enough as to be guessed like rot 13 but not heavy weight like DSE/RSA.

Search the net for PHP XOR encryption to find some implementation. The first one I found is here.