is it possible the generated validation code in user.cgi would have the same value in the future?
Feb 29, 2000, 7:30 AM
Veteran / Moderator (6956 posts)
Feb 29, 2000, 7:30 AM
Post #2 of 9
Views: 3391
I'm not sure what you are asking, but not having looked at the code, usually these things are randomly generated from the time or a munge of time+process ID.
Could two validation codes ever be the same? Possibly. Is it likely, probably not, but they say the Internet has proven the old "Infinite # of monkeys" theorum to be wrong too
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/
Could two validation codes ever be the same? Possibly. Is it likely, probably not, but they say the Internet has proven the old "Infinite # of monkeys" theorum to be wrong too
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/
Feb 29, 2000, 1:38 PM
Novice (15 posts)
Feb 29, 2000, 1:38 PM
Post #3 of 9
Views: 3417
Code:
# Add the user in. if ($LINKS{user_validation}) {
$code = (time) . ($$) . (int rand (1000));
$in_r->{Status} = "Not Validated";
$in_r->{Validation} = $code;
$db->add_record ( $in_r );
I have to make sure that '$code' won't have the same value ever, because I'm planning to use the same code for building my detail page.
e.g :
if the '$code' produce 9839839839383, than the detail page filename for the link will be 9839839839383.html
I have already setup everything, just to make sure that the '$code' value won't mess everything up in the future. =)
Or maybe, You have some other trick or suggestion for me to use ? please let me know.
Feb 29, 2000, 2:21 PM
Veteran / Moderator (6956 posts)
Feb 29, 2000, 2:21 PM
Post #4 of 9
Views: 3391
The only way to make sure that it won't ever be the same is to use a sequential system.
_BUT_ if you do that, then it's easy to crack the validation codes, and that defeats the whole point.
What you need to do is pick a code that is reasonably expected to not repeat -- but two sequential users could theoretically get the same code -- statistically they wouldn't be expected to -- but it's _possible_
Don't use that code for building detail pages. Once the user signs in, and validates, use their "ID" from the User table, that won't repeat ever. It's sequential.
It also makes a better more logical linking mechanism.
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/
_BUT_ if you do that, then it's easy to crack the validation codes, and that defeats the whole point.
What you need to do is pick a code that is reasonably expected to not repeat -- but two sequential users could theoretically get the same code -- statistically they wouldn't be expected to -- but it's _possible_
Don't use that code for building detail pages. Once the user signs in, and validates, use their "ID" from the User table, that won't repeat ever. It's sequential.
It also makes a better more logical linking mechanism.
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/
Feb 29, 2000, 5:00 PM
Administrator (9387 posts)
Feb 29, 2000, 5:00 PM
Post #6 of 9
Views: 3393
Well, the random string is pretty secure from duplications. Consider that it has the current time in it, so you only have to worry about duplications within the same second. Also, it has the process id of apache, so you only have to worry about people hitting the same apache child in the same second. Finally, a random number is thrown in, so your chances of a duplicate are _very_ small. I wouldn't be worried about it.
If you are, you could make the field UNIQUE in mysql, and then catch the error and generate a new random number if the add fails.
Hope this helps,
Alex
If you are, you could make the field UNIQUE in mysql, and then catch the error and generate a new random number if the add fails.
Hope this helps,
Alex
Feb 29, 2000, 5:32 PM
Veteran / Moderator (6956 posts)
Feb 29, 2000, 5:32 PM
Post #7 of 9
Views: 3394
I had thought of that ... but it seemed extra complex to trap the error if there is a duplicate random number... but the concept of the random number is such that it theoretically could occur in sequence, or duplicate itself.
The chance may be infinitely small, but if you are using any sort of random number it _could_ duplicate.
So, by not using sequential numbers, the only way to guarantee no random duplication, is to trap the duplicate error and generate a new random number. This needs to be in a loop, since the odds of generating a second duplicate could actually be higher than not -- since whatever cuased the duplication could cause additional ones (there is a law or a name for that .. and it's not "chaos"....)
Anyway... I try to be simple, and it seemed the simplest solution would be to use the UID. That won't ever duplicate....
If you stored this key in a character field, you could use the UID plus a '.' plus the validation code. That would _NEVER_ dupliate, because UID's are sequential, but you couldn't find the file randomly because of the random number appended after a '.' so the file name would be -- UID.random.html
That wouldn't cause a problem, and it would let a system admin rebuild the file system easily if something happened as well... since each file is linked to the user record.
(I'm always concerned about being able to rebuild as well.)
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/
The chance may be infinitely small, but if you are using any sort of random number it _could_ duplicate.
So, by not using sequential numbers, the only way to guarantee no random duplication, is to trap the duplicate error and generate a new random number. This needs to be in a loop, since the odds of generating a second duplicate could actually be higher than not -- since whatever cuased the duplication could cause additional ones (there is a law or a name for that .. and it's not "chaos"....)
Anyway... I try to be simple, and it seemed the simplest solution would be to use the UID. That won't ever duplicate....
If you stored this key in a character field, you could use the UID plus a '.' plus the validation code. That would _NEVER_ dupliate, because UID's are sequential, but you couldn't find the file randomly because of the random number appended after a '.' so the file name would be -- UID.random.html
That wouldn't cause a problem, and it would let a system admin rebuild the file system easily if something happened as well... since each file is linked to the user record.
(I'm always concerned about being able to rebuild as well.)
------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/