¿Cuál es la longitud óptima para la contraseña de usuario salt? [cerrado]

128

Obviamente, cualquier sal ayudará a la hora de salar y descifrar la contraseña de un usuario. ¿Existen algunas prácticas recomendadas para la duración de la sal? Estaré almacenando la sal en mi tabla de usuario, por lo que me gustaría la mejor compensación entre el tamaño de almacenamiento y la seguridad. ¿Son suficientes 10 caracteres aleatorios? ¿O necesito algo más?

encryption hash salt

— David
fuente

10

No tengo una recomendación sobre la longitud de la sal, pero las respuestas que se muestran aquí tienen mucha mala información. Su sal definitivamente debe: - ser aleatoria - ser por secreto (no un solo valor almacenado en la imagen de su programa o archivo de configuración). La sal no es un secreto criptográfico, por lo que almacenarla en su tabla no es un problema. El único propósito de una sal es asegurar que cuando diferentes instancias del mismo artículo sean codificadas (o encriptadas) obtenga un resultado diferente.

— Michael Burr

2

Para aquellos que no saben qué es la sal: <a href=" es.wikipedia.org/wiki/Salt_(cryptography)"> Sal (criptografía) </a> en Wikipedia

— David Koelle

1

¿O si hay una relación óptima entre la longitud de sal y la longitud de salida de hash? La sal de 8 bytes puede ser suficiente para HMAC-SHA-256, pero puede no serlo para HMAC-SHA-512.

— Rey Crend

1

La sal criptográficamente aleatoria del mismo tamaño que la salida de la función de hash significa que un ataque de "probar todas las sales posibles" (más un diccionario de contraseñas) requiere tanto esfuerzo como un ataque de "probar todos los resultados de hash posibles", que es una fuerza bruta estándar . Una sal más corta significa que puede tener un diccionario de sal más un diccionario de contraseña como ataque de fuerza bruta.

— Richard Gadsden

-1 Es cierto que no (ni siquiera intenta) responder la pregunta.

— user359996

70

La mayoría de estas respuestas están un poco equivocadas y demuestran una confusión entre sales y claves criptográficas. El propósito de incluir sales es modificar la función utilizada para codificar la contraseña de cada usuario de modo que cada hash de contraseña almacenado tenga que ser atacado individualmente. El único requisito de seguridad es que son únicos por usuario, no hay ningún beneficio en que sean impredecibles o difíciles de adivinar.

Las sales solo necesitan ser lo suficientemente largas para que la sal de cada usuario sea única. Es muy poco probable que las sales aleatorias de 64 bits se repitan incluso con mil millones de usuarios registrados, por lo que esto debería estar bien. Una sal repetida individualmente es una preocupación de seguridad relativamente menor, permite que un atacante busque dos cuentas a la vez, pero en conjunto no acelerará mucho la búsqueda en toda la base de datos. Incluso las sales de 32 bits son aceptables para la mayoría de los propósitos, en el peor de los casos acelerará la búsqueda de un atacante en aproximadamente un 58%. El costo de aumentar las sales más allá de 64 bits no es alto, pero no hay ninguna razón de seguridad para hacerlo.

También es beneficioso usar una sal de todo el sitio encima de la sal por usuario, esto evitará posibles colisiones con hashes de contraseñas almacenados en otros sitios y evitará el uso de tablas de arco iris de uso general, aunque incluso 32 bits de la sal es suficiente para hacer que las mesas arcoiris sean un ataque poco práctico

Incluso más simple, y los desarrolladores siempre pasan por alto esto: si tiene ID de usuario únicos o nombres de inicio de sesión, estos sirven perfectamente como una sal. Si hace esto, debe agregar una sal en todo el sitio para asegurarse de no superponerse con los usuarios de otro sistema que tenían la misma idea brillante.

— SecurityJoe
fuente

16

Hay un beneficio en que las sales sean impredecibles. Una sal predecible podría predecirse y usarse en un ataque de tabla hash. Por ejemplo, si su sal es solo el ID de usuario, entonces una tabla de hash alfa simple que sea lo suficientemente larga incluirá no solo todas las contraseñas, sino todas las combinaciones de nombre de usuario + contraseña.

— Richard Gadsden

66

Tenga en cuenta en relación con su último párrafo, si utiliza una sal en todo el sitio, eso debería ser exactamente eso: en todo el sitio. No en toda la aplicación, es decir, cada nueva instancia que instale de su aplicación debería generar una nueva sal en todo el sitio. Por ejemplo, si Windows usara la misma sal en cada base de datos de autenticación de Windows, entonces valdría la pena crear una tabla de arco iris para esa sal, pero si cada instalación de Windows generara una nueva sal, entonces no lo haría.

— Richard Gadsden

55

El problema no es que la sal sea difícil de adivinar. El atacante no necesita adivinar la sal: cualquiera que tenga acceso al hash ya tiene la sal. El problema es que si sus sales son muy comunes (como los nombres de usuario), podrían ser las mismas que las de otros sitios, y en ese momento el atacante necesita un conjunto mucho más pequeño de tablas de arco iris para hacer posibles los ataques. Es por eso que se menciona la idea de sal por sitio, para evitar este tipo de colisión con otros sitios.

