Almacenamiento de contraseñas correcto: Hashing, Salting y bcrypt frente a Argon2 frente a PBKDF2

Respuesta rápida: El almacenamiento seguro de contraseñas implica aplicar una función hash a cada contraseña con una clave aleatoria única mediante un algoritmo lento y exigente en memoria, sin almacenarla nunca en texto plano ni mediante cifrado reversible. Para sistemas nuevos, utilice Argon2id con los parámetros actuales de OWASP; para sistemas heredados, mantenga bcrypt con un factor de coste de al menos 12; utilice PBKDF2 solo cuando la validación FIPS lo requiera. La acción recomendada: audite hoy mismo su algoritmo y parámetros de hash actuales, ya que esta es una decisión de implementación criptográfica que puede resultar difícil de tomar sin darse cuenta.

Publicado: junio de 2026 | Actualizado: agosto de 2026 | Revisado por el equipo asesor de criptografía de Encryption Consulting

La mayoría de las personas nunca piensan en cómo se almacenan sus contraseñas después de registrarse. Simplemente confían en que las empresas lo gestionan correctamente. Pero esa confianza no siempre está justificada. El almacenamiento de contraseñas es uno de los aspectos más problemáticos en la seguridad de las aplicaciones, y las consecuencias de un mal manejo son graves.

Cada año, las filtraciones exponen millones de credenciales de usuario. En muchos casos, estas credenciales se almacenaban de forma que resultaba fácil de descifrar. Sin sal, con hashes débiles , a veces incluso en texto plano. No se trata de casos aislados, sino de fallos recurrentes que afectan a usuarios reales.

Esta publicación explica cómo funciona el almacenamiento seguro de contraseñas, desde los conceptos básicos de hash y salting hasta una comparación práctica de bcrypt, Argon2 y PBKDF2. Si estás diseñando o revisando un sistema de autenticación, este es el punto de partida.

Por qué es importante el almacenamiento seguro de contraseñas

Cuando los atacantes roban una base de datos de contraseñas, no obtienen instantáneamente todas las contraseñas. Lo que obtienen es un conjunto de representaciones almacenadas. Si estas se crearon correctamente, los datos les resultan prácticamente inútiles. De lo contrario, pueden recuperar miles de contraseñas reales en cuestión de horas.

El riesgo no se limita a una sola cuenta. Las personas reutilizan contraseñas en distintos servicios. Una contraseña descifrada en una aplicación de bajo riesgo puede desbloquear cuentas de correo electrónico, accesos bancarios o sistemas corporativos. Esta reacción en cadena explica por qué incluso las aplicaciones pequeñas son responsables de la seguridad general de sus usuarios.

También existe una dimensión de cumplimiento normativo. Marcos como NIST SP 800-63B, GDPR y PCI-DSS establecen expectativas sobre cómo se protegen los datos de autenticación. Un almacenamiento deficiente de contraseñas constituye tanto un fallo técnico como normativo, con las consiguientes sanciones y daños a la reputación.

¿En qué supuestos de seguridad se basa este análisis?

Cada recomendación de esta publicación parte de la premisa de un modelo de amenaza específico: un atacante que ha obtenido la base de datos de contraseñas sin conexión, mediante una brecha de seguridad, un empleado interno o una copia de seguridad mal configurada, y que puede realizar intentos de adivinación ilimitados sin limitaciones de velocidad, bloqueos de cuenta ni monitorización. Esta es la premisa correcta a tener en cuenta al diseñar, ya que la limitación de velocidad en línea es un control que puede fallar o eludirse, mientras que la resistencia al descifrado sin conexión es una propiedad de los propios datos almacenados.

El análisis también supone que el atacante tiene acceso a hardware GPU comercial, no a una granja de ASIC de un estado nación; supone que las contraseñas provienen del comportamiento real del usuario, lo que significa que una fracción significativa son cortas, basadas en diccionarios o reutilizadas, no uniformemente aleatorias; y supone que el salt es público (almacenado junto con el hash, como debería ser), por lo que el costo del algoritmo, no el secreto del salt, es lo que debe resistir el ataque.

Comprender el hashing y el salting de contraseñas

