[stringlytyped]

I am probably missing something obvious, but I am not sure how a timing attack would work during the verification stage (when the emailed token is compared against the database to ensure that it is valid).

If an attacker provides an invalid token, the record wouldn't be found in the database, and the web app would return an error indicating an invalid token. When a valid token is provided, the user is authenticated. You would immediately know whether a token is valid or not—no timing requiring.

However, perhaps there is potential for a timing attack during the initial stage of the reset process, when the user is asking to enter their email address? If the email address provided exists in the database, the server has to 1) generate a token, 2) save the token in the database and 3) send out an email with the generated token. If the email address doesn't exist in the database, the server doesn't have to perform any of these functions.

Potentially, couldn't this allow an attacker to enumerate the email addresses in the web app's database? Of course, in and of itself, this wouldn't allow an attacker to access any of those accounts. And the split-token method suggested by the article wouldn't prevent this enumeration issue.

Is there further potential for a timing attack that I am missing?

EDIT: fixed a typo

[stringlytyped]

I been doing some reading about this in an attempt to answer my own question. It turns out, there is potential for a timing attack during the verification stage. Provided you store the plain text token in the database, an attacker can deduce a valid token by submitting various guesses to the server.

Hashing the token protects against this.

For more detail: http://blog.ircmaxell.com/2014/11/its-all-about-time.html