Assume a password is hashed with a secure salt, e.g. hash = sha256(password+salt). If the hash and the salt are made public, an attacker can perform an attack by running possible password candidates through the hash function to try and find the correct password eventually. The assumption here is that if the hash function yields the correct output then it was the correct input, and this is often true for collision resistant hash functions.

But one could intentionally truncate the output to create more collisions, e.g. hash = sha256(password+salt) modulo 1000.

What information could this truncated hash reveal about the password? What kind of attacks could possible if it was made public?

Edit:
I did not mean that the server should use only a truncated hash for authentication. I was thinking purely about the security implications of a truncated hash being made public. My idea was that this could possibly be used as part of a challenge-response interchange to check that the client is "likely" in possession of the correct password before proceeding with the rest of the interchange.

• You'll need to be more specific on how you see such a challenge-response mechanism working. I would rather do something different if I wanted to go along those lines, I would have the server store the hash of the first N and last M characters of the password and then you can have for example two "pre authentication" phases before the "full" password authentication. Note that N and M can be modified from one login to the next. BTW this also allows the client to pre authenticate the server (the client may delibarately lie randomly in the pre authentication stage and see whether the server ...
– Amit
Feb 6 at 19:45
• is happy to be "fooled"...)
– Amit
Feb 6 at 19:47
• The idea was that the client has two signatures generated by doing hmac on the password with two different keys. The client only sends part of the first one and then later the whole second one. Feb 6 at 20:01
• so one thing is clear, you didn't really explain the important details of your question :) do that and perhaps someone else will give you a better answer
– Amit
Feb 6 at 20:10
• I'm sorry for not explaining the question clearly. Feb 6 at 20:18

If what you're trying to compare are the two scenarios:

1. Server uses regular hash with salt, and attacker obtains both
2. Server uses truncated hash with salt, and attacker obtains both

Then obviously the attacker has an easier job in Scenario #2 because for a truncated hash computed via the same algorithm, he will find a collision faster (If those are different algorithms, the output hash being shorter doesn't necessarily imply that the hash is faster to compute).

Remember that the attacker doesn't have to guess the correct password, he only needs to calculate a password that matches whatever hash value the server stores. I'm making the reasonable assumption that the server stores only the hash, not the password itself, otherwise storing a hash is rather pointless (at least as far as security goes).

Now, if an attacker only has access to the truncated hash but not the salt, then obviously it makes a big difference exactly how you perform the truncation. The "modulo 1000" example you gave for example will yield any hash trivially breakable, because the hash value will be in the range $$0-999$$ which is an exceedingly small search space. Of course, here he doesn't know the salt value, so he has no way to precompute possible hashes on his own, yet this is still an extremely insecure way to compute a hash, because of the ease of performing an exhaustive search attack directly on the server. However, if it is a reasonable hash function truncated to a reasonable size, for example: truncate(sha512(password||salt), 256) then probably the attacker isn't much better off without access to the salt value.

In general, I don't see any security benefit in truncating a hash for this specific use case. There are interesting security-related use cases where truncating a hash can be useful: if you want to create some kind of data equivocation, e.g. make it difficult for an adversary to ascertain that a hash value belongs to a certain object and not another.

But again, since when talking about password hashes, the correctness of the password sent to the server in general doesn't matter, but only it (in combination with the salt, if used) having a matching hash value, I don't see how that can have any security benefit.