Funciones de derivación de claves: PBKDF2, bcrypt y Argon2

Almacenar contraseñas requiere una clase especial de función criptográfica denominada función de hash de contraseñas (PHF) o función de derivación de claves (KDF). Los hashes criptográficos habituales, como SHA-256, están diseñados para ser rápidos: una GPU moderna puede calcular miles de millones de hashes SHA-256 por segundo. Esta velocidad es catastrófica para el almacenamiento de contraseñas: un atacante que robe una base de datos de hashes puede probar miles de millones de contraseñas por segundo. Las KDF para contraseñas son intencionadamente lentas y se pueden ajustar para que los ataques de fuerza bruta resulten inviables desde el punto de vista computacional, a la vez que permiten iniciar sesión legítimamente en cuestión de milisegundos.

Antes de que existieran KDF específicas para contraseñas, los atacantes utilizaban tablas rainbow: correspondencias precalculadas entre valores hash y contraseñas en texto claro. Un salt es un valor aleatorio único para cada usuario que se antepone o se añade a la contraseña antes de aplicar el hash, haciendo que cada hash sea único incluso cuando las contraseñas son idénticas. Los salts se almacenan junto al hash en la base de datos; no son secretos, solo deben ser aleatorios. Un salt adecuado debe tener al menos 16 bytes, generarse mediante un generador de números aleatorios criptográficamente seguro y almacenarse por usuario (nunca reutilizarse entre cuentas).

PBKDF2 (Password-Based Key Derivation Function 2) está definido en la RFC 8018 y aprobado por NIST. Funciona aplicando repetidamente una función HMAC (normalmente HMAC-SHA-256) a la contraseña y al salt, durante un número configurable de iteraciones. El número de iteraciones es el factor de trabajo; a partir de 2023, NIST recomienda al menos 600.000 iteraciones de PBKDF2-HMAC-SHA256. PBKDF2 se utiliza ampliamente (Django, iOS Keychain, WPA2-PSK), pero tiene una debilidad: puede implementarse de forma eficiente en GPU, por lo que ofrece menos resistencia frente a GPU que otras alternativas.

bcrypt fue diseñado por Niels Provos y David Mazieres en 1999 y sigue utilizándose ampliamente. Su principal innovación es un factor de coste (parámetro de rondas), en el que cada incremento duplica el tiempo de cálculo. bcrypt utiliza un cifrado Blowfish modificado con una configuración de clave Eksblowfish que requiere un uso intensivo de CPU y memoria, lo que dificulta considerablemente su aceleración en GPU frente a PBKDF2. bcrypt también limita la entrada de contraseña a 72 bytes (las contraseñas más largas se truncan), por lo que en algunas implementaciones es necesario aplicar SHA-256 primero a las contraseñas largas.

Argon2 ganó la Password Hashing Competition en 2015 y es la recomendación actual de OWASP. Tiene tres variantes: Argon2d (más rápida, vulnerable a canales laterales y adecuada principalmente para criptomonedas), Argon2i (en tiempo constante y adecuada para aplicar hash a contraseñas) y Argon2id (híbrida y recomendada para la mayoría de los usos). Argon2id se puede configurar en tres dimensiones: coste temporal (iteraciones), coste de memoria (RAM requerida) y paralelismo (hilos). Los elevados requisitos de memoria dificultan enormemente la paralelización en GPU y la hacen completamente inviable en ASIC.

Las GPU tienen miles de núcleos, pero poca memoria por núcleo; destacan al paralelizar cálculos sencillos que requieren poca memoria. Las funciones resistentes a memoria, como Argon2 y scrypt, requieren grandes cantidades de RAM para cada cálculo de hash. Si un atacante desea ejecutar 10.000 cálculos de Argon2id en paralelo y cada uno requiere 64 MB de memoria, necesitará 640 GB de RAM de GPU, una cantidad muy superior a la disponible en cualquier clúster de GPU. Esta propiedad, denominada resistencia a memoria, obliga a los atacantes a realizar cálculos secuenciales lentos o a invertir en hardware extraordinariamente costoso, lo que hace que los ataques dejen de ser rentables.

