Kent
Active member
The customer verification requires only a token and optionally a domain.
It's up to whoever is asking for the token to keep it safe and check the domain by having a unique file uploaded. This may not always happen.
If tokens are instead generated using a secret salt and a message they could become purposeful tokens.
Example:
$salt is retrieved from the server using the associated license ID/token which is then hashed with a $message. This creates a token which the server can re-generate without having to store the $message. The $purposefulToken is given to the customer along with their license ID/token.
The $message can be something like... "XenForo license verification for XenForo forum user SomeDeveloper on 26 May 2013. Not intended for any other purpose."
The developer can additionally request that a message of their own is appended in case the $message is too generic to trust.
It's worth noting that given an output, the $salt could be brute forced if it is not long enough or random enough.
It's up to whoever is asking for the token to keep it safe and check the domain by having a unique file uploaded. This may not always happen.
If tokens are instead generated using a secret salt and a message they could become purposeful tokens.
Example:
Code:
$purposefulToken = md5($salt . $message);
$salt is retrieved from the server using the associated license ID/token which is then hashed with a $message. This creates a token which the server can re-generate without having to store the $message. The $purposefulToken is given to the customer along with their license ID/token.
The $message can be something like... "XenForo license verification for XenForo forum user SomeDeveloper on 26 May 2013. Not intended for any other purpose."
The developer can additionally request that a message of their own is appended in case the $message is too generic to trust.
It's worth noting that given an output, the $salt could be brute forced if it is not long enough or random enough.