How to secure the id that are passed in a URL? - php

Question

have a typical website that passed id values in the URL. ex. account.php?id=755
in the account.php page I do check the value
$id = 0;
if(isset($_GET['id'])){
$id = intval($_GET['id']);
}
if($id == 0){
echo 'this account does not exists!';
exit();
}
But, I am trying to find away to encrypt the value 755 prior displaying it and then decode it prior checking the value. So I am not displaying the the actual id but a mask.
My question is this:
1) Is this a good idea to encrypt and decrypt ids? so a mask will be passed and not the actual id.
2) is there an easy way of encrypting the ids by returning a string with a mix of number and alphabets only, using PHP?

Answer 1

But, I am trying to find away to encrypt the value 755 prior
displaying it and then decode it prior checking the value. So I am not
displaying the the actual id but a mask.
It seems like a very cumbersome idea. But if it means something to you and security, then you need to devise an encoding/decoding scheme that works for you. On the most simple level you can perhaps base64_encode the id and then decode it with base64_decode. The examples below are just illustrative. Please clean and adjust for your needs.
$encrypted_id = base64_encode($id);
Now to get it back, just run base64_decode:
$decrypted_id = base64_decode($encrypted_id);
But that is simple to hack.
A better way might be too create some secret “salt” to add to the ID that only your system knows or understands.
$salt="MY_SECRET_STUFF";
$encrypted_id = base64_encode($id . $salt);
In that way, simply using base64_decode is meaningless if the $id decoding does not factor in the salt:
$decrypted_id = base64_decode($encrypted_id);
It would only be usefully decoded with your salt factored into the decryption process:
$decrypted_id_raw = base64_decode($encrypted_id);
$decrypted_id = preg_replace(sprintf('/%s/', $salt), '', $decrypted_id_raw);
The logic is the raw decrypted ID still has the salt mixed in and the preg_replace would strip this out. Since only you know the ‘salt’ guess what? You are secure! But of course if you loose the salt for some reason, your whole system is useless because who knows what about your ids.
But again, this seems excessive unless protecting user IDs is the goal of your app and truly critical to security. If someone guesses an ID what is the worst that can happen? And how can you program against that ‘worst’ scenario.

Answer 2

There really isn't a point other than obfuscating the id's that you are passing. This isn't really any sort of security. An attacker can still guess at id's even if they are encoded.
As a rule of thumb, you should consider all of this information as public. If you are trying to prevent access, you should look into setting up a session.

Answer 3

Well one thing you can do to mask the actual id is to hash it. Example:
Generate the link:
<a href='script.php?id='<?php echo hash('sha256',$id); ?>'>click me</a>
And then on script.php reference hash('sha256',$_GET['id']).
Alternatively you can use mcrypt_encrypt and mycrypt_decrypt if you need more direct access to the actual value.

Answer 4

1- (Reply to the comments) GET allows URL reference and POST is as secure as GET. You can easily use a Firefox extension to modify the value at any time. Asking it to avoid the usage is like asking someone to add JS validation to protect a page. It will defend you against the regulars, not the smart ones.
2- I get that this looks like an homework and you might be limited in your options/will do do so, but you shouldn't rely on "step by step" validation. It's not that they don't work but they are often vulnerable when it comes to an attack if you forget to add something. They also give you a really messy code after you add a bunch of new elements.
Instead of trying to hide what pages your client is accessing, check who's the owner of the ID and who's trying to access it (with a server-side login)
3- If you just want something simple but cool, checkout base64_encode(), it's not actually secure, but it's an easy way to get the job done.

Answer 5

Since the url is account.php?id=755 i assume that you want to prevent the user from "spying" on any other accounts but their own. It wouldn't make sense to obfuscate the id in that case.
Store the id in the users session instead and make account.php retrieve it from there instead, so the user will only be able to see it's own account page.

Answer 6

Reasons why you shouldn't do this:
GET requests are cached and can be easily copy/pasted... resulting in the page you are showing being shared among users and allowing anyone else to access the page
You wont make it more secure
Why should should do this (can overrule the above):
You don't want to show customers orderNumber=xxxx for competitive reasons since competitors could guess your revenue
Solutions:
Change your order numbers to 1184xxxxxx
Use a reversible cipher (see comment at http://de3.php.net/manual/en/function.mcrypt-module-open.php)
Use MD5(orderNumber + SALT) in your database next to the order number