Una función hash criptográfica toma una contraseña como entrada y produce una salida de longitud fija llamada hash o resumen. La característica clave es que este proceso solo funciona en una dirección. No se puede revertir un hash para recuperar la contraseña original. Por lo tanto, en lugar de almacenar las contraseñas directamente, los sistemas almacenan sus hashes. Al iniciar sesión, la contraseña ingresada se somete a un proceso de hash y se compara con el hash almacenado.

Esto suena bastante seguro. Sin embargo, las funciones hash de propósito general como MD5 y SHA-256 se diseñaron para la velocidad, no para contraseñas. Una GPU moderna puede calcular miles de millones de hashes SHA-256 por segundo. Esa velocidad representa una ventaja para los atacantes que realizan ataques de fuerza bruta o de diccionario.

El salting de contraseñas aborda un ataque específico: las tablas arcoíris. Una tabla arcoíris es una búsqueda precalculada de hashes para contraseñas comunes. Un atacante puede tomar un hash robado y consultarlo en segundos sin realizar ningún cálculo real.

Una sal es una cadena única generada aleatoriamente que se añade a cada contraseña antes de aplicarle el hash. Aunque dos usuarios tengan la misma contraseña, sus sales generan hashes completamente diferentes. Esto inutiliza las tablas arcoíris y obliga a los atacantes a descifrar cada hash individualmente.

Las sales no son secretas. Se almacenan junto con el hash. Su valor reside en su singularidad y aleatoriedad, no en su ocultación. El uso de sales no es cifrado. Es una forma de contrarrestar los ataques de precomputación.

Un ejemplo práctico: por qué la elección del algoritmo lo cambia todo.

Las cifras hacen que la diferencia sea tangible. Consideremos una contraseña de 8 caracteres compuesta únicamente por letras minúsculas: aproximadamente 208 mil millones de combinaciones posibles. Una sola GPU moderna para consumidores puede calcular más de 10 mil millones de hashes SHA-256 sin sal por segundo, lo que significa que el espacio de claves se agota en menos de un minuto, con o sin sal, ya que el uso de sal detiene las tablas arcoíris precalculadas, pero no ralentiza un intento de fuerza bruta por hash contra hashes rápidos.

Si se ejecuta el mismo ataque contra una contraseña almacenada con Argon2id en la configuración base recomendada por OWASP (46 MiB de memoria, 1 iteración, 1 grado de paralelismo), el panorama cambia. La misma GPU que calculaba 10 mil millones de hashes SHA-256 por segundo ahora se ve limitada por el ancho de banda de la memoria, no por la capacidad de procesamiento, y normalmente solo puede gestionar unos pocos miles de hashes Argon2id por segundo con ese coste de memoria. Las mismas 208 mil millones de combinaciones que tardaban menos de un minuto contra SHA-256 sin procesar ahora requieren meses o incluso años de uso continuo de la GPU, y escalar el ataque exige disponer de suficiente hardware equivalente en memoria para ejecutar muchas instancias en paralelo, lo que resulta mucho más caro que añadir núcleos de GPU. Esta diferencia, y no una diferencia en la potencia matemática, es la razón principal de la existencia de algoritmos que requieren mucha memoria.

bcrypt explicado: fortalezas, debilidades y cuándo usarlo

bcrypt se creó en 1999 específicamente para el cifrado de contraseñas. Incluye la adición automática de sal y un factor de coste configurable, también llamado factor de trabajo, que controla el coste computacional del cifrado. Al aumentar el factor de coste, aumenta el tiempo necesario por cada hash, lo que dificulta a los atacantes que intentan descifrar contraseñas a gran escala.

Fortalezas:

• Sistema de salazón incorporado: bcrypt genera y almacena automáticamente un valor aleatorio único (salt) para cada contraseña, eliminando una fuente común de errores por parte de los desarrolladores.
• Factor de coste adaptativo: A medida que el hardware mejora, se puede aumentar el factor de trabajo para mantener la resistencia contra los ataques.
• Probado en batalla: Tras más de 25 años de análisis exhaustivo, no se han encontrado vulnerabilidades fundamentales.
• Amplio apoyo: Disponible en prácticamente todos los principales lenguajes y frameworks de programación.

Limitaciones:

• Límite de 72 caracteres: bcrypt trunca las entradas que superan los 72 bytes. Esto puede ser un problema para contraseñas largas si no se maneja correctamente.
• Sin dureza de memoria: bcrypt no requiere mucha memoria RAM, lo que lo hace más vulnerable a ataques de hardware altamente paralelos en comparación con opciones más recientes.

