Your hash is going to be of a tiny set though, the same as a 4- or 5-character password. That's possible to brute force in seconds, even with the slowest algorithm.

Not only that, but enumerating all possible combinations of 4 or 5 characters from a 20 character password would be untenable.

Also, if all those combinations were stored would the software use separate salts for each one? Well designed software would but I suspect anyone intelligent enough to consider that would also raise a loud voice at the meeting where this feature was being discussed. They probably use a common salt and if it's known how long (at most) each partial password is (say 5 characters) it's super trivial to generate a rainbow table to break it.

Honestly, even if the salting was done independently per chunk, the fact that you know each chunk is under 5 characters long massively reduces the time to generate a rainbow table to verify the password, even more so if the entry field only allows 36 character entry.

Again, not defending this I'm just being technical. You wouldn't need every permutation. 100 is probably plenty.

20 choose 5 = 15504. You could enumerate them all in less than a second and store all the hashes in less than a megabyte.

Problem with this is that you just transform the problem into generating collisions on multiple hashes of multiple short strings, rather than one collision on a long string. Even if you salt the hash, you have a substantially smaller search space on each of the sub-sequence hashes.