With these provisions in place, the password hinting should provide brute-forcing protection comparable to that of regular authentication mechanisms.
VERY bold statement and directly false? Since you a) also hints the hash and, indirectly, b) are forced to use a fast hash.
If there are 256 classes of hashes it is trivial to detect which class belongs to the user, I don't get the brute-force mitigations that is presented. Since this is done for every character sent you could just precompute 256 different passwords that generate the 256 different classes. And brute-forcing 256 passwords is trivial, especially since the current implementation request a new (reduced) hash for every character.
I don't understand what you don't understand, sorry.
Think of it this way - for every new password that you put into the database, run it through some function that spits out N bits. Remember these bits. Then, when you have a password candidate, pass it through the same function and check if the bits are the same. That's all there's to it.
The main exploitation risk is that hinting can be used to quickly reject candidate passwords when running a brute-force discovery (so that only remaining positives need to be run through the full authentication process). The provisions listed are to mitigate this risk, i.e. to make hinting unfit for the quick pre-filtering purpose.
Think of it this way - for every new password that you put into the database, run it through some function that spits out N bits.
And since those N bits are based on the password those N bits tell you something about the password. Directly or indirectly you leak information about the password.
His point is that the tradeoff isn't too bad: leak 8 bits, get pretty lights. Now for me, the pretty lights are basically nil because I don't see the improvement over just failing a login attempt, the way every other system in the world works. Also, the average password probably isn't very complicated (my guess is around 30 bits of entropy on average) which means every bit is precious. If you're going to ditch 8 of them, you better be getting some damn good usability improvements, which this thing doesn't give.
VERY bold statement and directly false? Since you a) also hints the hash and, indirectly, b) are forced to use a fast hash.
If there are 256 classes of hashes it is trivial to detect which class belongs to the user, I don't get the brute-force mitigations that is presented. Since this is done for every character sent you could just precompute 256 different passwords that generate the 256 different classes. And brute-forcing 256 passwords is trivial, especially since the current implementation request a new (reduced) hash for every character.