Search code examples
databasesecurityhashsalt-cryptography

Hashing vs Database Lookup Efficiency

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.

Solution

  • 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 =)