The author appears to have given some consideration to security implications (one-use tokens, demanding relatedness, delays, presumably some protection against timing attacks, etc.); my main concerns are:
* This approach requires granting access to read the raw password hash to the password-tester application
* High resource cost for marginal user utility
* These password-check attempts do not count as logon failures, likely defeating intrusion detection measures
There are probably more issues but there are top-of-head. FWIW Lotus Notes has always done something similar as you type.
It does. What I mean by 'the application' is the backend / web app.
To put it another way, a better design allows no application code to read the hash from storage; the application can only ask the storage or security service to compare a supplied value for correctness. Fail enough times in rapid succession and the security service locks the account for a few minutes, preventing any comparisons during that period.
Opening the door to testing the hash itself outside of these constraints is the weakness I am suggesting.
There are probably more issues but there are top-of-head. FWIW Lotus Notes has always done something similar as you type.