Hashing vs Database Lookup Efficiency

Question

I'm intending on using a hash to generate a verification token for verifying email addresses. The hash would be generated like so:

email:username:salt

The hash is generated with the SHA256 algorithm and the same salt is used for each token generated.

The alternative, and more commonly used, method is to generate a one time UID which is stored in the database and acts as the verification for the new email address.

My question is: is this an efficient (taking processor and disk utilisation etc.. into account) way of achieving the generation of a token for email validation.

Answer 1

The whole purpose of email verification tokens is to generate a token from your secure web server, and email that token out to someone so that they can click a link which contains that token, so you can then verify their account.

The important things to keep in mind:

• The token must be impossible for the end-user to reproduce, otherwise it can be faked.
• The token needs to be cryptographically signed by your web server (ideally), so that the CLIENT knows this is a valid token. This also is important because when the user sends this token BACK to your server, you can verify that YOUR server is the one that created it.
• The token needs to be expireable: you should be able to 'expire' this token if it is not used within a certain amount of time: 24 hours, 3 days, etc.

For this reason, I would not recommend the approach you're taking.

Instead, I would use a JSON web token (this is an ideal use case for them). This other SO question has a decent summary.

Using a JWT will let you:

• Create the token on your web server.
• Set an 'expirey' date on this token so it can't be used after a certain time limit you specify.
• Encode any user-specific data in the token you want: usually a user ID or something similar.

When the user sends the token back to your web server, a JWT will:

• Guarantee that the token was generated by your server and not someone else maliciously.
• Guarantee the token is still valid (in terms of timestamp).
• Guarantee the token hasn't been tampered with.
• Let you view the previously encoded token data (user ID / etc).

I hope this helps =)