El factor de trabajo adecuado depende de su hardware y de la latencia aceptable. El objetivo general es de 100-300 ms en el hardware de producción del servidor por cada autenticación. A medida que mejora el hardware, debe aumentar el factor de trabajo; por eso bcrypt y Argon2 almacenan los parámetros junto al hash, lo que permite realizar actualizaciones transparentes: en el siguiente inicio de sesión, se verifica la contraseña y después se vuelve a aplicar el hash con los nuevos parámetros, más elevados. OWASP mantiene los parámetros mínimos recomendados actuales para PBKDF2, bcrypt y Argon2id, que deben revisarse anualmente.

scrypt, diseñado por Colin Percival en 2009, fue la primera KDF resistente a memoria adoptada ampliamente y se utiliza en Litecoin y en muchos gestores de contraseñas. scrypt se parametriza mediante N (coste de CPU/memoria), r (tamaño de bloque) y p (factor de paralelización). Al igual que Argon2, los valores altos de N requieren grandes cantidades de RAM por cálculo. scrypt se considera seguro, pero generalmente se prefiere Argon2id para aplicaciones nuevas porque ganó la PHC y ha recibido un análisis criptográfico más exhaustivo. Ambas son opciones aceptables.

Hay varios enfoques de hash que nunca deben utilizarse para contraseñas: MD5 (roto; el hardware de consumo puede calcular miles de millones de hashes por segundo), SHA-1 (presenta el mismo problema), SHA-256 sin salt (es rápido y las tablas rainbow lo vuelven trivial) y el cifrado simple (es reversible, por lo que el robo de la clave equivale a robar todas las contraseñas). Filtraciones históricas como la de LinkedIn (2012) utilizaron SHA-1 sin salt y expusieron 117 millones de contraseñas, que se descifraron en cuestión de días. Adobe (2013) cifró las contraseñas en lugar de aplicarles un hash; este malentendido fundamental dejó expuestas 153 millones de cuentas. Estos incidentes forman parte del contenido del examen Security+.

Las KDF también se utilizan para derivar claves de cifrado a partir de contraseñas, en lugar de almacenar hashes de contraseñas. Cuando un usuario establece una contraseña maestra para una bóveda cifrada, la aplicación utiliza una KDF para derivar la clave de cifrado AES-256 real a partir de esa contraseña. Por eso los gestores de contraseñas pueden descifrar la bóveda localmente: ejecutan la KDF con su contraseña maestra para reconstruir la clave de cifrado, que nunca sale de su dispositivo. HKDF (HMAC-based Key Derivation Function) es el estándar para derivar varias claves a partir de un único secreto con alta entropía, y se utiliza en TLS 1.3 para derivar las claves del protocolo de enlace y de la aplicación.

Los ataques de credential stuffing reutilizan pares de nombre de usuario y contraseña robados en una filtración para intentar acceder a otros servicios. Las KDF sólidas reducen la ventana disponible para el cracking sin conexión después de una filtración: si el atacante debe invertir 300 ms por intento en lugar de microsegundos, crackear una contraseña aleatoria de 10 caracteres se vuelve computacionalmente inviable. Sin embargo, las KDF no protegen contra la reutilización de contraseñas entre sitios; para eso, los usuarios deben utilizar contraseñas únicas. La combinación de contraseñas únicas + almacenamiento con Argon2id + MFA hace que los ataques basados en credenciales sean prácticamente ineficaces.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que: las KDF de contraseñas son intencionadamente lentas y tienen factores de trabajo configurables para hacer que los ataques de fuerza bruta sin conexión sean computacionalmente inviables; las funciones con elevado consumo de memoria, como Argon2id y scrypt, frustran la paralelización mediante GPU al requerir una gran cantidad de RAM por cálculo; y MD5, SHA-1 y los hashes sin salt son completamente inadecuados para almacenar contraseñas, como han demostrado varias filtraciones de gran repercusión. A continuación, exploraremos la criptografía poscuántica y los algoritmos seleccionados por NIST para sustituir RSA y ECC.