Hacker News Reader

What matters is how the jitter is distributed. If it resolves to a small number of cases (spikes in the p.d.f.), then that means trouble. Also, attackers may work from the same datacenter, meaning that the jitter could be much smaller.

By repeating the query lots of times you can eliminate both the jitter and the sleep.

This was my thought as well, and what I was referring to re: "so many observations on each username" in the parent.

The reason this seems unlikely to me is mainly rate limits and password lockouts. Plus you're adding a multiple on # of requests for each username you want to try. Say your dictionary has 10,000 usernames (very small IMO). That turns into 10,000,000 requests if you need 1,000 observations on each to control for jitter.

Not impossible to find this in the wild, I suppose, but pretty trivial to prevent at any layer.

perhaps bcrypt with sufficient rounds to deter bruteforcing stolen hashes would take >10ms to compute?