Argon2 vs. PBKDF2 vs. bcrypt: Diferencias clave que importan

No todos los algoritmos de cifrado de contraseñas ofrecen el mismo nivel de protección. A continuación, se comparan las tres opciones principales según los factores más importantes.

Elemento	bcrypt	argonxnumx	PBKDF2
Dureza de la memoria	No es difícil de recordar	Uso de RAM configurable y con requisitos de memoria exigentes.	No es difícil de recordar
Salado incorporado	si, automatico	si, automatico	No, debe manejarse manualmente.
Control de paralelismo	No se admite	Con soporte a través de Argon2id	No se admite
Límite de longitud de la contraseña	Limitado a 72 bytes	No hay límite	No hay límite
NIST recomendado	No aparece en la lista SP 800-63B.	Sí:	Sí:
Resistencia de la GPU	Moderado	Alto	Bajo a moderado
Madurez	Más de 25	Disponible desde 2015	Disponible desde 2000

Argon2: El estándar moderno

Argon2 ganó el concurso de hash de contraseñas en 2015 y está recomendado por el NIST en la norma SP 800-63B. Se presenta en tres variantes: Argon2d, que resiste ataques de GPU; Argon2i, que resiste ataques de canal lateral; y Argon2id, que combina ambas características y es la opción recomendada para la mayoría de los escenarios de almacenamiento de contraseñas.

Lo que distingue a Argon2 es su robustez en cuanto al uso de memoria. Requiere una cantidad configurable de RAM durante el cálculo. Esto hace que los ataques paralelos a hardware especializado, como ASIC o FPGA, sean significativamente más costosos. Un mayor consumo de memoria implica que un atacante puede realizar menos intentos de descifrado simultáneos. La guía actual de OWASP recomienda 46 MiB de memoria con 1 iteración y 1 grado de paralelismo como configuración base preferida, y una configuración más eficiente de 19 MiB con 2 iteraciones como alternativa aceptable para entornos con recursos de memoria limitados.

PBKDF2: La opción de cumplimiento

PBKDF2 es el más antiguo de los tres y se usa ampliamente en entornos con certificación FIPS porque se basa en construcciones HMAC aprobadas . Si su organización requiere el cumplimiento de FIPS 140-2 o 140-3, común en los sectores financieros federales y regulados, es posible que se requiera PBKDF2 con SHA-256 o SHA-512. Carece de resistencia a ataques de memoria, lo que lo convierte en el más débil de los tres frente a ataques de hardware. Para compensarlo, utilice un alto número de iteraciones: la guía actual recomienda al menos 600 000 iteraciones con HMAC-SHA-256, o aproximadamente 210 000 iteraciones con HMAC-SHA-512, que requiere mayor capacidad de cálculo.

¿Cuáles son las limitaciones del almacenamiento de contraseñas basado en funciones hash?

• El hashing protege la base de datos almacenada, pero no hace nada contra el relleno de credenciales, el phishing o la reutilización de contraseñas; una contraseña correctamente cifrada robada a través de una página de phishing se ve comprometida independientemente del algoritmo.
• La robustez del algoritmo no puede compensar las contraseñas débiles de los usuarios; una palabra común protegida por Argon2id aún puede descifrarse en un ataque de diccionario dirigido, solo que más lentamente que con una función hash rápida.
• El aumento del coste de la memoria o del número de iteraciones incrementa el uso de recursos del servidor en el momento del inicio de sesión, por lo que el ajuste de parámetros supone una verdadera compensación en la planificación de la capacidad, no una mejora de seguridad gratuita.
• La migración de una base de usuarios existente a un nuevo algoritmo no puede ocurrir de forma instantánea, ya que los hashes antiguos no se pueden convertir sin la contraseña en texto plano; la migración debe realizarse progresivamente, con cada inicio de sesión exitoso del usuario.

¿Qué algoritmo debería utilizar? Una tabla de decisiones empresariales

