| 5:27 pm on Aug 28, 2004 (gmt 0)|
Sounds like a job for uniqid() [fr.php.net]
| 6:51 pm on Aug 28, 2004 (gmt 0)|
|Sounds like a job for uniqid() |
Thank's that's something I can use.
| 8:58 pm on Aug 28, 2004 (gmt 0)|
But does it have a security feature in it? Can someone change one or two characters arbitraly to get soneone else's valid code?
I'm planning to give the ID to the users but I don't want them to change it and get another user's ID. It's just like your credit card number. Changing the number does'nt get you someone else's credit card right away. The number has a rule that it has to follow in order to be valid.
| 10:49 pm on Aug 28, 2004 (gmt 0)|
This is what I use to generate alphanumeric codes:
$data = "AbcDE123IJKLMN67QRSTUVWXYZ";
$data .= "aBCdefghijklmn123opq45rs67tuv89wxyz";
$data .= "0FGH45OP89";
for($i = 0; $i < $length; $i++)
$random .= substr($data, (rand()%(strlen($data))), 1);
| 11:11 pm on Aug 28, 2004 (gmt 0)|
What you really need is encryption. Generate incrmental numbers, i.e. numbers that follow on on the next. these are your internal IDs. Now, when you hand them out you encrypt them. If you use strong enough encryption, they should not be guessable or incremental anymore, as well as beeign able to be converted back into the real ID.
| 12:00 am on Aug 29, 2004 (gmt 0)|
Or, use a check-digit scheme if you want a measure of security. If you randomly generate a 9 digit alphanumeric, you can use the final digit for the check digit.
You can re-use the credit card check digit scheme for this (google, PHP implementations are everywhere).
Just generate your 9 character A-Z, 0-9 string, convert it from base36 to base 10 (base_convert('7JDA2N4G4', 36, 10)), run that number through the check digit routine and tack the result onto the end. Presto, 10 digit random alphanumeric with a check digit.
| 12:44 am on Aug 29, 2004 (gmt 0)|
If you have 50 users and used a two-digit code, then 50% of the possible permutations would be valid at any one time. You need to make the number long enough such that only a very few of the possible combinations are valid at any one time.
If you use a random number, then they will not be unique. It is possible for a number to be repeated exactly the same after a small interval. Some of the suggestions above do look useful though.
| 12:52 am on Aug 29, 2004 (gmt 0)|
|Generate incrmental numbers, i.e. numbers that follow on on the next. these are your internal IDs. Now, when you hand them out you encrypt them. If you use strong enough encryption, they should not be guessable or incremental anymore, as well as beeign able to be converted back into the real ID. |
You really need one way hash here, ie MD5. However be careful because if you use obvious things like consequtive numbers then you open yourself up for a "known plain text" attack. MD5 hashes are easily recognisable (its most obvious choice and its known to be 128 bit long (256 if in hex code)).
A better way of doing it would be to merge few strings like your internal number, plus time of creation, plus some pseudo-random big number and then MD5 the whole lot. This should be unique as well and if its not then you should contact RSA and get Nobel Prize of the year for discovering multiple collisions of MD5 algo!
| 4:24 pm on Aug 29, 2004 (gmt 0)|
contact RSA and get Nobel Prize of the year
Actually, it's only $10K for the MD5 collision algo and the best you could get is the Turing prize, but it's worth settling for. Let us know when you get the solution ;-)