¿Anteponer un salt a la contraseña en lugar de insertarlo en el medio disminuye la seguridad?

Lo que este artículo podría haber significado es que poner la sal en algún lugar en el medio de la contraseña supuestamente aumenta la posibilidad de ser descifrado por un ataque de diccionario o por fuerza bruta, porque las reglas para componer realmente el mismo hash no se pudieron implementar en su contraseña cracker de elección. En realidad, esto probablemente sea un completo disparate.

¿Cómo funciona esto?

Si toma un programa como John the Ripper , aliméntelo con su archivo de contraseña como tal (no la sintaxis exacta ):

username:password:salt

Luego pasas el formato como un parámetro con el que crees que se genera el hash. Esto puede ser:

md5(pass + salt)
md5(salt + pass)
md5(md5(pass) + md5(salt))
md5(pass + md5(salt))
md5(md5(...(salt + pass + salt)...))
...
and whatnot.

John the Ripper viene con un conjunto prefabricado de aproximadamente 16 subformatos que puedes elegir.

Probablemente, poner la sal en algún lugar de la contraseña se vería así:

md5(password.substring(0,4) + salt + password.substring(4,end))

Entonces, usar una técnica como esta requiere que escribas un pequeño plugin para John al principio, antes de que puedas comenzar a descifrar (lo que no debería ser un problema).

Además, usted, como atacante, puede tener una lista de hashes + sales de origen desconocido y no tiene conocimiento de la forma en que se compone un hash. Esto es raramente el caso. Si usted, como atacante, logra extraer hashes y sales de una base de datos, probablemente encuentre la forma de extraer el algoritmo de hashing de contraseñas del sitio web o simplemente cree una nueva cuenta con una contraseña conocida, extraiga el hash y la sal para y fuerza bruta el algoritmo que se utilizó para componer el hash final (que puede ser más o menos desafiante).

En general, es casi completamente arbitrario dónde se pone la sal y si se repite o no el algoritmo hash diez mil veces o no. Esto NO proporciona una cantidad significativa de seguridad.

Si desea seguridad, puede hacerlo mejor utilizando un mejor algoritmo de hash o bcrypt o algo más que sea computacionalmente costoso.

Depende de la función hash.

Con un oráculo aleatorio (que es la "función hash ideal"), no hay ninguna diferencia en la forma en que se combinan el salt y la contraseña, siempre y cuando ambos entren.

Con las funciones hash en vivo reales puede haber diferencias en la posición de la entrada (como, hay ataques de extensión).

Pero entonces, usualmente desea usar algún esquema especial de hashing de contraseñas como PBKDF-2, bcrypt o scrypt, y estos ya están hechos con tres entradas, una es la contraseña y la otra la sal (la tercera es el trabajo factor). Simplemente úselos como estaban destinados a ser utilizados.

Es mejor tener aleatoriedad al principio de la cadena de entrada, que al final.

Si el valor de sal es un valor constante para todas las contraseñas, es más fácil restringir varias contraseñas si se aplica como:

hash(salt . password)

en lugar de

hash(password . salt)

La razón es simplemente porque algunos algoritmos de hashing (y creo que tanto md5 como sha-1 se ajustan a esta descripción) son iterativos, y si la cadena que está haciendo comience con un valor constante conocido es posible sembrar cualquier intento de craqueo con El resultado del hashing the salt, eliminando así los beneficios de compartir sus contraseñas.

Si los valores de sal son específicos de la contraseña (como deberían ser), no se aplica lo anterior, y es probable que la sal sea más aleatoria que la propia contraseña. Por esta razón, es mejor anteponer la sal, aunque la diferencia / beneficio es insignificante.

La sugerencia de insertar la sal en el medio de la cadena de entrada es probablemente otra permutación de no iniciar la cadena de entrada con un valor constante, siempre que evite eso, la contraseña es tan segura como el algoritmo de hash y la aplicación. usándolo.

Sería potencialmente un poco más seguro, pero despreciable. No me preocuparía por eso y simplemente lo prepararía para simplificar. Casi todas las empresas en las que he trabajado ni siquiera utilizan sal, por lo que ya está más seguro que la mayoría.

Es muy poco probable que se encuentren las posibilidades de que un pirata informático con un hash robado de su base de datos o un ataque de hombre en el medio al que se le haya aplicado sal, a diferencia de los hashes sin sal, que pueden romperse fácilmente con tablas de arcoiris.

En otras aplicaciones, cuando se usa un HMAC, tanto la adición de la clave secreta como la anterior son vulnerables a diferentes tipos de ataques. Sin embargo, ninguno de estos se aplica a la salada de un hash de contraseña, por lo que cualquiera de los dos debe ser satisfactorio.

Es (aunque solo un poco) más seguro basado en el hecho de que si alguien asumiera y probara contra la salazón definitivamente asumiría una sal prependida debido a la frecuencia con la que ocurre (y dependiendo de cuánto querían) acceso pueden probar una sal añadida)

A pesar de que comienza a ser menos que un intercambio de tiempo / memoria, definitivamente puede generar tablas de arco iris con contraseñas con sal y aún son útiles. Obviamente, tardan mucho más en generar y ocupan mucho más espacio, pero incluso los he usado para algunos proyectos.

Si estuviera implementando mi propio algoritmo de hashing de contraseñas, incluido el uso de sal, elegiría en algún lugar que no fuera ni el frente ni el final. Obviamente, tampoco usaría una sal codificada debido a la poca cantidad de problemas que se derivarían de eso.

No se me ocurre ninguna razón por la que no quiera aumentar la seguridad (independientemente de lo insignificante que pueda ser un aumento) a costa de poco o ningún aumento de gastos generales.