Escenario	Algoritmo recomendado	Parámetros sugeridos
Nueva aplicación, sin restricciones heredadas.	Argón2id	46 MiB de memoria, 1 iteración, 1 grado de paralelismo (línea base de OWASP)
El sistema existente ya utiliza bcrypt.	Mantén bcrypt, planifica la migración.	Factor de coste de al menos 12; volver a generar el hash de Argon2id progresivamente en el siguiente inicio de sesión.
Entorno validado según FIPS 140-2/140-3	PBKDF2-HMAC-SHA256	Al menos 600,000 iteraciones, un valor aleatorio único por contraseña.
Objetivo de alto valor / modelo de amenaza elevado	Argon2id, mayor coste de memoria	64 MiB o más, ajustado para una latencia de inicio de sesión aceptable en su hardware.
Con recursos limitados (móviles, integrados, sin servidor)	Argon2id, perfil más delgado	Memoria de 19 MiB, 2 iteraciones, 1 grado de paralelismo

Buenas prácticas para almacenar contraseñas de forma segura

Elegir el algoritmo adecuado es solo el punto de partida. Esto es lo que debería incluir una implementación sólida:

• Elige el algoritmo correcto: Utilice Argon2id para sistemas nuevos. Mantenga bcrypt para sistemas existentes con un factor de coste de 12 o superior. Utilice PBKDF2 solo cuando el cumplimiento normativo lo exija.
• Ajusta tus parámetros: Para Argon2id, OWASP recomienda 46 MiB de memoria, 1 iteración y 1 grado de paralelismo como configuración base preferida. Ajuste estos valores según la capacidad de su servidor y la latencia de inicio de sesión aceptable.
• Utilice siempre sales únicas y aleatorias: Aunque tu biblioteca gestione el salting automáticamente, ten en cuenta que lo hace. Nunca uses valores estáticos ni identificadores secuenciales como salts.
• Aplicar contraseñas seguras: El hashing no sustituye una buena política de contraseñas. Exija longitudes mínimas, rechace las contraseñas que se sabe que han sido comprometidas y admita la autenticación multifactor.
• Almacenamiento de credenciales por separado: Almacene los hashes de las contraseñas en un repositorio dedicado con estrictos controles de acceso. Las aplicaciones solo deben acceder a los datos de las credenciales en el momento de la autenticación.
• Plan de migración de algoritmos: Diseñe su sistema para que vuelva a generar el hash de las credenciales en el siguiente inicio de sesión. Esto le permite actualizar algoritmos o parámetros sin necesidad de restablecer masivamente las contraseñas.

Cómo puede ayudar la consultoría de cifrado

Gestionar correctamente el almacenamiento de contraseñas es una decisión de implementación criptográfica, y como ocurre con la mayoría de las decisiones criptográficas, es fácil cometer errores que no son inmediatamente visibles. Un algoritmo incorrecto, la falta de un valor aleatorio (salt), un número insuficiente de iteraciones o una implementación incompatible con FIPS pueden parecer correctos en apariencia, pero exponer silenciosamente a su organización a graves riesgos. Es ahí donde entran en juego los Servicios de Asesoramiento en Cifrado de Encryption Consulting.

Nuestro equipo ayuda a las organizaciones a evaluar y fortalecer sus implementaciones criptográficas en entornos de nube, locales e híbridos. Ya sea que esté creando un nuevo sistema de autenticación, revisando uno existente o preparándose para una auditoría de cumplimiento según PCI-DSS, NIST SP 800-63B o GDPR, aportamos el conocimiento profundo para evaluar lo que ya está implementado y la experiencia práctica para ayudarle a corregir lo que no funciona correctamente.

Aquí es donde nuestros Servicios de Asesoramiento en Cifrado se aplican directamente a la seguridad del almacenamiento de contraseñas y la autenticación:

Revisión de la implementación criptográfica: Evaluamos su implementación actual de almacenamiento de contraseñas, incluyendo la elección del algoritmo, las prácticas de salting, el ajuste de parámetros y cómo se separan los datos de credenciales y se controla el acceso. Esto le brinda una visión clara de las deficiencias antes de que una brecha de seguridad o una auditoría las revelen.

Selección de algoritmos y planificación de la migración: Pasar de bcrypt a Argon2id, o de una implementación PBKDF2 heredada a una que cumpla con las recomendaciones actuales de NIST sobre el número de iteraciones, requiere una planificación cuidadosa para evitar la interrupción de los flujos de autenticación existentes. Diseñamos rutas de migración que recalculan progresivamente el hash de las credenciales en el siguiente inicio de sesión, sin restablecimientos de contraseña forzados ni interrupciones para el usuario.

