| As the author mentions, this solution doesn't create identical distributions between the found case and the not-found case. One other concern is that a db hit and miss could take very different amount of times (e.g., L1 hit vs miss that travels to disk). * Don't waste server time hashing a password if you already know the user doesn't exist. doesn't seem like too big of a concern, since you're spending the time anyway, it's just increasing server load marginally. To solve the first problem, how about running two queries in parallel against the db, one for a fixed username and one for the given username? However, depending on the database, now you may run into caching issues with the fixed username, speeding up that query. Querying for a random username at the beginning might also push that row into the cache. Maybe keep a large, randomized linkedlist of usernames on-disk (initialized on server startup), read out the next link, and use that as parallel username? For these ideas I believe you would need to enforce a max-password-length and take up that many steps to check equality for all passwords. |