I had to read the article a couple times. The scenario he's describing is: 1. A user submits a password (with no username) to authenticate. 2. The server

I had to read the article a couple times. The scenario he's describing is: 1. A user submits a password (with no username) to authenticate. 2. The server looks up the password in a hash table. This involves: a. Hashing the password to find the correct bucket. b. Doing a string comparison against passwords stored in the bucket. There are vulnerabilities in two places: 1. Buckets containing more passwords will take longer to return a negative result because they will have to perform more string comparisons. (This irrelevant except in pathological cases.) 2. String comparisons with longer common prefixes will take longer to return a negative result. This is a bad example for a couple reasons: 1. Password inputs are not compared directly to stored values in any real authentication system. They are hashed first. A timing attack here implies a preimage attack against the hash function. 2. Passwords are not global. Passwords are paired with a username. You don't get to time the comparison against every password in the system to determine common prefixes, for example. A better example might have been API tokens, which are often stored in cleartext and fetched directly from the database.