¿Cómo deben almacenarse las contraseñas y por qué usar bcrypt/scrypt/argon2 en lugar de hashes rápidos?
Respuesta breve
Almacena las contraseñas usando una función de hashing de contraseñas deliberadamente lenta, salada y adaptativa —bcrypt, scrypt o Argon2— nunca un hash rápido de propósito general como SHA-256 o MD5. Los hashes rápidos están hechos para la velocidad, así que atacantes con GPU pueden probar miles de millones de intentos por segundo contra una base de datos filtrada. Los hashes lentos tienen un factor de trabajo ajustable (y un coste de memoria) que hace cada intento caro, manteniendo la fuerza bruta impracticable incluso tras una filtración.
Esta es una pregunta decisiva en appsec. La respuesta equivocada («hacemos un SHA-256 de la contraseña») suena responsable pero es exactamente el error que convierte una filtración de base de datos en un secuestro masivo de cuentas. La idea clave es que el hashing de contraseñas quiere ser lento.
Por qué fallan los hashes rápidos
SHA-256, SHA-1 y MD5 están diseñados para ser rápidos: una virtud para la integridad de archivos, donde se hashean gigabytes con rapidez. Pero la velocidad es un lastre para las contraseñas. Cuando un atacante roba una tabla de contraseñas hasheadas, la rompe sin conexión, y con GPU modernas puede calcular miles de millones de intentos de hash rápido por segundo. Combinado con listas de palabras filtradas y la realidad de que los usuarios eligen contraseñas predecibles, la mayoría de las contraseñas hasheadas rápido caen en horas. El salado ayuda contra el precálculo pero no hace nada contra la velocidad bruta de adivinación.
Por qué ganan los hashes lentos y adaptativos
Los hashes de contraseñas diseñados para ello cuestan deliberadamente mucho por evaluación:
- bcrypt tiene un factor de trabajo (coste) ajustable que aumentas con el tiempo a medida que mejora el hardware; ha sido probado durante décadas.
- scrypt añade dureza de memoria, obligando a cada intento a consumir mucha RAM, lo que frena el descifrado paralelo barato en GPU/ASIC.
- Argon2 (ganador de la Password Hashing Competition) ajusta tiempo, memoria y paralelismo de forma independiente y es la recomendación moderna por defecto.
La idea compartida: hacer que un solo intento tarde, digamos, 100 ms en lugar de un nanosegundo. Eso es invisible para un inicio de sesión legítimo pero multiplica el coste de un atacante en órdenes de magnitud, de modo que incluso una base de datos filtrada resiste el descifrado. Las sales (únicas por usuario) siguen siendo obligatorias por encima, para frenar las tablas arcoíris y las filtraciones de hashes idénticos.
¿Por qué no cifrar en su lugar?
El cifrado es reversible, lo que significa que la clave existe en algún lugar, y si la clave se compromete, cada contraseña se recupera al instante. El hashing es unidireccional por diseño; verificas re-hasheando la entrada, nunca descifrando. Nunca deberías necesitar el texto plano de vuelta.
Qué buscan los entrevistadores
Nombrar bcrypt/scrypt/Argon2, explicar la lógica lento-por-diseño / factor de trabajo, el salado por encima, la dureza de memoria como extra, y un firme «hashear, no cifrar» con el razonamiento.
Posibles preguntas de seguimiento
- ¿Por qué ser rápido es una debilidad para un hash de contraseña pero una fortaleza para una suma de comprobación de archivo?
- ¿Qué defiende la dureza de memoria de Argon2 que bcrypt no?
- ¿Por qué nunca deberías cifrar (de forma reversible) las contraseñas almacenadas?