¿Truncar el hash criptográfico hace que sea imposible de descifrar?

Definitivamente no, en todo caso, esta práctica socava la función hash, lo que facilita la búsqueda de una colisión durante una búsqueda exhaustiva. En el sentido de una contraseña, cualquier texto simple que produzca el mismo valor de hash es una contraseña válida .

Dicho esto, ChromeOS utiliza un hash truncado de su contraseña de Google en su función s2k para esquema de cifrado de disco de Google . Sospecho que esto fue para hacer que sea más difícil romper tu contraseña de Google a favor de que sea más fácil encontrar una contraseña que descifre tu disco ... lo cual es un poco inquietante.

¿Qué es "cracking"? Es encontrar un valor de contraseña que su sistema acepte, es decir, uno que coincida con lo que su sistema almacene como valor hash en su base de datos. Si el atacante encuentra otra contraseña otra , distinta de la contraseña "verdadera", pero que coincide con el hash, el atacante gana.

Para un valor hash dado, ya hay muchas contraseñas coincidentes (porque hay "solo" 2²⁵⁶ posibles valores hash, y muchas más contraseñas posibles si acepta) contraseñas "largas", digamos 50 caracteres). Al truncar el valor de hash, solo aumentará el número de contraseñas que, cuando se hash y truncado, coincidirán con lo que almacenó; es decir, solo hace las cosas más fáciles para el atacante.

Ahora las cosas no son necesariamente tan terribles. SHA-256 ofrece 256 bits de salida porque intenta ofrecer resistencia a las colisiones de al menos 2¹²⁸ , y necesita 256 bits de salida para conseguir tanta resistencia. Sin embargo, las colisiones no son un problema para el almacenamiento de contraseña hash; lo que se necesita es resistencia a las imágenes previas . Este requiere solo n bits de salida para la resistencia de 2ⁿ . En otras palabras, si mantiene solo 128 bits (es decir, 32 caracteres hexadecimales), entonces todavía está "bien", o al menos no es sustancialmente peor que lo que sería con los 64 caracteres completos.

Precaución: un hash simple no es bueno . Aunque no lo debilites más (al menos no de una manera prácticamente significativa) al truncarlo, ya tienes dos problemas:

• No tiene sal, lo que le permite al atacante aplicar un paralelismo en el tiempo o en el espacio. Es decir, atacar muchas contraseñas simultáneamente y / o usar tablas precomputadas (tablas arcoiris).
• Un solo hash es demasiado rápido, lo que facilita al atacante probar millones, posiblemente miles de millones de contraseñas potenciales por segundo.

Por lo tanto, necesita un mejor proceso de hashing de contraseñas, uno que se pueda configurar para la lentitud y que use un salt (un nuevo salt aleatorio para cada contraseña). La recomendación habitual es bcrypt . Entonces, y solo entonces, podría visualizar un truncamiento (pero debe mantener al menos 128 bits, y no se recomiendan las alteraciones caseras de los algoritmos criptográficos en general).

Editar: para aclarar las cosas: un atacante con capacidad de computación ilimitada puede tratar de enumerar todas las contraseñas posibles y mantener las que coinciden con los valores hash almacenados. Estos son candidatos para ser "verdaderos" contraseña. Al truncar el hash, aumenta el número de candidatos, por lo que, bajo cierta luz, el atacante está más lejos de adivinar la "contraseña verdadera". Sin embargo, el atacante no está detrás de la "contraseña verdadera", sino después de una contraseña que otorga acceso. Cualquier contraseña que coincida con el valor almacenado otorgará acceso, ya que el servidor otorga acceso en base a "la contraseña ingresada coincide con el valor hash almacenado". Así que cualquier candidato es lo suficientemente bueno para el atacante.

Al truncar el hash, solo puedes hacer que sea más fácil de crackear. Digamos que el hash es 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae y usted almacena 2c26b46b68ffc68ff99b453c1d304134. El atacante ahora tiene un trabajo más fácil: puede encontrar cualquier contraseña cuyo hash comience con 2c26b46b68ffc68ff99b453c1d304134. Si está utilizando una tabla de búsqueda, es posible que tenga que reorganizarlo un poco para hacer frente a su formato no estándar, pero esa es una cantidad de trabajo que es aproximadamente proporcional al tamaño de la tabla.

