I do this with session-based random sequences. It works as follows:
For each list of options (such as the options in a dropdown, or the
names of parameters you can pass to the page), you have an array of
"hashes". I quote the word hashes, because it is a salted hash, e.g. a
hash that also contains the session ID. This means that all hashes are
totally useless outside the current session. Because md5 hashes are
quite long, I compact them somewhat. Acutally, the hashes need not to be
based on the items themselves, and I usually just take an ordinal number
to base the hash on. So it is more of a random number than a hash.
If you want to code an option, id or name, just look it up in its array
in the session. If it is not there, create a new hash and add the
(option, hash) pair to the array in the session. this hash can be sent
to the client, while your real data remains on the server.
If you get a request from the client, just look up the hash to get the
real data again. If it is not there, fail gently. It means that either
someone has stored an old request and issues it again, or that the
session has expired. Or that you have made a programming error...
Example: say you want to send: <input type="radio" name="paymentmethod"
value="creditcard">
When both the name and the value get hashed, it would become something
like: <input type="radio" name="P5H0M" value="S8ND">
And in another session it could be: <input type="radio" name="PTOBW"
value="4JOC">
Any hacker that wants to break into and abuse a session from somebody
else now has to parse your generated pages during that same session to
be able to do much harm. Also, as the innocent user is still actively
using the session, he user will probably notice that something is wrong
and can inform the webmaster.
So it is just a measure to make a hacker's life more difficult.
Best regards
Alvaro G. Vicario wrote:
*** ho******@gmail.com escribió/wrote (11 Aug 2006 01:59:53 -0700):
>Nowadays, many site use encrypted resource ID, rather than plain
numeric ID, such as the following:
>>>http://www.youtube.com/watch?v=p_YMigZmUuk
This is not encryption, it's just a random ID (or maybe a hash). The more
different chars you use, the shorter the string can be.
>"p_YMigZmUuk" will be mapped into a database unique ID (numeric, auto
increment).
I'd just store it as string and unique key.
>What kind of encryption in PHP is the best in handling this job?
You can calculate hashes with md5(), crc32() or sha1(), but you must be
aware that hashes are one-way: you can't get the original string back.
For random strings, you can use uniqid() or you can write a custom function
using mt_rand().
