If you have an index on your "Email" field in the database, there may be discernible difference between the time taken to check the index and return '0 rows', vs getting a match and actually reading the appropriate data to build the result row.

I don't know if there's a solution to that in the general scheme of things, other than making the variance of query times between no user and some user as small as possible.

And, if you're returning the correct error message, it doesn't matter.. the whole point of a timing attack is to determine the difference.

IMHO usability is more important. There are other ways to improve security. Rate limiting with < N failed attempts via an IP in under < X minutes.

Your code has precisely the timing attack he tried to describe in it. You're returning early when a user doesn't exist.

So? I'm advocating showing the correct error message... a timing attack is irrelevant in this case.

For that matter, adding a random 500-2000ms timer before returning a failed result would likely be as effective, and not lead to a bad user experience.