5 ms·
Typical network jitter is in the range of +/- 10ms over the Internet, optimistically. So the hash computation needs to be well over 10ms to be noticeable, or yo
by sjbase 9y ago
Typical network jitter is in the range of +/- 10ms over the Internet, optimistically. So the hash computation needs to be well over 10ms to be noticeable, or you need so many observations on each username that something emerges statistically.
Both seem unlikely. Am I missing something?
- richardwhiuk 9y agoBy repeating the query lots of times you can eliminate both the jitter and the sleep.
- sjbase 9y agoThis 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.
- amelius 9y agoWhat 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.
- beaconstudios 9y agoperhaps bcrypt with sufficient rounds to deter bruteforcing stolen hashes would take >10ms to compute?