The only realistic utility of this feature is that it could let you "guess" when the user has finished typing their password and check it automatically upon com

The only realistic utility of this feature is that it could let you "guess" when the user has finished typing their password and check it automatically upon completion without them needing to press return. That would be a neat gimmick, but I don't see it working out. The issues are twofold: 1. The obvious, it reduces an attacker's search space by the guess accuracy, in this case 256 times. To maintain equivalent security you must compensate for this by increasing the work of your hash function 256 times. Depending on your password's entropy (and thus your default work factor) this may or may not be acceptable. For user-supplied passwords secure hashes should take order of 100ms -- 10ms at the least -- and increasing that many orders of magnitude is definitely not acceptable. This, alas, pretty much breaks the idea, but putting it aside: 2. There will be collisions. The odds of a particular collision are 1/256; since an 8-character password contains seven chances for a collision, ballpark one in 36 of your users will have at least one collision during their password. This means that to maintain the seamless experience, you need to check the crypto-hash on the server silently, without indicating checking or failure to the user (anything else would be confusing). This introduces a number of very weird problems which you can definitely not be sure you have accurately addressed. So, not really a good plan for passwords. Still a neat hack, though.