For starters, hash functions are supposed to be basically random, so the length of the input string doesn't matter. The probability that two random 3-character strings hash to the same thing is the same as the probability that two random 100-character strings hash the same.
For modern hash functions (
MD5) their structure is mathematically complex enough that we can't say very much about it algebraically. Also, the space of possible input strings, even of length 32, is so huge that we can't experimentally check all of them. So, we don't actually know how many collisions there are within the first 2128 strings (strings whose binary representation are
11... 2128). In theory there should be some, but as far as I know, we haven't uncovered any yet for
SHA2. So your intuition that capping the length of the input strings to less than 2128 bits will eliminate the risk of collisions isn't quite right.
In any case, let's assume there are pairs of passwords within the first 2128 strings that have the same hash, the probability that you will hit one in your database is roughly
<number of entries in db> / 2128.
The reason that
the "impact of hash collisions is non existent"?
is that 1/ 2128 is such an unimaginably small number that even if you wrote a program to generate random passwords until the sun ran out of energy, you still wouldn't expect to see a single collision by random chance. (If someone's actively trying to do a collision attack, then that's a different story).
Consider also how the risk of a collision (~ 1/2128) compares to the risk of a standard dictionary attack. According to the 2013 Adobe password leak, 1 out of 68 accounts on the internet use the password
123456. 1/68 is a MUCH bigger number than 1/2128, so the fact that a single guess of
123456 has a 1/68 chance of being right is a MUCH more important thing to worry about than theoretically-possible-collisions. Solution: allow (or enforce) long non-dictionary passwords, use a unique salt for each password hash, and don't worry about collisions.