Por qué SHA-256 es la herramienta equivocada para contraseñas
Abre diez tutoriales al azar sobre cómo guardar contraseñas y al menos tres te enseñarán sha256(password + salt). Parece seguro. No lo es.
SHA-256 está diseñado para ser rápido. Una tarjeta gráfica moderna calcula unos 50.000 millones por segundo. Si se filtra tu base de datos, un atacante prueba todas las contraseñas comunes contra todos los usuarios en una tarde, y la mayoría de las contraseñas elegidas por humanos salen en claro.
El salt no te salva. Los salts solo evitan tablas precomputadas de ataque. Contra un intento dirigido sobre un solo usuario, un salt no marca diferencia ninguna.
La respuesta correcta es un tipo distinto de hash, uno diseñado para ser intencionalmente lento. Hace el mismo trabajo (convertir una contraseña en algo que puedes guardar), pero hace que la tarde de ataque del atacante se convierta en siglos.
Qué algoritmo usar
| Algoritmo | Exigente en memoria | Veredicto 2026 | Cuándo |
|---|---|---|---|
| Argon2id | Sí | Default recomendado | Proyectos nuevos |
| bcrypt | No | Sigue seguro | Sistemas existentes, sin prisa |
| scrypt | Sí | Aceptable | Ya desplegado |
| PBKDF2 | No | Último recurso | Entornos regulados |
| MD5 / SHA-1 | No | Nunca | No vale para contraseñas |
Las tres opciones que vale la pena usar
Tres algoritmos han pasado las pruebas para almacenamiento de contraseñas en producción. Cada uno tiene una razón para elegirlo y una para saltarlo.
Argon2id es el default moderno. Es lento a propósito, necesita mucha memoria (que las tarjetas gráficas no tienen en cantidad), y tiene un modo híbrido que resiste varios tipos de ataque. Si arrancas de cero en 2026, este es el que toca.
bcrypt lleva en producción desde 1999. Es maduro, todos los lenguajes tienen una librería que funciona, y el mando de coste es intuitivo. Usa menos memoria que Argon2id, lo que lo hace ligeramente más fácil de atacar con hardware a medida, pero con un factor de coste alto sigue comprando segundos reales contra cualquier atacante realista. Si lo tienes desplegado, no te apresures a migrar.
scrypt queda en el medio. Es lento y exigente en memoria como Argon2, pero sus parámetros son más difíciles de razonar. Úsalo si ya lo tienes. No lo elijas para código nuevo a menos que tengas una razón concreta.
Lo que está mal: cualquier hash plano (SHA-256, MD5, BLAKE3), cualquier “SHA-256 iterado” casero, y PBKDF2 a menos que estés en un entorno regulado que prohíba los demás.
Si solo necesitas un checksum o una huella de contenido (no una contraseña), eso es el trabajo del generador de hash, no del almacén de contraseñas. Dos problemas distintos, dos herramientas distintas.
Parámetros que de verdad defienden en 2026
Los parámetros por defecto de un tutorial de 2018 están calibrados para hardware de 2018. Son demasiado baratos hoy.
Para Argon2id en 2026, un punto de partida razonable son unos 64 MB de memoria, tres iteraciones y un grado de paralelismo. Subes desde ahí hasta que cada hash tarde entre 250 y 500 ms en tu servidor. Ese es el punto dulce: lo bastante lento para fastidiar a los atacantes, lo bastante rápido para que los logins legítimos no parezcan colgados.
Para bcrypt, un factor de coste de 12 es el mínimo moderno. 13 si tu hardware aguanta. El factor de coste es exponencial, así que 13 es el doble de lento que 12 y cuatro veces más lento que 11.
La regla más importante: mide en tu hardware real de producción, no en el portátil. El número correcto es el que tarda 250 a 500 ms en la máquina que lo va a ejecutar.
La cuestión del pepper
Un pepper es un valor secreto que añades a cada contraseña antes de hashearla, guardado separado de la base de datos. Si la base se filtra pero el pepper no, el atacante no tiene nada que crackear.
Si añadirlo o no es un tradeoff. El pepper tiene que vivir en algún sitio al que llegue la aplicación pero no la base de datos. Sitios habituales: una variable de entorno, un gestor de secretos, un módulo hardware. Si puedes rotarlo limpio, añádelo. Si tu plan operacional para “dónde vive el pepper” es flojo, sáltalo.
El pepper no sustituye a un hash fuerte, es una capa extra.
Migrar sin romper a tus usuarios
Si tienes SHA-256 guardado hoy, no puedes rehashear a todo el mundo de golpe porque no tienes las contraseñas en plano. El camino es envolver el hash nuevo alrededor del viejo.
En cada login exitoso, tienes el plano un instante. En ese momento, calculas el hash nuevo, lo guardas, y marcas al usuario como “migrado”. Con el tiempo, cada usuario activo se rehashea. Los usuarios que no entran nunca se quedan en el hash viejo, lo cual está bien porque si la cuenta no se mueve, la amenaza es pequeña.
El enfoque “envolver el hash viejo” te deja empezar a defenderte de inmediato, sin un día clave donde todo el mundo tiene que resetear su contraseña. La mayoría de sistemas en producción migran así y funciona.
Una configuración práctica para 2026
Usa Argon2id en sistemas nuevos con los parámetros de arriba. Usa bcrypt con coste 12+ si ya lo tienes desplegado. Añade un pepper si puedes guardarlo y rotarlo limpio. Planea migración si todavía estás en la familia SHA o en PBKDF2.
Cuando necesites inspeccionar un formato de hash (qué algoritmo, qué parámetros), el generador de hash de AldeaCode corre en tu navegador, con una variante Node.js que refleja la API crypto y una variante Python para hashlib. El codificador Base64 ayuda cuando estás decodificando un hash guardado a su forma cruda. La guía Web Crypto cubre la diferencia entre hashear datos y hashear contraseñas con más profundidad.
El almacenamiento de contraseñas es una de esas pequeñas disciplinas donde hacerlo un poco mal filtra todas las cuentas a la vez. Hacerlo bien no es difícil, solo requiere elegir el hash lento a propósito y ajustarlo a tu hardware. El resto es detalle.