¿Alguien utiliza longitudes de hash deliberadamente cortas para que las contraseñas aumenten la posibilidad de colisiones falsas positivas en caso de un ataque de fuerza bruta en la base de datos?
Al intentar decidir sobre una longitud de hash, mi suposición predeterminada era "el almacenamiento es barato, hazlo enorme". Sin embargo, en realidad, dado que la debilidad de una contraseña a menudo es que es corta o fácil de adivinar, ninguna cantidad de hash ayudaría a los usuarios en el caso de una violación de la base de datos.
Eso me hizo preguntarme: ¿Alguien usa deliberadamente hashes cortos para ocultar mejor la contraseña original? Si solo hay, digamos, un millón de hashes posibles, obtendrás colisiones por todos lados. De todos modos, cuando la aplicación se ejecuta normalmente, no permitirá que un atacante intente más de un puñado de veces, lo que reduce la posibilidad de que afortunado se acerque a cero. Si la base de datos está comprometida, un atacante será forzado y hallazgo brutal. Todas las contraseñas fáciles sin importar cuál sea su esquema de hash. Sin embargo, si la probabilidad de colisiones es alta, es probable que una fuerza bruta encuentre una contraseña que el usuario no pueda reutilizar en ningún otro lugar.
Supongo que deberías elegir una longitud que proteja lo suficiente la entrada aleatoria de colisiones en un puñado de intentos, mientras que también tienes una probabilidad relativamente alta de tener múltiples palabras de diccionario que coincidan. Y tal vez ese equilibrio no existe.
Entonces mi pregunta es: ¿Alguien hace eso? ¿Hay un nombre para eso?