No estoy seguro de cómo funciona el hashing de contraseñas (lo implementaremos más adelante), pero necesito crear un esquema de base de datos ahora.

Estoy pensando en limitar las contraseñas a 4-20 caracteres, pero según tengo entendido, después de cifrar la cadena hash será de diferente longitud.

Entonces, ¿cómo almacenar estas contraseñas en la base de datos?

Actualización: el simple uso de una función hash no es lo suficientemente fuerte como para almacenar contraseñas. Deberías leer la respuesta de Gilles en este hilo para obtener una explicación más detallada.

Para las contraseñas, use un algoritmo hash de fortalecimiento de claves como Bcrypt o Argon2i. Por ejemplo, en PHP, use la función password_hash () , que usa Bcrypt por defecto.

$hash = password_hash("rasmuslerdorf", PASSWORD_DEFAULT);

El resultado es una cadena de 60 caracteres similar a la siguiente (pero los dígitos variarán, ya que genera una sal única).

$2y$10$.vGA1O9wmRjrwAVXD98HNOgsNpDczlqm3Jq7KnEd1rVAGv3Fykk1a

Use el tipo de datos SQL CHAR(60) para almacenar esta codificación de un hash Bcrypt. Tenga en cuenta que esta función no codifica como una cadena de dígitos hexadecimales, por lo que no podemos eliminarla fácilmente para almacenarla en binario.

Otras funciones hash todavía tienen usos, pero no para almacenar contraseñas, por lo que conservaré la respuesta original a continuación, escrita en 2008.

Depende del algoritmo de hash que uses. El hash siempre produce un resultado de la misma longitud, independientemente de la entrada. Es típico representar el resultado del hash binario en el texto, como una serie de dígitos hexadecimales. O puede usar la UNHEX()función para reducir una cadena de dígitos hexadecimales a la mitad.

• MD5 genera un valor hash de 128 bits. Puede usar CHAR (32) o BINARY (16)
• SHA-1 genera un valor hash de 160 bits. Puede usar CHAR (40) o BINARY (20)
• SHA-224 genera un valor hash de 224 bits. Puede usar CHAR (56) o BINARY (28)
• SHA-256 genera un valor hash de 256 bits. Puede usar CHAR (64) o BINARY (32)
• SHA-384 genera un valor hash de 384 bits. Puede usar CHAR (96) o BINARY (48)
• SHA-512 genera un valor hash de 512 bits. Puede usar CHAR (128) o BINARY (64)
• BCrypt genera un valor hash de 448 bits dependiente de la implementación. Es posible que necesite CHAR (56), CHAR (60), CHAR (76), BINARY (56) o BINARY (60)

A partir de 2015, NIST recomienda usar SHA-256 o superior para cualquier aplicación de funciones hash que requiera interoperabilidad. Pero NIST no recomienda el uso de estas funciones simples de hash para almacenar contraseñas de forma segura.

Los algoritmos de hash menores tienen sus usos (como internos a una aplicación, no para intercambio), pero se sabe que son crackeables .

En realidad, puede usar CHAR(longitud de hash) para definir su tipo de datos para MySQL porque cada algoritmo de hash siempre evaluará la misma cantidad de caracteres. Por ejemplo, SHA1siempre devuelve un número hexadecimal de 40 caracteres.

Utilice siempre un algoritmo de hash de contraseña: Argon2 , scrypt , bcrypt o PBKDF2 .

Argon2 ganó el concurso de hashing de contraseñas de 2015. Scrypt , bcrypt y PBKDF2 son algoritmos más antiguos que ahora se consideran menos preferidos, pero aún son fundamentalmente sólidos, por lo que si su plataforma aún no es compatible con Argon2, está bien usar otro algoritmo por ahora.

Nunca almacene una contraseña directamente en una base de datos. Tampoco lo cifre: de lo contrario, si se viola su sitio, el atacante obtiene la clave de descifrado y puede obtener todas las contraseñas. Las contraseñas DEBEN ser hash .

Un hash de contraseña tiene propiedades diferentes de un hash de tabla hash o un hash criptográfico. Nunca use un hash criptográfico ordinario como MD5, SHA-256 o SHA-512 en una contraseña. Un algoritmo de hash de contraseña utiliza un salt , que es único (no se usa para ningún otro usuario o en la base de datos de nadie). La sal es necesaria para que los atacantes no puedan calcular previamente los valores hash de las contraseñas comunes: con una sal, tienen que reiniciar el cálculo para cada cuenta. Un algoritmo de hash de contraseña es intrínsecamente lento , tan lento como puede permitirse. La lentitud lastima al atacante mucho más que a ti porque el atacante tiene que probar muchas contraseñas diferentes. Para obtener más información, consulte Cómo contraseñas seguras de hash .

Un hash de contraseña codifica cuatro piezas de información:

