Hashing de contraseñas: bcrypt, Argon2 y PBKDF2

Almacenar contraseñas en texto plano es catastrófico: una sola filtración de la base de datos expone todas las cuentas. Las contraseñas deben procesarse con una función unidireccional antes de almacenarlas, de modo que ni siquiera el acceso a la base de datos revele la contraseña original.

Una función hash convierte una entrada de cualquier longitud en una salida de longitud fija. La misma entrada siempre produce la misma salida, pero no es posible recuperar el original a partir del hash. Ejemplos: SHA-256, bcrypt, Argon2.

Las funciones hash de propósito general como SHA-256 están diseñadas para ser rápidas. Un atacante puede calcular miles de millones de hashes SHA-256 por segundo con una GPU, lo que hace viable el descifrado por fuerza bruta.

Para las contraseñas se necesitan funciones lentas y costosas.

Un salt es un valor aleatorio que se añade a cada contraseña antes de aplicar el hash. Garantiza que dos usuarios con la misma contraseña tengan hashes diferentes, lo que evita ataques de tablas rainbow y de descifrado por lotes. El salt se almacena junto al hash (no es secreto).

bcrypt se diseñó en 1999 específicamente para aplicar hash a contraseñas. Tiene un factor de coste configurable que controla la lentitud del proceso de hash. A medida que mejora el hardware, aumente el factor de coste para mantener la seguridad.

Un factor de coste de 12 es habitual actualmente: tarda aproximadamente 250 ms en aplicar el hash en una CPU moderna.

PBKDF2 (Password-Based Key Derivation Function 2) aplica una función hash (por ejemplo, HMAC-SHA256) muchas veces (iteraciones). Más iteraciones = más lento = más seguro. Recomendado por NIST y utilizado por WPA2 para las contraseñas de Wi-Fi.

Argon2 ganó la competición de hashing de contraseñas en 2015. Es el estándar moderno. Se puede configurar mediante:

• Coste temporal — número de iteraciones
• Coste de memoria — RAM necesaria (limita la aceleración mediante GPU)
• Paralelismo — número de hilos

Use Argon2id para la mayoría de las aplicaciones.

Una tabla rainbow es una tabla de consulta precalculada de hash → texto plano. Sin salt, un atacante que tiene el hash puede buscarlo en la tabla al instante. El uso de salt inutiliza las tablas rainbow porque cada hash es único.

Enfoques habituales para el descifrado sin conexión:

• Ataque de diccionario — probar contraseñas comunes y variaciones
• Fuerza bruta — probar todas las combinaciones de caracteres
• Basado en reglas — aplicar reglas de mutación a un diccionario (añadir el año, poner en mayúscula, usar leetspeak)
• Herramientas: Hashcat, John the Ripper

Orden de preferencia para aplicaciones nuevas:

1. Argon2id — mayor resistencia al descifrado con GPU/ASIC
2. bcrypt — ampliamente compatible y con una trayectoria probada
3. PBKDF2 — aprobado por NIST y obligatorio en algunos contextos de cumplimiento

No utilice nunca: MD5, SHA-1 ni SHA-256 sin salt para las contraseñas.

Cuando un usuario inicia sesión:

1. Recupere el hash y el salt almacenados del usuario
2. Calcule el hash de la contraseña enviada con el mismo salt y algoritmo
3. Compare el hash resultante con el hash almacenado (comparación en tiempo constante)
4. Nunca descifre: solo realice la comparación

Las contraseñas deben almacenarse como hashes, no como texto plano. Los algoritmos rápidos, como SHA-256, no son adecuados: utilice funciones lentas de hashing de contraseñas: Argon2id (preferido), bcrypt o PBKDF2. Utilice siempre un salt aleatorio por contraseña para evitar ataques mediante tablas rainbow. Nunca implemente su propia criptografía: utilice bibliotecas probadas.