Cuando te registras en una web bien hecha, tu contraseña ni se guarda ni se cifra: se hashea con una función lenta y salada. Esa frase condensa veinte años de lecciones aprendidas a base de filtraciones millonarias. Este artículo recorre el viaje completo de una contraseña dentro del servidor —y por qué cada etapa existe—, conocimiento útil tanto si construyes sistemas como si quieres saber cuáles merecen tu confianza.
Por qué jamás se guarda la contraseña
La pregunta que responde todo: ¿qué pasa si me roban la base de datos? Con la contraseña guardada tal cual (texto plano), el atacante tiene acceso inmediato a todas las cuentas — y a las cuentas de otros servicios donde tus usuarios repiten contraseñas. Cifrada con clave: mejor, pero la clave vive cerca de los datos y un atacante con acceso al sistema suele tenerla también.
El modelo correcto invierte la lógica: guardar algo que no permite iniciar sesión pero sí verificarla. Un hash criptográfico cumple exactamente eso: determinista (misma entrada, mismo resultado), irreversible (no hay operación inversa) y con efecto avalancha (un bit cambiado transforma toda la salida).
El problema del hash rápido y la solución del salt
Un detalle histórico costó carísimo: SHA-256 es rápida por diseño — procesa millones de hashes por segundo en GPU. Para verificar integridad es perfecta; para proteger contraseñas es desastrosa: el atacante roba la base de datos y prueba diccionarios enteros a velocidad industrial (las rainbow tables: hashes precalculados de millones de contraseñas comunes).
Primera defensa — salt: un valor aleatorio único por usuario, mezclado con la contraseña antes de hashear:
hash = H(salt + contraseña)
guardar: salt + hash ← el salt no es secreto, viaja junto
Con salt, dos usuarios con la misma contraseña producen hashes distintos, y las rainbow tables precalculadas quedan inútiles: regenerarlas exigiría un cálculo individual por cada salt. Es la muerte de la precomputación masiva.
Pero queda el ataque directo: probar candidatos contra UN usuario concreto sigue corriendo a velocidad GPU. Ahí entra la segunda defensa.
Funciones lentas a propósito
Las funciones de derivación para contraseñas hacen deliberadamente lo contrario que SHA-256: tardar. No milisegundos — decenas o cientos de milisegundos por intento. La diferencia es asimétrica: para ti, que haces login una vez, 100 ms son imperceptibles; para el atacante probando 10.000 millones de candidatos, multiplicar el coste unitario por 100.000 convierte semanas en milenios.
Los tres estándares vivos:
bcrypt (1999): el veterano. Factor de coste configurable (cada +1 duplica el tiempo), salt integrado, décadas de análisis. Sigue siendo aceptable hoy con coste ≥10-12.
// Node.js con bcryptjs
const hash = await bcrypt.hash(contrasena, 12); // ~250 ms
await bcrypt.compare(intento, hash); // true/false
scrypt (2009): añade resistencia a memoria además de CPU — castiga especialmente a GPUs y ASICs, que tienen cómputo sobrado pero memoria limitada.
Argon2id (2015, ganador de la Password Hashing Competition): el estándar moderno recomendado. Parametrizable en tiempo, memoria Y paralelismo. Configuración típica actual: 19 MiB de memoria, 2 iteraciones, paralelismo 1 — ajustables según hardware del servidor.
// Node.js con argon2 nativo
const hash = await argon2.hash(contrasena, { type: argon2.argon2id });
Regla de elección en 2026: Argon2id si tu plataforma lo soporta; bcrypt perfectamente defendible; scrypt correcto. Nunca MD5, nunca SHA-1, nunca SHA-256 sola para contraseñas.
Pepper: la capa opcional
Un pepper es un valor secreto global (no por usuario) añadido al proceso, guardado FUERA de la base de datos — variable de entorno, KMS, HSM:
hash = Argon2id(pepper + salt + contraseña)
Su gracia: si el atacante extrae solo la base de datos (dump SQL filtrado, backup perdido), los hashes son inverificables sin el pepper que no estaba allí. Limitación honesta: si compromete el sistema completo, también obtiene el pepper. Defensa en profundidad, no escudo absoluto.
Los errores clásicos (todos vistos en producción)
Hashear con MD5 "porque funciona". Saltar el salt ("ya hasheo, suficiente"). Truncar o mal convertir el resultado (mayúsculas en base64 rompiendo verificaciones). Limitar la longitud de contraseña a 8 "por compatibilidad" — con Argon2 puedes aceptar 128 sin coste. Y el peor: inventar un esquema propio. La criptografía casera pierde siempre; usa librerías mantenidas con defaults seguros.
También importa el flujo alrededor: rate limiting en login (el hash lento frena el ataque offline, no el online — para eso limita intentos), mensajes genéricos de error ("usuario o contraseña incorrectos", nunca revelar cuál falló), y reset por token de un solo uso con expiración corta.
Comprueba hashes tú mismo
Si quieres ver el efecto avalancha en vivo o calcular SHA-256 sobre textos para entender qué es un hash fuera del contexto de contraseñas, nuestro generador de hashes lo hace localmente. Para evaluar la fortaleza de las contraseñas antes de que lleguen al hash, la guía de entropía explica cómo se mide en bits, y si diseñas el flujo de registro completo, cómo crear una contraseña segura cubre el lado del usuario.
Preguntas frecuentes
¿Cada cuánto debo rehashear? Al iniciar sesión puedes re-hashear transparentemente si los parámetros subieron (bcrypt lo detecta por el coste almacenado). Migraciones masivas de algoritmo requieren reset de contraseña o doble hash transitorio.
¿El hash lento puede tirar mi servidor con muchos logins? Es un coste real: Argon2id consume memoria por intento. Limita intentos concurrentes y ajusta parámetros a tu hardware — mejor 100 ms seguros que 10 ms frágiles.
¿Puedo recuperar una contraseña de su hash? No, y ese es el punto. Solo se puede restablecer (generando nueva). Cualquier servicio que pueda enviarte "tu" contraseña la guarda en texto plano o cifrada reversible: huye.
Calcula hashes SHA-256 al instante con nuestro generador de hashes online, gratis y directamente en tu navegador.