5 ms·
I'm not defending this strategy, but you could still do this with hashing. Just create a different hash for different combinations when creating the hash.
by dickeytk 8y ago
I'm not defending this strategy, but you could still do this with hashing. Just create a different hash for different combinations when creating the hash.
- gregmac 8y agoYour 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.
- inetknght 8y agoNot only that, but enumerating all possible combinations of 4 or 5 characters from a 20 character password would be untenable.
- munk-a 8y agoAlso, 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.
- myhf 8y ago20 choose 5 = 15504. You could enumerate them all in less than a second and store all the hashes in less than a megabyte.
- dickeytk 8y agoAgain, not defending this I'm just being technical. You wouldn't need every permutation. 100 is probably plenty.
- munchbunny 8y agoProblem 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.