Las contraseñas nunca deben almacenarse en texto plano. Se guardan hasheadas, de modo que ni siquiera el sistema conozca la contraseña real: al iniciar sesión, se hashea lo ingresado y se compara con el hash guardado. Como el hash es irreversible, una filtración no revela las contraseñas de forma directa.
Pero no sirve cualquier hash: para contraseñas se usan funciones diseñadas para ser lentas y combinadas con un salt, como bcrypt, scrypt y Argon2.
Por qué un hash rápido (SHA-256) no alcanza:
- Es tan veloz que un atacante puede probar miles de millones por segundo (fuerza bruta).
- Las rainbow tables (tablas de hashes precalculados) rompen contraseñas comunes al instante.
Las dos defensas clave:
| Defensa | Qué hace |
|---|---|
| Hashing lento (bcrypt/Argon2) | Hace costoso cada intento → frena la fuerza bruta |
| Salt | Valor aleatorio único por contraseña, añadido antes de hashear |
El salt logra que dos usuarios con la misma contraseña tengan hashes distintos, e inutiliza las rainbow tables.
Algoritmos recomendados:
| Algoritmo | Notas |
|---|---|
| Argon2 | Más moderno; ganador del Password Hashing Competition; resistente a GPU/ASIC |
| bcrypt | Muy probado y ampliamente soportado |
| scrypt | Alto uso de memoria, resistente a hardware especializado |
⚠️ No usar para contraseñas: MD5, SHA-1 o SHA-256 "a secas" (son rápidos y, solos, inseguros para este fin).
Conceptos complementarios:
- Factor de coste / iteraciones → se puede subir para mantener el ritmo del hardware moderno.
- Pepper → secreto adicional (no almacenado junto al hash) para reforzar aún más.
Buenas prácticas para el usuario: contraseñas largas y únicas por sitio, gestor de contraseñas y MFA. Aunque el sitio hashee bien, una contraseña débil sigue siendo vulnerable.
Este tema aplica el hashing a un caso crítico de seguridad. Se conecta con los ataques a contraseñas (Pentest) y con la protección de credenciales en general.