However, I am not sure the free plan is generous enough to properly evaluate the search engine and see if I can incorporate it into my workflow. And the pricing feels steep. I would have a look at Kagi's pricing model.

[1] https://developer.mozilla.org/en-US/docs/Web/OpenSearch

Comments URL: https://news.ycombinator.com/item?id=17461364

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=14199092

Points: 6

# Comments: 5

Hashing the token protects against this.

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

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