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

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.

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.

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 a memoria. Requiere una cantidad configurable de RAM durante el cálculo. Esto hace que los ataques paralelos a hardware especializado, como ASICs o FPGAs, sean significativamente más costosos. Un mayor consumo de memoria implica que un atacante puede realizar menos intentos de descifrado simultáneos.

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, ya que 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 robustez 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. El NIST recomienda al menos 600 000 iteraciones con HMAC-SHA-256.

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 al menos 19 MiB de memoria, 2 iteraciones y 1 grado de paralelismo. 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.