Almacene las contraseñas con Argon2id, configurado con al menos 19 MiB de memoria, 2 iteraciones y 1 grado de paralelismo, y con un salt único por contraseña. Esa es la configuración mínima de la OWASP Password Storage Cheat Sheet. Si su base de datos aún contiene hashes MD5, SHA-1 o sin salt, puede corregirlo sin un restablecimiento masivo de contraseñas y sin dejar hashes débiles en las cuentas inactivas.
Qué utilizar y cuáles son los ajustes mínimos
La cheat sheet establece estos mínimos:
| Situación | Algoritmo | Ajustes mínimos |
|---|---|---|
| Preferido | Argon2id | 19 MiB de memoria, 2 iteraciones, paralelismo 1 |
| Argon2id no disponible | scrypt | parámetro de coste 2^17, tamaño de bloque 8, paralelismo 1 |
| Sistemas heredados con bcrypt | bcrypt | factor de trabajo 10 o superior, límite de contraseña de 72 bytes |
| Se exige cumplimiento de FIPS-140 | PBKDF2 | 600.000 o más, HMAC-SHA-256 |
Argon2id es la variante principal de la RFC 9106, y toda implementación de ese documento debe soportarla. Funciona como Argon2i durante la primera mitad de la primera pasada sobre la memoria y como Argon2d en el resto.
El límite de 72 bytes de bcrypt
La cheat sheet fija un límite de contraseña de 72 bytes para bcrypt. Las fuentes no indican cómo tratan cada una de las bibliotecas las entradas más largas, así que pruebe la suya. Calcule el hash de una contraseña formada por 72 caracteres a seguidos de b y después verifique 72 caracteres a seguidos de c. Si la verificación tiene éxito, su biblioteca trunca en silencio.
A continuación, limite la longitud de la contraseña en sus formularios a 72 bytes e indíquelo claramente, o bien planifique la migración a Argon2id. La RFC 9106 admite contraseñas de hasta 2^32-1 bytes.
Por qué fallan los hashes rápidos
MD5 y SHA-1 se diseñaron para ser rápidos, y SHA-256 no es adecuado por la misma razón: permite a un atacante probar un gran número de candidatas con rapidez. El atacante calcula el hash de candidatas procedentes de listas de contraseñas filtradas, diccionarios o fuerza bruta y compara los resultados con sus filas. Las GPU y los servidores en la nube de alquiler lo hacen barato.
Un salt único obliga al atacante a descifrar los hashes uno a uno. También anula las rainbow tables, y las contraseñas idénticas dejan de producir hashes idénticos. La RFC 9106 recomienda un salt de 16 bytes para el hashing de contraseñas. Las bibliotecas maduras generan y almacenan el salt por usted, así que no escriba esa parte a mano.
Ajuste del factor de trabajo
No existe una cifra universal. Depende de su servidor y de su número de usuarios, y se determina experimentando con el hardware que utiliza. La regla general es que un hash debe tardar menos de un segundo.
Pasarse tiene un precio. Cada intento de inicio de sesión consume CPU, y una avalancha de intentos puede agotar el servidor. Haga pruebas de rendimiento con una concurrencia realista y elija un valor que pueda permitirse en los picos de carga.
Compruebe la unidad que espera su biblioteca de Argon2. La RFC 9106 define el tamaño de memoria en kibibytes, mientras que la cheat sheet lo expresa en MiB. 19 MiB son 19456 KiB, y si pasa 19 donde la biblioteca espera KiB, obtiene 19 KiB de memoria. Esa configuración funciona y es mucho más débil de lo previsto.
El factor de trabajo suele almacenarse en la propia salida del hash. Eso facilita la migración, porque en el login puede ver con qué parámetros se creó cada hash.
Pepper como capa adicional
Un pepper es un secreto compartido por todas las contraseñas almacenadas y conservado fuera de la base de datos, en un gestor de secretos o en un HSM. Resulta útil cuando el atacante obtiene solo la base de datos, mediante una inyección SQL o una copia de seguridad robada. Por sí solo no aporta nada, así que considérelo defensa en profundidad.
El problema es la rotación. Un pepper comprometido no puede cambiarse sin conocer la contraseña de cada usuario, de modo que sustituirlo obliga a restablecer las contraseñas de todos a quienes protegía. Decida quién es responsable de ese procedimiento antes de introducir un pepper.
Migración de hashes antiguos
El enfoque de la cheat sheet para aumentar un factor de trabajo consiste en esperar a que el usuario se autentique de nuevo y entonces recalcular el hash de su contraseña con los nuevos ajustes. El paso desde MD5, SHA-1 o hashes sin salt sigue la misma lógica, aunque esa extensión es nuestra.
- Marque cada hash almacenado con su algoritmo, en una columna aparte o mediante el formato del hash. Si no está seguro de lo que contiene la tabla, el identificador de hashes le ayuda a reconocer los formatos.
- En el login, verifique con el algoritmo que use el hash almacenado.
- Si la verificación tiene éxito y el hash es heredado o está por debajo de sus parámetros actuales, calcule un nuevo hash Argon2id a partir de la contraseña enviada, con un salt nuevo.
- Sobrescriba el valor antiguo en la misma operación.
ok = verify(row.scheme, row.hash, submitted)
if ok and (row.scheme != "argon2id" or needs_rehash(row.hash)):
row.hash = argon2id_hash(submitted) # fresh salt, current parameters
row.scheme = "argon2id"
save(row)Cuentas inactivas
Los usuarios que no vuelven a iniciar sesión nunca se actualizan, de modo que sus hashes débiles permanecen en la tabla indefinidamente. Una solución es envolverlos ahora. Aplique Argon2id sobre el valor MD5 o SHA-1 existente, almacene el resultado con un marcador de esquema como argon2id(md5) y elimine el hash original.
En el login, calcule el hash heredado de la contraseña enviada, verifíquelo contra el envoltorio Argon2id y, si tiene éxito, sustituya el envoltorio por un hash Argon2id simple. Registre con exactitud cómo se codifica el valor heredado (hexadecimal o bytes en bruto), porque una discrepancia rompe todos los inicios de sesión de ese esquema. Pruebe antes la ruta envuelta con una copia de la tabla.
Envolver el hash no convierte en fuerte una contraseña débil. Lo que consigue es que una tabla robada no pueda atacarse a la velocidad de MD5.
La alternativa es eliminar los hashes antiguos tras una fecha límite y exigir un restablecimiento en el siguiente inicio de sesión, algo que la cheat sheet describe como una opción según la aplicación. Si el cambio afecta a un código que no controla por completo, nuestro equipo de desarrollo seguro de software puede revisarlo.
Por dónde empezar
- Audite la tabla de usuarios: qué algoritmos hay, si existen salts y si alguna contraseña está en texto plano o cifrada de forma reversible. El cifrado solo es aceptable cuando es necesario recuperar la contraseña original, y la cheat sheet indica que conviene evitar esa necesidad.
- Elija Argon2id con al menos 19456 KiB, 2 iteraciones y paralelismo 1, y mida su rendimiento en el hardware de producción hasta que un hash tarde menos de un segundo.
- Si utiliza bcrypt, ejecute la prueba de 72 bytes descrita arriba y decida entre limitar la longitud o migrar a Argon2id.
- Añada un marcador de algoritmo al esquema y cambie el código de login para verificar con el esquema antiguo y recalcular el hash cuando la verificación tenga éxito.
- Envuelva en Argon2id los hashes heredados restantes, o fije una fecha límite a partir de la cual se eliminen y se exija un restablecimiento.
- Si añade un pepper, guárdelo en un gestor de secretos y documente antes el procedimiento de rotación y de restablecimiento forzado.
