¿De dónde deben provenir los valores de hash de sal?

Por lo general, tengo una columna created TIMESTAMP en una tabla de usuarios para que pueda ver cuándo se registró el usuario. No me gusta agregar una columna adicional para Salt, así que uso la columna de marca de tiempo como sal:

SHA1(password + created)

¿Importa?

La sal sirve para dos propósitos. Hace que no sea práctico utilizar tablas grandes de contraseñas prehasheadas ("tablas de arco iris") y hace que las contraseñas idénticas se vean diferentes en la lista de hashes. Hacer que las contraseñas idénticas parezcan diferentes ayuda a evitar un problema en el que varias personas usan una contraseña en particular, que probablemente sea una débil común.

Por lo tanto, cada cuenta debe tener su propia sal única, y las sales no deben ser demasiado predecibles, en el sentido de que no habrá un grupo de sales que puedan ocurrir. (Si muchos sitios comenzaron en 1 y contaron, los malos podrían construir tablas de arco iris que incluyen sales de números bajos, por ejemplo). No tienen que ser aleatorios en ningún sentido que no sea generalmente impredecible. No son más secretos que el hash en sí, por lo que no tienen que ser específicamente indiscutibles.

Utilice cualquier método conveniente para generar una sal. Si hay muchos valores potenciales de sal (los sistemas Unix antiguos usaban con frecuencia dos bytes, para un número posible de 65536) en comparación con el número de cuentas, la asignación semi-aleatoria casi nunca daría una sal duplicada.

Cada vez que desee almacenar una nueva contraseña (registro, restablecimiento de contraseña, actualización de contraseña), una buena técnica es:

• generar nueva sal
  • use un generador de números pseudoaleatorios seguro criptográficamente
  • use un tamaño de sal decente; un buen valor es el tamaño de bloque del algoritmo de hash subyacente (podría ser SHA-256)
• generar un nuevo token de contraseña
  • cree una función hmac a partir del algoritmo de hash subyacente (podría ser SHA-256) usando la sal como clave hmac
  • for i in (0...65536) { password = hmac(password) }
  • el resultado de las aplicaciones iteradas de la función hmac es el token de contraseña
• almacena el salt y el token de contraseña
  • no almacene la contraseña original
  • opcionalmente, almacene el algoritmo de hash subyacente y los tramos para el descubrimiento

Aproveche el marco. En .NET puede usar el RNGCryptoServoiceProvider ...

        // If salt is not specified, generate it on the fly.
        if (saltBytes == null)
        {
            // Define min and max salt sizes.
            int minSaltSize = 4;
            int maxSaltSize = 8;

            // Generate a random number for the size of the salt.
            Random  random = new Random();
            int saltSize = random.Next(minSaltSize, maxSaltSize);

            // Allocate a byte array, which will hold the salt.
            saltBytes = new byte[saltSize];

            // Initialize a random number generator.
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            // Fill the salt with cryptographically strong byte values.
            rng.GetNonZeroBytes(saltBytes); 
        }

Otros marcos deberían tener clases similares que puedas aprovechar. Para lograr la aleatoriedad, el software a menudo emplea al usuario frente a Random como se mencionó anteriormente. Mover al azar un mouse en un área definida para proporcionar sal es una opción empleada por TrueCrypt. Se reduce a sus necesidades específicas y nivel de seguridad; ya que su sal podría simplemente ser !@#$% .

Usted genera un servidor de servidor sal y lo asigna a una cuenta de usuario en el momento de su creación. Utilice mejor la API de generación de cifrado disponible con su marco, pero en principio cualquier secuencia funcionará.

Por lo general, las cosas se almacenan así:

User
-------------------
ID
Username
PasswordHashWithSalt

Ejemplo:

PasswordHashWithSalt =

A15CD9652D4F4A3FB61A2A422AEAFDF0DEA4E703 j5d58k4b56s8744q

Use bcrypt y lea este artículo , ya que solo los hashes normales no es una protección seria en este día y edad

Considere utilizar protocolo de contraseña de conocimiento cero SDR que tiene muchas bibliotecas de código abierto y no tiene patentes.

SDR requiere sal y el mejor lugar para conseguirlo es el cliente; cronometre sus pulsaciones de teclado, movimientos de mouse, hash de sus variables de entorno, números aleatorios, tiempos de creación de archivos en su carpeta temporal, para hacer que la sal salga en su extremo de una manera impredecible lejos de su servidor. SDR toma el salt, un número primo grande, la contraseña del usuario y genera una clave de verificación. No almacena una contraseña, nunca deja su máquina, pero puede verificar que tengan la contraseña que va con la clave del verificador y la sal. Es inmune al hombre en el medio y a los ataques de diccionario. Cifre las claves y la sal en la columna de la base de datos solo para estar seguro.