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?

  • 1
    it could protect privacy via reverse-engineering, but at a great cost to security compared to proper derivation.
    – dandavis
    Commented Oct 31, 2017 at 23:49
  • Maybe you misunderstand what I'm suggesting. I'm saying use a proper derivation, with whatever work factor / memory hardness you choose. Best practices. The point is, eventually you store a hash, which, while not reversible, if it is long enough it is /essentially/ reversible by the fact that collisions are rare. The security lost would be that an attacker could get a password that works, given a full DB loss. But because of high collision rate they likely wouldn't have the user's original password. This is of course assuming if your DB was compromised, you reset passwords etc.
    – Vectorjohn
    Commented Oct 31, 2017 at 23:55
  • 2
    @Vectorjohn If someone finds a collision with such a shortened hash, the you've by definition reduced the security of your authentication scheme to the point where an attacker was able to authenticate, in a practical amount of time, with an invalid password. This is cutting off your nose to spite your face. Commented Nov 1, 2017 at 4:18
  • And it doesn't even protect a person's "real" password: an attacker doesn't have to stop guessing just because they found a single match. Although the overwhelming likelihood is that the first match will be the real password, because for "bad" passwords that are guessable, the password will be lower-entropy than any of the alternatives it collides with. For "good" passwords that aren't guessable, this approach only serves to weaken its effective strength. Commented Nov 1, 2017 at 4:20
  • @Stephen I think it does protect the real password. Essentially an attacker would get a bunch of false positive hits and won't know which one is the "real" one. Even people with medium-good passwords would cause a bunch of false positives for dictionary words and permutations of those. They might have hundreds or thousands of false positives. Of course, that would mean a higher chance of letting someone guess a password through the UI, which is the real drawback of this thought experiment.
    – Vectorjohn
    Commented Nov 2, 2017 at 17:28

2 Answers 2


I'm not aware of anyone doing this, currently or historically.

I see what you're getting at -- resistance to password discovery -- but increasing the likelihood of collision as a way to mitigate offline attacks is of dubious value. Any potential benefit of doing so is outweighed by the drawbacks:

  • If a specific user is targeted, unless there were many collisions, it would be easy for the attacker to try all of the collisions against another site or leak until they got a match ... which would confirm the real password and cancel out any benefit from the collisions.

  • As the number of collisions goes up, the risk of an online false positive for authenticating (with the original site) goes up.

  • This also means that the trustworthiness / nonrepudiation of the authentication is reduced. Someone else other than the user could (theoretically) log in as the user, without the user's actual password. Usually, the risk of this is effectively zero in the real world when using a sufficiently collision-resistant hash function. But by deliberately seeking out collisions, it could be argued that you are not following the best practices that ensure nonrepudiation in practice.

Instead, you can get a lot of the benefit you're looking for simply by storing extra private material (an encryption key or a pepper) in an HSM. If implemented properly, this would get you some real resistance to offline attack - without the drawbacks of frequent collisions.

  • 1
    This is roughly the conclusion I was coming to. Yeah, the idea was as a way to prevent giving up information about users' original passwords, in the case of a whole database being accessed. Sure, attackers would gain access to my site, but all they'd have is a bunch of false matches for other sites. But, as you say, the benefit isn't strong enough. False positives would probably have to be really high (like 1 in 100) to really hide the original password. And that besides the vulnerability to something like a bot net attack that just tries logging in to the live site.
    – Vectorjohn
    Commented Nov 1, 2017 at 17:01

The only benefit from such a scheme is that if your own database is compromised, you are unlikely to compromise your user's account on some other site, not your own, because that other site is likely to use a different hash algorithm (and a different salt) so that the original password is actually required, not some hash collision.

On the other hand, if they get a collision with the password hash, then for your site it doesn't matter if it's not the original password, they can use that password to log into your site. So someone with a long random original password could be compromised by a collision with a short common password. This is bad.

Basically you're giving a dubious benefit to other sites at the expense of your own security. It seems very misguided so I doubt very much anyone is doing it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .