Por qué un hash lento
Cuando una base de datos se filtra, los atacantes adivinan contraseñas sin conexión contra los hashes almacenados. Un hash rápido como SHA-256 permite a una sola GPU probar unos diez mil millones de intentos por segundo, lo que convierte la mayoría de las contraseñas elegidas por personas en texto claro en cuestión de horas. Las funciones de hash de contraseñas son deliberadamente lentas y, en los diseños más nuevos, ávidas de memoria, de modo que cada intento le cuesta al atacante tanto como a ti, y los miles de núcleos de una GPU no ayudan porque comparten demasiada poca memoria.
| Función | Año | Ajustable | Recomendado (OWASP 2024) | Cuándo usarla |
|---|---|---|---|---|
| Argon2id | 2015 | memoria, pasadas, carriles | m=19 MiB, t=2, p=1 (o m=64 MiB, t=3) | Por defecto en sistemas nuevos. Ganadora de la Password Hashing Competition. |
| scrypt | 2009 | N, r, p | N=2¹⁷, r=8, p=1 | Exigente en memoria; bien donde no hay Argon2. |
| bcrypt | 1999 | coste (2ⁿ rondas) | coste 10 o más | En todas partes; sigue siendo sólida. Trunca a 72 bytes. |
| PBKDF2 | 2000 | iteraciones | 600.000 (SHA-256) | Cumplimiento FIPS; no es exigente en memoria, así que es la más débil frente a GPU. |
Leer una cadena de hash
$2b$12$ + 22 caracteres de sal + 31 de hash: bcrypt, coste 12 (4.096 rondas). $argon2id$v=19$m=19456,t=2,p=1$sal$hash: Argon2id con sus parámetros en la cadena, Base64 sin relleno. Ambos formatos llevan todo lo necesario para verificar, así que puedes subir el coste con el tiempo y volver a hashear a los usuarios en su siguiente inicio de sesión. scrypt y PBKDF2 no tienen formato de cadena universal; la sal y los parámetros se guardan al lado, por eso el verificador pide la sal por separado.
Elegir un coste
Apunta a unos 100–300 ms por hash en tu servidor. Esta página indica cuánto tardó cada hash en tu navegador (un portátil decente es comparable a un núcleo de servidor pequeño). Argon2 con los 19 MiB recomendados tarda alrededor de un segundo en JavaScript; las implementaciones nativas son varias veces más rápidas.
Qué no hacer
No uses MD5, SHA-1 o SHA-256 solos, ni siquiera con sal. No uses una única sal para todo el sitio. No pre-hashees con SHA-256 para saltarte el límite de 72 bytes de bcrypt a menos que también codifiques el resultado en Base64 (los bytes en bruto pueden contener NUL, donde bcrypt se detiene). Y no pegues contraseñas reales de producción en ninguna página web, incluida esta; usa valores de prueba.
Preguntas
¿Es seguro usar esta página con una contraseña real?
El hashing se ejecuta en tu navegador y nada se transmite, pero la regla sensata es tratar toda página web como no fiable para credenciales reales. Úsala para generar hashes para fixtures de prueba, entender los formatos y verificar con contraseñas desechables.
¿Por qué bcrypt da un hash distinto cada vez?
La sal es aleatoria en cada llamada; se guarda dentro de la cadena del hash. La verificación la extrae y recalcula. Dos hashes de la misma contraseña deben diferir; ambos verifican.
¿Por qué falla mi verificación bcrypt con una contraseña larga?
bcrypt usa solo los primeros 72 bytes. Si la contraseña la hasheó una biblioteca que pre-hashea (algunas configuraciones de Django y Passlib), la verificación bcrypt en bruto de aquí no coincidirá. Comprueba también el prefijo: los hashes $2y$ y $2b$ son compatibles; $2x$ marca una implementación defectuosa.
¿Qué significan m, t y p en Argon2?
m es la memoria en KiB (19456 = 19 MiB), t el número de pasadas sobre esa memoria, p el número de carriles que pueden ejecutarse en paralelo. La memoria es el mando principal de seguridad: es lo que encarece los ataques con GPU y ASIC.