• Un indicador de qué algoritmo se utiliza. Esto es necesario para la agilidad : las recomendaciones criptográficas cambian con el tiempo. Debe poder realizar la transición a un nuevo algoritmo.
• Un indicador de dificultad o dureza. Cuanto mayor sea este valor, más cálculo se necesita para calcular el hash. Esto debería ser un valor de configuración constante o global en la función de cambio de contraseña, pero debería aumentar con el tiempo a medida que las computadoras se vuelven más rápidas, por lo que debe recordar el valor de cada cuenta. Algunos algoritmos tienen un solo valor numérico, otros tienen más parámetros allí (por ejemplo, para ajustar el uso de la CPU y el uso de RAM por separado).
• La sal. Como la sal debe ser globalmente única, debe almacenarse para cada cuenta. La sal debe generarse aleatoriamente en cada cambio de contraseña.
• El hash propiamente dicho, es decir, la salida del cálculo matemático en el algoritmo de hash.

Muchas bibliotecas incluyen un par de funciones que convenientemente empaqueta esta información como una sola cadena: una que toma el indicador del algoritmo, el indicador de dureza y la contraseña, genera una sal aleatoria y devuelve la cadena hash completa; y uno que toma una contraseña y la cadena hash completa como entrada y devuelve un booleano que indica si la contraseña era correcta. No hay un estándar universal, pero una codificación común es

$ algoritmo $ parámetros $ salt $ salida

donde algorithmes un número o una cadena alfanumérica corta que codifica la elección del algoritmo, parameterses una cadena imprimible salty outputestá codificada en Base64 sin terminar= .

16 bytes son suficientes para la sal y la salida. (Ver, por ejemplo, recomendaciones para Argon2 .) Codificado en Base64, son 21 caracteres cada uno. Las otras dos partes dependen del algoritmo y los parámetros, pero son típicos de 20 a 40 caracteres. Eso es un total de aproximadamente 82 caracteres ASCII ( CHAR(82)y no es necesario usar Unicode), a lo que debe agregar un margen de seguridad si cree que será difícil ampliar el campo más adelante.

Si codifica el hash en formato binario, puede reducirlo a 1 byte para el algoritmo, 1-4 bytes para la dureza (si codifica algunos de los parámetros) y 16 bytes cada uno para la sal y la salida , para un total de 37 bytes. Digamos 40 bytes ( BINARY(40)) para tener al menos un par de bytes de repuesto. Tenga en cuenta que estos son bytes de 8 bits, no caracteres imprimibles, en particular el campo puede incluir bytes nulos.

Tenga en cuenta que la longitud del hash no tiene ninguna relación con la longitud de la contraseña.

Puede encontrar este artículo de Wikipedia sobre la salazón que vale la pena . La idea es agregar un conjunto de datos para aleatorizar su valor hash; esto protegerá sus contraseñas de ataques de diccionario si alguien obtiene acceso no autorizado a los hashes de contraseñas.

Como una cadena de longitud fija (VARCHAR (n) o como MySQL lo llame). Un hash siempre tiene una longitud fija de, por ejemplo, 12 caracteres (según el algoritmo de hash que utilice). Por lo tanto, una contraseña de 20 caracteres se reduciría a un hash de 12 caracteres, y una contraseña de 4 caracteres también generaría un hash de 12 caracteres.

Debería usar TEXT(almacenar un número ilimitado de caracteres) en aras de la compatibilidad hacia adelante. Los algoritmos de hash (deben) fortalecerse con el tiempo y, por lo tanto, este campo de la base de datos deberá admitir más caracteres con el tiempo. Además, dependiendo de su estrategia de migración, es posible que necesite almacenar hashes nuevos y antiguos en el mismo campo, por lo que no se recomienda fijar la longitud a un tipo de hash.

Realmente depende del algoritmo de hash que estés usando. La longitud de la contraseña tiene poco que ver con la longitud del hash, si no recuerdo mal. Busque las especificaciones del algoritmo de hash que está utilizando, ejecute algunas pruebas y trunca justo por encima de eso.

Los hashes son una secuencia de bits (128 bits, 160 bits, 256 bits, etc., según el algoritmo). Su columna debe ser de tipo binario, no de texto / caracteres, si MySQL lo permite (el tipo de datos de SQL Server es binary(n)o varbinary(n)). También debes salar los hash. Las sales pueden ser de texto o binarias, y necesitará una columna correspondiente.

Siempre probé para encontrar la longitud MÁXIMA de una cadena encriptada y establecerla como la longitud de caracteres de un tipo VARCHAR. Dependiendo de cuántos registros va a tener, realmente podría ayudar al tamaño de la base de datos.

para md5 vARCHAR (32) es apropiado. Para aquellos que usan AES, mejor usar varbinary.