Alineación con el cumplimiento de FIPS: Para las organizaciones que operan en entornos financieros federales o regulados donde se requiere la validación FIPS 140-2 o 140-3, le ayudamos a seleccionar y configurar implementaciones de PBKDF2 que cumplan con los requisitos de cumplimiento, compensando al mismo tiempo la menor resistencia del algoritmo al hardware mediante una configuración de parámetros adecuada.

Análisis de brechas de cumplimiento: Marcos como PCI-DSS, GDPR y NIST SP 800-63B establecen expectativas sobre cómo se protegen los datos de autenticación. Comparamos su implementación actual con estos requisitos, identificamos las brechas y elaboramos una hoja de ruta clara para su corrección.

El almacenamiento inadecuado de contraseñas es uno de los fallos de seguridad más comunes y, a la vez, más evitables. Si su organización aún no ha revisado formalmente sus prácticas de gestión de credenciales, ahora es el momento oportuno.

Conclusión

El almacenamiento de contraseñas no es un tema atractivo, pero es fundamental. Las decisiones tomadas en la capa de datos determinan si una brecha de seguridad se convierte en un incidente aislado o en un problema mucho mayor. En última instancia, todos los demás controles de seguridad de una aplicación dependen de cómo se almacenan las credenciales, y dada la frecuencia con la que se reutilizan las contraseñas, el daño causado por una implementación deficiente suele extenderse mucho más allá de la aplicación original.

Lo que complica este ámbito es que las consecuencias rara vez son visibles hasta que algo falla. Una elección de hash débil no ralentiza el rendimiento ni activa alertas. Permanece en producción sin causar problemas hasta que se produce una brecha de seguridad y los atacantes empiezan a descifrar los hashes almacenados. La buena noticia es que las directrices al respecto no son ambiguas. El NIST ha publicado recomendaciones claras y existen bibliotecas consolidadas en todos los lenguajes de programación principales para implementar correctamente estos algoritmos.

El camino a seguir es claro. Utilice Argon2id para nuevas implementaciones. Mantenga bcrypt de forma responsable para sistemas heredados con un factor de costo de al menos 12. Recurra a PBKDF2 solo cuando el cumplimiento lo exija, compensando con un alto número de iteraciones. Siempre use sal, siempre ajuste sus parámetros y planifique las futuras migraciones de algoritmos desde el principio. Considere esto como una práctica continua, no como una configuración única.

Preguntas frecuentes

¿Qué algoritmo de hash de contraseñas debería utilizar un nuevo proyecto?

Argon2id utiliza la configuración base actual de OWASP de 46 MiB de memoria, 1 iteración y 1 grado de paralelismo. Es exigente en cuanto a memoria, cuenta con la recomendación del NIST y no tiene un límite práctico de longitud de contraseña.

¿Sigue siendo seguro usar bcrypt?

Sí, con un factor de coste de al menos 12. bcrypt ha sido sometido a más de 25 años de análisis sin fallos fundamentales, pero carece de robustez en cuanto a memoria, por lo que los nuevos sistemas deberían preferir Argon2id cuando no exista ninguna restricción heredada.

¿Por qué el salado por sí solo no detiene los ataques rápidos de fuerza bruta?

El uso de sal invalida las tablas arcoíris precalculadas al hacer que cada hash sea único, pero no ralentiza el cálculo por hash. Una función hash rápida, equivalente a una sin sal, como SHA-256 sin procesar, aún puede ser descifrada rápidamente por fuerza bruta para cada contraseña, incluso con una sal única; solo un algoritmo deliberadamente lento y que requiere mucha memoria puede resistirlo.

¿Cuándo es PBKDF2 la opción correcta en lugar de Argon2id?

Cuando la validación FIPS 140-2 o 140-3 es un requisito estricto, dado que PBKDF2 se basa en construcciones HMAC aprobadas que Argon2 no utiliza actualmente, compense su falta de robustez ante errores de memoria con al menos 600 000 iteraciones de HMAC-SHA-256.

¿Cómo debería una organización migrar de un algoritmo antiguo a Argon2id?

Progresivamente, en cada inicio de sesión exitoso del usuario: se verifica la contraseña con el hash anterior, se vuelve a generar el hash con Argon2id y se almacena el nuevo hash. Esto evita un restablecimiento masivo forzado de contraseñas mientras se completa la migración gradualmente.

Referencias

• Hoja de referencia para el almacenamiento de contraseñas de OWASP
• Directrices sobre identidad digital NIST SP 800-63B