0

In this site we have ids for categories. These are essentially the primary key of categories table. They are sequential and auto-incremental.

This id is passed around the site as hidden field, session value etc. In the backend whenever a form is submitted, or some db update is done etc, the id is validated to make sure that it has not been tampered with. 

$id = $this->getPostField(cat_id);
$id = validate($id); //perform checks on the id field

I could encrypt/decrypt the id so that even if anyone looks at the hidden field he couldn't really understand its value. However my question is - is it really necessary or will I be just adding a layer of complexity which only increases the overhead without too much value add?

$id = $this->getPostField(cat_id);
$id = validate(keyDecrypt($id)); //perform checks on the decrypted id field

I guess why I am asking this is because the id is not a very sensitive data like a credit card or social sec number. It does not really matter that the user can see it if he reads hidden fields. As long as I am validating it in the backend I am assuming I should be fine (?)

Undefined Variable
  • 4,196
  • 10
  • 40
  • 69
  • I think this help u.. http://stackoverflow.com/questions/3422759/php-aes-encrypt-decrypt – NULL Jul 01 '14 at 12:17
  • Are you familiar with the term security through obscurity – kero Jul 01 '14 at 12:17
  • @kingkero Are you familiar with the term - "why don't you give a complete answer"? – Undefined Variable Jul 01 '14 at 12:19
  • @Aminul - thanks for that link. I guess I can find a way to do the encrypt/decrypt. But if I am checking the id properly in the backend, does it really matter if I encrypt the number or not? I mean, it is not an email/password/credit card number or any such important/sensitive piece of data. – Undefined Variable Jul 01 '14 at 12:21
  • @open_sourse - no it does not really matter. if any one could get the id he/she could understand why it is needed and which table it belongs to.. – NULL Jul 01 '14 at 12:24

2 Answers2

1

You can, too, add an uniqid to every Category, and check if id + uniqid are linked to a category. This uniqid can even be the slug, for example

But it looks like to be an overhead, if someone really wan't to change something client-side, it is still possible. As long as you check server side, it's good. And as you save it in the session, it's quite fast and easy.

As said above in comments, it's security through obscurity, and it won't protect you for long if the attacker really wan't to.

It's up to you to see if it's valuable to use the id, another field, or encrypt it ... (you may also hash it, as the id is stored in session :-))

punkeel
  • 869
  • 8
  • 12
0

I don't consider this security through obscurity.

if anyone looks at the hidden field he couldn't really understand its value.

There isn't much to understand in the first place. id itself doesn't have any useful information, it just refers to a particular record.

However, since it's an auto-increment integer, it exposes information like how many categories there are. Encrypting the ids with a key makes that meta information confidential, and it does so with a well-defined secret: the encryption key. This isn't security through obscurity, because even if people knew the exact scheme, they still couldn't figure out the category count without the key.

guest
  • 6,450
  • 30
  • 44