Encrypt / Decrypt Primary Key instead of using UID?

Question

Although I always check that someone is allowed to access a record, I normally use a UID in query strings as I feel it discourages the temptation to "poke around" that ?id=1, ?id=2 does.

I find though that it makes it a bit convoluted to do lookups across multiple tables as you need to store the UID as well instead of just the record id.

If I was to pass an encrypted string of the id number through the query string and then decrypt it to do a database query would this add massive overhead?

This would mean I can just work with the primary key (though I would still obviously check that they have permission to view the record) and could make unique links each session (or change anytime throughout a session) - which would be useful if there's a lot of AJAX driven content you don't want them trying to play with.

Is this a really bad idea?

Answer 1

Why not just base64encode/decode the IDs? If you're only doing this to prevent legitimate users from experimenting with toys they do in fact have permission to play with anyhow, there is really no purpose in doing anything particularly fancy to discourage them.

Answer 2

You should definitely check for permissions on every request. You should never rely on just input data for security!

And remember if you can decrypt it, so can the malicious user who wants to hack in your site.

Using a session to store permissions is a trade off security in favor of performance and I think it would be average security to do it.

But still - if you have sensitive data - check on every request, every time. Don't optimize for few microseconds in the name of less security.

---

As now I saw your real problem in a comment, I can suggest using some sort of additional hash for every refresh the user makes and save it in the session of the user. Then check if the user uses the same hash e.g.:

$hash = md5(microtime());
$_SESSION['secret_user_hash'] = $hash;

And put it in URLS like:

&z=<?php echo substr($hash, 5, 10); ?>

And after a user makes the request just check if it is the same hash.

Keep in mind that if you are using heavy AJAX you should always update your hash, when you change it in the session. The best way i can think of is keeping an array in the session of random hashesh(e.g. 5) and use them on random for the query. So you have a bigger pool and you don't have to update after every request.

Answer 3

Make your UID a hash and pass that through.

Unless you don't want to refactor your entire schema and codebase, then rot13 / base64 encode it.

Answer 4

why would it have any bearing on how you access your data, access and display are two separate entities. your key should be used in a query but you never need display it if you dont want to. you can hash it, you can mod rewrite so it never is visible in the url...there are many options while still querying key in you tables. you can even generate it on the fly for display if you set a pattern. P+IDHASH+ANATTRIBUTE or something. using a base64 on an integer and decoding to run your query will not cost you anything more than milisecond or so. remember you aren't hashing in your queries so they will remain the same you will encode/decode one item which is not an issue with time