— Nate CK

3

Nota rápida: si usa nombres de usuario como sal, esto puede ser un problema si cambian los nombres de usuario. Prácticamente, (a pesar de lo que se dice en los documentos de diseño del cliente), he descubierto que los usuarios a menudo desean cambiar los nombres de usuario.

— SilentSteel

55

@ NateC-K, la idea de sal por sitio de la que está hablando se llama pimienta.

— Pacerier

35

Los estándares actualmente aceptados para las contraseñas de hash crean un nuevo salt de 16 caracteres para cada contraseña y almacenan el salt con el hash de contraseña.

Por supuesto, se debe tener cuidado criptográfico adecuado para crear sal realmente aleatoria.

— David Schmitt
fuente

66

El personaje está un poco mal definido. Deberías decir byte .

— CodesInChaos

10

@CodesInChaos Creo que te refieres a octeto ;-)

— usuario2864740

1

¡Hola! Parece que el artículo de wikipedia ha cambiado, ¿tal vez debería consultar en.wikipedia.org/wiki/PBKDF2 o algo así?

— Boris Treukhov

55

O incluso mejor owasp.org/index.php/Password_Storage_Cheat_Sheet

— Boris Treukhov

24

Editar: Mi respuesta a continuación responde a la pregunta que se le hizo, pero la respuesta "real" es: solo use bcrypt , scrypt o Argon2 . Si hace preguntas como esta, es casi seguro que está utilizando herramientas a un nivel demasiado bajo.

Honestamente, no hay ninguna razón defendible para que la sal no tenga la misma longitud exacta que la contraseña cifrada. Si está utilizando SHA-256, entonces tiene un hash de 256 bits. No hay razón para no usar una sal de 256 bits.

Más de 256 bits no le proporcionarán ninguna mejora en seguridad, matemáticamente. Pero ir con una sal más corta siempre puede terminar en una situación en la que una mesa arcoíris alcanza su longitud de sal, especialmente con sales más cortas.

— Stephen Touset
fuente

10

Eso no es que una gran cosa; el usuario apenas notará la diferencia entre un hash de milisegundos y un hash de medio segundo, además, el hash de contraseña en realidad debería tomar más tiempo para ralentizar los ataques de fuerza bruta, aunque los tres ataques típicos bloqueados durante 15 minutos son mejores. ¿Estás "desperdiciando" ciclos de CPU para hacer esto? Sí lo que sea. De todos modos, la CPU pasa más tiempo inactiva que no en la mayoría de los sitios web, entonces, ¿qué importa? Si tiene problemas de rendimiento, escale.

— Randolpho

14

Las sales se defienden contra las mesas arcoiris. Una sal de 512 bits con un hash de 256 bits solo dará como resultado 256 bits de entropía en la contraseña final.

— Stephen Touset

8

El hash lento es una característica, no un error.

— outis

77

Si tiene un hash de 3 bits, su sal de 9999 bits seguirá reduciéndose a 3 posibles bits de entropía. Una tabla de arcoiris solo tendría que encontrar tres sales para cada contraseña que den como resultado una salida diferente, que es un factor multiplicativo constante y, por lo tanto, se descarta del big-O.

— Stephen Touset

2

.................................................. .................................... sistema particular. El propósito de las sales es detener los ataques de precomputación para que no se puedan buscar los hashes e inmediatamente se inviertan en texto sin formato . Con una sal de 9999 bits, su contraseña sigue siendo un secreto , mientras que con una sal de 3 bits, su contraseña ahora es conocida en todo el mundo (y pueden usarla para iniciar sesión en sus otras cuentas, ya que muchas personas a menudo reutilizan las contraseñas). Me parece divertido que 5 personas aquí realmente hayan votado tu comentario debido a la palabra "entropía".

— Pacerier

7

Wikipedia :

Los métodos SHA2-crypt y bcrypt, utilizados en Linux, BSD Unixes y Solaris, tienen sales de 128 bits. Estos valores de sal más grandes hacen que los ataques de precomputación para casi cualquier longitud de contraseña no sean factibles contra estos sistemas en el futuro previsible.

La sal de 128 bits (16 bytes) será suficiente. Puede representarlo como una secuencia de 128 / 4 = 32dígitos hexadecimales.

— Andrii Nemchenko
fuente

Me parece que un ejemplo de lo que usan otros sistemas seguros es un gran ejemplo de lo que es la mejor práctica.

— cjbarth 01 de

1

@ mklement0 Gracias, he actualizado la respuesta.

— Andrii Nemchenko

2

Una respuesta podría ser usar como tamaño de sal el valor que el hash que va a usar proporciona en términos de seguridad.

Por ejemplo, si va a utilizar SHA-512, use sal de 256 bits, ya que la seguridad proporcionada por SHA-512 es de 256 bits.

— Roberto Martelloni
fuente