[incandenza]

This doesn't make any sense. There is no "reduction" of a cryptographic hash that shows you anything other than "100% match" or "not 100% match". Essentially this is just displaying a random symbol along the side until the password matches completely.

EDIT: I'm surprised more people aren't commenting on this. It should be clear that if there were any way to tell if a match were "close", that would totally defeat the purpose of a cryptographic hash.

Essentially all this does it check the password (well, with extra meaningless false positives) without you having to press return.

[sk5t]

Exactly, it's just testing 8 bits of the hash rather than the whole thing. So there is a considerably greater than zero chance of a false positive on totally unrelated words... it's all quite silly.

[latitude]

> it's all quite silly

Which part exactly?

[nowarninglabel]

The part where you seem to be treating it like a breakthrough of some sort, when it's just a fun little gimmick. Your indicator is beyond useless, I just tried it on a user and they had no idea what that was supposed to indicate. There's similar reports out there. The setup is somewhat complex. The extra computational and network resources are not something to sneeze at. It looks like a fun project, but the idea that many sites would actually use this is quite silly

[latitude]

> you seem to be treating it like a breakthrough of some sort

Hahahahaha... seriously, where? What does make it seem that way? This is few hours worth of effort. That damn indicator took the longest to draw. Here, have a look at runner-ups - http://drbl.in/dpbA, http://drbl.in/dpgl

[skattyadz]

"Essentially all this does it check the password (well, with extra meaningless false positives) without you having to press return."

You're absolutely right. That's a far clearer explanation of what's happening here. A standard login form is rate limited to protect from brute force attempts, when calling a url for each character entered, this is problematic. I think the value in his approach is that it makes it significantly harder to brute force the password.

[latitude]

> 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

[incandenza]

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.

[latitude]

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

[tobias3]

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.