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
fuente
Respuestas:
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.
fuente
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.
fuente
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.
fuente
Wikipedia :
La sal de 128 bits (16 bytes) será suficiente. Puede representarlo como una secuencia de
128 / 4 = 32dígitos hexadecimales.fuente
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.
fuente