I have an service that accepts an HTTP POST request from the end-user's browser. The user passes their only email. I intend the server to generate a token and store this in a database, and email them the HMAC'd token as a means of implementing a "magic sign in" link.

Here is some pseudo-code:

SendSignInLinkToEmail(email string) error {
  // 1. check if the user exists (look in the DB)?

  // 2. If they exist, generate the token and store it in the DB against their uid.
  //     and 3. Send an email and return with no error.
  // they don't exist so do nothing

Step 2 and 3 will take some additional time relative to the scenario when a non-existing email is sent.

Does this make the server vulnerable to leaking email addresses? If so, how do I mitigate against this? Will the timing of 2+3 be "washed away" in the network latency, do would I wait a random amount of time if the user doesn't exist, or what?

  • Why use HMAC if the magic token is random and stored at server side?
    – goteguru
    Jun 11, 2021 at 21:34
  • @goteguru Yes, you're correct. There is no need to HMAC the token. Jul 13, 2021 at 16:14

1 Answer 1


You should not be concerned about this risk, but you can mitigate this very small risk with a little change on the steps you're using.

  1. Generate a random token
  2. Search the database for the user
  3. Display a message that if the email exists, he will receive a token, flush the output buffers and close the connection.
  4. Update the database and send the email if user exists, do nothing if user does not exist.

Up until step 3, the run time is the same, so nothing will change on the user side. After that, steps 4 and 5 won't show anything to the user and he cannot infer anything about those steps.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .