Not necessarily. You could store $10 \choose 5 = 252$ hashes for each user.
We did something similar for call center caller authentication (you don't want the operator to get the whole PIN of the user, so he asked only for e.g. two characters). Not that this would be very useful, security-wise.
> Not necessarily. You could store $10 \choose 5 = 252$ hashes for each user.
Wouldn't this be way easier to crack if the password hashes were leaked? Once you crack one 5-letter hash, you can trivially crack the one that shares 4 characters with it, and do that repeatedly until you have all 10 characters.
You're reducing the effective search space not by a factor of 252 (8 bits of entropy, which would often be acceptable) but to its square root, losing half of the entropy.
Although it seems like security theatre, the PIN solution actually sounds more useful. The typical attack on a system protected by PINs, like bank cards, is not cracking hashes offline - it's that the attacker tries the PINs on the live system and gets locked out after a small number of failures. Assuming the bad actor can't just initiate another call and ask for the other two digits.
Oh, sure, the authentication itself is fairly usable for the given usecase, the hashing is security theater. I advocated not hashing those PINs, but you know, standards, auditors, etc. "Passwords must be hashed", security theater or not.
We did something similar for call center caller authentication (you don't want the operator to get the whole PIN of the user, so he asked only for e.g. two characters). Not that this would be very useful, security-wise.