[Not Confirmed] Activation id discrepencies.

[Paul]

Hi,

When a new user registers on a vB2.x forum and e-mail verification e-mails are enabled, a unique random number is generated called the activation id. This number is created as follows:


if ($verifyemail) {
// make random number
mt_srand ((double) microtime() * 1000000);
$activateid=mt_rand(0,100000000);


This number is then stored in the useractivation table along with the new user's userid and the dateline.

In approximately three instances thusfar over a period of two years, I have seen users complain that they were not able to activate their accounts trying both the link and filling out the activation form. Each time, I requested that the user forward me the activation e-mail they received and verified that clicking the link in the supplied e-mail would not activate the account.

The matter was resolved by resending the activation codes via the admin cp, which in fact, generates a new activation id for the user.

The same thing occured today, however I decided to examine it a bit further and look at the values in the useractivation table and compare them to the e-mail the user received. The activation ids were completely different:

The link in the e-mail: register.php?a=act&u=<userid>&i=26424750 (where <userid> was the userid of the user in question)

The value of activationid in the database: 41375

I don't see anything in the code itself that could explain such a discrepancy. The only odd thing I've noticed thusfar is that the activationid column is char(20)... certainly not an int field, but I'm not sure what affects if any that would have on any of this.

I'm verifying now with the user that they did not attempt to resend the activation e-mail prior to contacting me (the only explanation I can think of). Should that be the case, I will flog the user with a cane.

[Steve Machol]

I'll move this to Bugs to see if a Dev has any ideas.

[Paul]

I'm verifying now with the user that they did not attempt to resend the activation e-mail prior to contacting me (the only explanation I can think of). Should that be the case, I will flog the user with a cane.

User writes:


Man, you've got me all mixed up now.......I think I only have one activation email......however, I think I did do the "re-send" activation at one point.


I've asked the user to look very carefully at the inbox of the account used to register with to verify that this in fact is the issue. If it is, I recommend the following steps be taken:

That the default activation mail specify that only the latest mail received will work OR that a similar message be displayed to the user when having the activation codes resent. That the column type for the activation id be re-examined. I still don't understand why char(20) was used (perhaps to accomidate an older version of vBulletin?) instead of int(9) That the justification for altering the activation id upon resend of the activation e-mail be reconsidered. Users who activate aren't automatically logged in, so I don't see the concern that should someone else obtain access to the activation id that there would be a security risk requiring it to be changed. In fact, I think in most cases where an activation id would need to be resent (at least in our experiences) there's some sort of delay on the user's mail server--eventually they get all the e-mails delivered.

Perhaps a better method would be to only regenerate an activation id in a case where the activationid record doesn't exist in the useractivation table. A simple SELECT with the userid would determine whether or not it exists.Looking forward to hear if anyone else has had similar issues.

Best wishes,
Paul

[Scott MacVicar]

paul the problem then exists that you can brute force this. Since its a numeric value.

I'm looking at the code just now.

[Paul]

paul the problem then exists that you can brute force this. Since its a numeric value.

I'm looking at the code just now.


How about an alphanumeric replacement then? You'd be able to brute force it regardless of whether it was resent or not. I don't see how resending the activation id would heighten the likelihood of someone attempting to brute force the activation id.

Is that what you're saying?