Al agregar sal y contraseñas de hashing, ¿alguna ventaja de incluir la longitud de la contraseña?

El punto de una sal es que es único, por lo que un atacante que quiera romper múltiples hashes debe hacer todo el trabajo de nuevo para cada hash. Si incluye una característica que se deriva de la contraseña, no ayuda a la sal. Tampoco duele, pero no fortalece la sal de ninguna manera.

En efecto, al tomar hash(password+length+salt) en lugar de hash(password+salt) , estás usando una función hash diferente hash2(password+salt) donde hash2(x) = hash(x+length(x)) . Estás inventando efectivamente tu propia primitiva criptográfica. Eso en sí mismo es una mala señal. No creo que el resultado sea realmente inseguro de ninguna manera, pero todavía lo vetaría como un riesgo innecesario.

hash2 es ligeramente más lento que hash . Más lento es bueno para un hash de contraseña, pero hay mejores maneras de hacer que el hash sea lento: las funciones de hashing de contraseña tienen un parámetro ajustable para configurar la lentitud del hash. Usar un hash variante no vale la pena por la complejidad agregada.

El método normal para generar la sal es hacerlo aleatorio. Si va a agregarle algo, el único punto sería mitigar un error en el generador de números aleatorios. Si va a hacer eso, tome algo que no dependa de la contraseña, como la identificación del usuario o la hora.

Tenga cuidado al tomar el hash de una concatenación de dos cadenas: es ambiguo: hash("bob" + "swordfish") = hash("bobsword" + "fish") . Siempre que tome la concatenación de algunas cadenas y las pise o las utilice de otra manera en un protocolo criptográfico, asegúrese de que las cadenas se puedan descomponer de forma inequívoca. Si hay un valor de byte que no puede aparecer en ninguna de las cadenas (los bytes nulos suelen ser adecuados), utilícelo como separador. Si hay un límite en la longitud de la primera cadena (a menudo es adecuado 2 ⁶⁴ ), prepárese la longitud (en sí misma en una codificación de tamaño fijo, por ejemplo, 8 bytes para un 2 ⁶⁴ límite de longitud). Si está construyendo estructuras de datos complejas, use el módulo ASN.1 de su biblioteca.

En cualquier caso, cuando necesita almacenar un hash de contraseña, no debe pensar en la criptografía. Utilice la biblioteca bcrypt o PBKDF2 o scrypt de su entorno de programación.

Para todo lo que quería saber sobre contraseñas de hash, todo lo que no quería saber sobre contraseñas de hash y todo lo que ni siquiera sabía que pudiera saber sobre contraseñas de hash, lea ¿Cómo hacer hash de forma segura las contraseñas?

Depende. Si está utilizando un KDF adecuado, como PBKDF2 o bcrypt, entonces no hay ningún beneficio en absoluto.

Si está utilizando una función hash criptográfica simple que sufre de ataques de extensión de longitud (por ejemplo, MD5 o SHA-1 ) entonces puede ayudar a reducir su susceptibilidad a tales problemas. Sin embargo, en ese momento, tienes problemas más grandes.

No veo ninguna ventaja en absoluto (aunque tampoco hay desventajas). El propósito de la salazón es frustrar las tablas de hash / arco iris precomputadas, lo que obliga al atacante a forzar sus hashes. Si agrega una propiedad fácilmente computable de la contraseña en el proceso de hash, el atacante solo tendrá que hacer lo mismo (para cada intento de adivinación), y la diferencia en el tiempo será despreciable.

La salida de un buen hash no debe estar relacionada con la entrada, por lo que no se debe lograr una aleatoriedad adicional al tomar en cuenta la longitud. El objetivo de la sal no es hacer que el hash sea más único, sino prevenir la posibilidad de precalcular las tablas. Dado que se conoce la longitud de una contraseña que se adivina, no agrega ninguna protección contra las tablas generadas previamente.

Por ejemplo, si eliminamos el salt de él, la prueba de contraseña solo tendría que saber qué es password8. Nunca habría una contraseña3 o una contraseña7. La ligera oscuridad del algoritmo no tiene ningún aumento medible en la seguridad.