Hacker News Reader

> displaying a random symbol along the side until the password matches completely

This is exactly what it does. See this comment for details - http://news.ycombinator.com/item?id=3689051

But the "reduction" adds no benefit. You might as well just check the whole hash and eliminate the false positives, which have no purpose. (A false positive has no correlation with being "closer" to the real password.)

All you're doing is shifting the time at which you check the password, from when the form is submitted, to when each key is pressed.

You seem to be wanting to assume that a correlation between some subset of the input bits leads to a correlation between some subset of the hash bits. But that's exactly what a cryptographic hash function is designed to prevent.

EDIT: The brute-forcing issue assumes that you treat form submissions and keypresses differently. In other words, why would you ignore a billion mismatches on keypresses and then raise an alarm on a few failed form submissions? You're just dividing the detection into two different phases, for no real purpose.

False positives are needed to mitigate the risk of brute-forcing abuse.

If you need that you can always rate limit it with the exception that you can add to passwords e.g. if you queried "abc" perviously "abcd" does not count to the rate limit, but "bcd" does.

Reply on news.ycombinator.com