Does anybody use deliberately short hash lengths for passwords to increase the chance of false positive collisions in the event of a brute force attack on the database?
When trying to decide on a hash length, my default assumption was "storage is cheap, make it huge". However, in reality since the weakness of a password is often that it's short or easily guessable, no amount of hash length would help users in the case of a database breach.
That got me wondering, does anybody deliberately use short hashes in order to obscure the original password better? If there are only, say, a million possible hashes, you're going to get collisions all over the place. When the application is running normally, it won't let an attacker try more than a handful of times anyway, reducing the chance of a lucky guess almost to 0. If the database is compromised, an attacker is going to be brute forcing and finding all the easy passwords no matter what your hashing scheme. However, if the chance of collisions is high, a brute force is likely to find a password match that the user doesn't actually reuse anywhere else.
I suppose you would need to choose a length that sufficiently protects random input from colliding in a handful of tries while also having a relatively high chance of having multiple dictionary words that match. And maybe that balance doesn't exist.
So my question is: does anybody do that? Is there a name for that?