This looks like an amazing tool. I've always thought it would be great if I could curate my own search index. And the way results are summarized with citations is really cool.
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.
You might want consider using OpenSearch [1] to make it easier to add Blog Surf to browsers as a search engine that can be accessed from the location bar. I added it manually in Firefox but it would have been handy to just be able to right-click the search field and choose "Add a Keyword for this Search".
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.
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?
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.