security - password - que es salt en criptografia
¿Está bien almacenar sales con hashes? (7)
En realidad, ya tiene un valor de sal almacenado en la tabla de usuario: el pkey de la tabla.
No tiene que inventar una nueva columna para almacenar la sal. Solo usa la llave. Esta idea, por supuesto, presume que tienes un pkey asociado con un nombre de usuario. por ejemplo, el nombre de usuario no es el pkey en la tabla.
Este es un wtb casi duplicado: hashing de contraseñas, sal y almacenamiento de valores hash
Según entiendo, una sal no pretende ser secreta, sino que simplemente pretende ser diferente de cualquier estándar centralizado, por lo que no se puede desarrollar una tabla arcoiris o un ataque similar para romper todos los hashes que usan el algoritmo, ya que la sal se rompe. la mesa del arcoiris Mi comprensión aquí podría no ser completamente correcta, así que corrígeme si estoy equivocado.
En una pieza ampliamente utilizada de software de código abierto, la sal sería ampliamente conocida, y esto te abre a los ataques porque ahora pueden simplemente atacar la versión salada de tu hash y crear tablas de arco iris que incluyan los datos de sal.
Según lo veo, hay dos opciones para lidiar con esto. El primero es cambiar la sal con cada nueva versión del software, pero esto no es bueno porque las nuevas versiones del software ya no podrían probar contra hashes de contraseñas antiguas.
La segunda solución que pensé fue tener una sal por contraseña almacenada; en otras palabras, cada contraseña recibe una sal diferente. La desventaja es que las sales tienen que estar asociadas con los hashes de la contraseña de alguna manera, probablemente solo pegándolos al lado de la contraseña en la base de datos. Incluso podría ser correcto usar el nombre de usuario (aunque quizás no, los nombres de usuario son demasiado cortos).
Mi pregunta es, ¿es esto aceptable? ¿Hay algún riesgo adicional asociado con almacenar la sal directamente con la contraseña que haste? Me parece que almacenar la sal en el código fuente no es diferente, por lo que no hay pérdida de seguridad almacenando la sal con la contraseña.
DESCARGO DE RESPONSABILIDAD: No estoy usando esto para ningún sistema de seguridad de la vida real. De hecho, nunca he diseñado un sistema de contraseñas de ningún tipo. Me mantengo vagamente informado sobre los problemas de seguridad.
Es perfectamente normal generar una sal única para cada contraseña. La sal puede ser un producto del material existente (como un ID de usuario, et al.) O generarse aleatoriamente. La ventaja es que un ataque contra la información encriptada se vuelve más impráctico a medida que crece la fuerza de la sal.
Recuerde: todos los algoritmos criptográficos son frágiles. La información solo se puede considerar "segura" si agrietar la protección (a través de una tabla de arcoíris o de otro modo) es más costosa de lo que vale la información.
editar:
Suponiendo que eres muy nuevo en la criptografía, aquí hay algunos consejos más:
- Las sales más largas son mejores que las cortas.
- Cuanto más valores posibles para una sal, mejor. Una sal alfanumérica es mejor que una numérica. Una sal binaria es mejor que una alfa-numérica.
- Las sales no harán que los ataques de fuerza bruta sean menos probables contra una sola contraseña.
Su segunda solución, "Tener una sal por contraseña almacenada", es la correcta y generalmente se usa.
El "Salt" está allí principalmente para que sea difícil detectar cuando dos usuarios tienen la misma contraseña, por lo que mezcla un "Salt" conocido en la contraseña. La sal debe ser obtenible en el momento de verificación de contraseña.
Por lo tanto, normalmente genera un sal aleatorio y lo almacena con la contraseña O utiliza otro identificador (ID de usuario, nombre de usuario, etc.) como sal.
Usar una sola sal para todas las contraseñas en la base de datos es útil, pero mucho menos seguro que dar a cada usuario una sal única.
Básicamente: una contraseña + salt más larga (en bytes) aumenta el espacio de búsqueda y, por lo tanto, dificulta el uso de tablas "rainbow estándar" estándar.
Sin embargo, si se usa la misma sal para todas las entradas, entonces es posible crear una tabla de arco iris específicamente para atacar su software. Si su base de usuarios es grande, entonces alguien podría decidir hacer una tabla de ese tipo.
Por ejemplo, si simplemente agrega "y mucha sal" al final de cada contraseña antes del hashing, un atacante podría construir una tabla de valores hash generados por muchas cadenas, todas esas cadenas que terminan con "y mucha sal". .
Por esta razón, una sal por usuario es la mejor manera de hacerlo. Sin embargo, recuerde que también desea que la contraseña + sal sea "larga".
Si desea usar la clave principal, probablemente sea una buena idea tomar el hash de la clave primaria en lugar de usar la clave principal en sí, porque si la contraseña + salt para el usuario 43 se ve como "myPassword00000000043", un atacante podría construir un tabla con la suposición de que hay muchos ceros en el medio. Sin embargo, las marcas de tiempo de creación y la secuencia aleatoria son probablemente mejores opciones, ya que las PKeys a veces se pueden encontrar o adivinar fácilmente.
Nota: no soy un verdadero experto en encriptación, no use este consejo en un sistema real.
actualización : use una biblioteca competente, por ejemplo, passlib para Python.
Éstos se encargan de generar una sal por contraseña y usan un algoritmo de hash adecuado (no es suficiente usar simplemente un algoritmo hash criptográfico como SHA1; hay que aplicarlo de forma que sea muy lento para revertir, por ejemplo, iterar 1000 o más veces, etc. Así es como funcionan las funciones de hash de contraseña, como bcrypt . Las bibliotecas de almacenamiento de contraseñas hacen todo esto correctamente, normalmente producen una cadena delimitada para que puedan determinar el sistema de hash y el factor de trabajo utilizado, solo almacena la cadena sin necesitando saber esto.
Puede almacenar la sal en ''texto sin formato'' en la tabla.
La sal no necesita ser secreta para ser efectiva
solo necesita ser aleatorio.
La sal refuerza una contraseña al hacer que el valor hash sea incomparable a la misma contraseña en la misma u otra base de datos, e invalidar grandes listas pregeneradas de contraseña común para búsquedas de hash (por ejemplo, ''tablas de arcoíris'').
Por lo tanto, es fundamental que la sal sea única por usuario y que se almacene algún valor aleatorio con la contraseña; las alternativas descritas en la pregunta (usando el nombre de usuario como sal, usando un único valor de sal para toda la aplicación) fallan:
si los sistemas usan el nombre de usuario u otros datos triviales, la contraseña se puede comparar con otros usuarios con el mismo nombre en otros sistemas (imagine la frecuencia con la que la cuenta de usuario "administrador" o "raíz" usa la misma contraseña en diferentes sistemas). .)
si el sistema usa una sola sal aleatoria para todos los usuarios en el mismo sistema, entonces dos usuarios que por casualidad tienen la misma contraseña tendrían el mismo hash, y adivinar la contraseña de un usuario comprometería trivialmente al otro.
Tratar de mantener la sal en secreto no tiene sentido , porque toda la práctica de las contraseñas de salting y hashing existe solo porque sabemos por experiencia que ni siquiera podemos mantener nuestras bases de datos secretas con total fiabilidad. A lo sumo, puedes almacenar la sal por separado y esperar que un atacante que tenga acceso a tu DB no la encuentre, pero si usaste un buen algoritmo hash y sales individuales lo suficientemente largas, deberías estar seguro de cualquier manera.
El objetivo de una sal es garantizar que no se puede amortizar el costo de un ataque de fuerza bruta en una base de datos completa o incluso en varias bases de datos.
El primero es cambiar la sal con cada nueva versión del software, pero esto no es bueno porque las nuevas versiones del software ya no podrían probar contra hashes de contraseñas antiguas.
Una variación de esto que he visto es generar un sal aleatorio durante la instalación (y por supuesto mantenerlo en todas las versiones) para que cada instancia en ejecución tenga una diferente. Por supuesto, tener una sal diferente para cada contraseña (tal vez además de la anterior) es aún mejor.
La salt , por definición, debe ser aleatoria para ser efectiva. No use ningún valor determinista para esto. Esto, por supuesto, implica que debe almacenarlo en la base de datos junto con la contraseña hash. Los sistemas UNIX tradicionalmente incluso almacenan el hash en el mismo campo que la contraseña (el salt es un prefijo de longitud fija de la contraseña). En una base de datos, puede tener una columna adicional en la tabla de usuarios.