Creo que por "función hash" quieres decir algo como PBKDF2 o bcrypt , ya que usted menciona "sales, iteraciones, etc.". Las funciones como la familia SHA no son una forma adecuada de almacenar hashes (consulte ¿Por qué? ¿Usar la sal más segura? ). La única forma de invertir una función hash adecuada es mediante la fuerza bruta directa: adivinar la contraseña, calcular el hash de su conjetura, comparar con el hash de referencia. Si el hash de referencia es un truncamiento del hash real, el atacante gana una cantidad insignificante de tiempo haciendo la comparación. Para un ataque masivo de fuerza bruta, o si trunca el hash demasiado, el atacante puede hacer su trabajo más fácil al encontrar una colisión en el hash truncado que no habría sido uno en el hash original. Sin embargo, esto no es una preocupación importante en la práctica, porque el punto débil será la contraseña de todos modos.

Con una buena función hash, cada bit es lo más independiente posible de los otros bits y no revela ninguna información sobre el hash. Por lo tanto, una función hash truncada sigue siendo una función hash, con una fuerza reducida. Si su función hash es una de las funciones SHA (o por implicación un hash iterado derivado de un SHA), Las recomendaciones de NIST para usar hashes (NIST SP-800-107, §5.1) analizan la potencia que puede esperar de un truncamiento de N bits.

Creo que esta pregunta tiene buenas respuestas, así que solo quiero tratar de pensar con un enfoque diferente:

Dado que el hash, salt, etc., se realiza de la manera más conocida, obtienes 64 caracteres (32 bytes) como salida. Si tira 30 bytes de distancia y solo mantiene 2 bytes, ¿será más fácil encontrar contraseñas que generarán esa salida de 2 bytes? Probablemente sí, habrá muchas contraseñas que generarán esos 2 bytes.

¿Y si tiras 28 bytes, manteniendo 4 bytes? Probablemente cabrán menos contraseñas, pero aún muchas más contraseñas que el hash original de 32 bytes.

Y así sucesivamente ...

Supongamos que tenemos el hash 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae que se generó desde una entrada válida. Permite simplificar las cosas y truncar el hash a 1 carácter y ver los resultados de nuestra acción.

Nuestro nuevo hash es "2".

La pregunta es, ¿qué tan difícil sería revertir la contraseña del hash truncado?

¡Muchos algoritmos de craqueo encontrarán muchas contraseñas diferentes que coinciden con el hash! Sin embargo, esto nunca puede encontrar la entrada original. Además, la entrada original nunca se pudo probar que creó este hash.

Supongamos ahora un hash truncado diferente de 2 caracteres.

El nuevo hash es "2c".

Muchas menos contraseñas podrán coincidir con el nuevo hash truncado pero aún habrá muchas.

A partir de este patrón, puedes ver que cuanto más se trunca un hash, ¡más contraseñas podrían ser!

Obviamente , esto también será malo para la autenticación.

Debería ir sin decirlo, pero esto no protege a su sitio; protege al usuario que reutiliza su contraseña en otros sitios. Felicitaciones por pensar en sus usuarios (y hacerlo de manera realista).

De todos modos, esto es exactamente equivalente a usar una función hash más corta.

El problema es que sugiere un número fijo de bits. Pero la longitud de la contraseña, y la fuerza en general, es bastante variable.

Se ha sugerido que las fortalezas de las contraseñas comunes son equivalentes a una clave aleatoria de 18-30 bits de longitud. Entonces, puedes usar esa teoría y truncar el hash a 15 bits, pero luego las contraseñas de 18 bits solo requerirán 2 ³ = 8 conjeturas, una vez que hayas eliminado el hash. En segundo lugar, si le preocupa que lo llamen irresponsable, hacer eso va a marcar la casilla "implementar su propia criptografía personalizada es una muy mala idea", y "sonará increíblemente tonto si aparece en los cuadros de noticias". ("Seguridad de 15 bits, ¿alguien"?)

Esto no es una buena idea. En su lugar, debe utilizar técnicas estándar de fortalecimiento de claves como PBKDF2 o scrypt.

Truncar el hash puede reducir la seguridad de ese hash al aumentar la probabilidad de que un atacante pueda determinar una contraseña que genere ese hash. Sin embargo, la pregunta es si hay algún cambio en la dificultad para determinar la contraseña utilizada para generar el hash. Esto es importante si se usa la misma contraseña para generar múltiples hashes (usando diferentes sales).

Actualizar

Pensando más en esto la última noche, si el atacante tiene acceso a la sal, no hay ningún impacto en la dificultad para recuperar la contraseña maestra. La lógica es así: como un cambio menor en la entrada de hash tendrá un gran impacto en la salida de hash, lo mismo será cierto para el hash parcial. Por lo tanto, si se conoce parte de la entrada, la única forma de crear la salida es si se determina la contraseña maestra.

Esto no hace absolutamente ninguna diferencia, excepto que el software de craqueo original tendría que ser modificado para realmente manejarlo correctamente.