PBKDF2 Explicado: La Función de Derivación de Clave Basada en Contraseña que Protege tu Cofre

TL;DR

PBKDF2 (Password-Based Key Derivation Function 2) es un algoritmo de estiramiento de clave definido en RFC 2898. Aplica una función pseudoaleatoria (normalmente HMAC-SHA256) muchas veces a una contraseña y una sal, produciendo una clave derivada. El recuento de iteraciones hace que los ataques de fuerza bruta sean exponencialmente más costosos. OWASP recomienda 600 000 iteraciones para SHA-256 a partir de 2026. AppVault utiliza PBKDF2 con 600 000 iteraciones, una sal de 128 bits por instalación y envuelve la salida con una clave del Secure Enclave para una protección ligada al hardware.

Cada vez que desbloqueas tu iPhone, introduces una contraseña en un sitio web o abres un cofre de archivos, un software convierte tu secreto en una clave criptográfica. Esa transformación no es un hash simple. Es una función cuidadosamente diseñada que hace que los ataques de fuerza bruta sean costosos. La función más implementada de este tipo es PBKDF2.

PBKDF2 significa Password-Based Key Derivation Function 2 (Función de Derivación de Clave Basada en Contraseña 2). Está definida en RFC 2898 (PKCS #5 v2.0) y ha sido un estándar recomendado por NIST durante más de dos décadas. Toma una contraseña, una sal, un recuento de iteraciones y una longitud de clave deseada, y produce una clave derivada que puede usarse para cifrado, autenticación u otras operaciones criptográficas.

Este artículo explica cómo funciona PBKDF2, por qué el hash directo es insuficiente, el papel de las sales y los recuentos de iteraciones, la recomendación OWASP 2026 de 600 000 iteraciones para SHA-256, y cómo se compara PBKDF2 con alternativas modernas como Argon2id, bcrypt y scrypt. También describe cómo AppVault utiliza PBKDF2 como parte de su pila de cifrado.

Por qué Falla el Hash Directo

Si tomas una contraseña y calculas su hash SHA-256, obtienes un valor de 256 bits. Ese valor puede usarse como clave. El problema es la velocidad. Una GPU moderna puede calcular miles de millones de hashes SHA-256 por segundo. Un atacante con una sola GPU de consumo puede probar todas las contraseñas de 8 caracteres en minúsculas en pocos minutos.

El hash directo tampoco tiene protección incorporada contra la precomputación. Sin una sal, la misma contraseña siempre produce el mismo hash. Los atacantes pueden construir tablas rainbow — cadenas de hash precomputadas — y buscar el hash para recuperar la contraseña al instante.

PBKDF2 resuelve ambos problemas. Repite el hash miles de veces, haciendo que cada intento sea computacionalmente costoso. Requiere una sal, por lo que contraseñas idénticas producen claves diferentes. La combinación de recuento de iteraciones y sal convierte un hash rápido en una derivación lenta y única.

Cómo Funciona PBKDF2

PBKDF2 se basa en una función pseudoaleatoria (PRF), típicamente HMAC-SHA256 o HMAC-SHA1. El algoritmo funciona de la siguiente manera:

1. La contraseña y la sal se combinan.
2. La PRF se aplica a la sal concatenada con un contador de bloque (para longitudes de clave mayores que la salida de la PRF).
3. La salida se combina mediante XOR con el resultado de la iteración anterior (para la primera iteración, el resultado anterior es la propia salida de la PRF).
4. Los pasos 2 y 3 se repiten el número de iteraciones especificado.
5. La salida final es la clave derivada.

El recuento de iteraciones es el parámetro crítico. Cada iteración añade una cantidad fija de trabajo. Si un atacante quiere probar una contraseña, debe ejecutar toda la cadena de iteraciones. Con 600 000 iteraciones, un solo intento de contraseña toma aproximadamente 600 000 veces más que un solo hash SHA-256.

La sal debe ser única por usuario o por instancia. Una sal de 128 bits (16 bytes) es el mínimo recomendado por NIST. La sal se almacena junto con la clave derivada (o en los metadatos del cofre) para que la derivación pueda repetirse durante la autenticación.

La Recomendación OWASP 2026

OWASP publica una Hoja de Referencia sobre Almacenamiento de Contraseñas que proporciona recomendaciones de recuento de iteraciones para varias funciones de derivación de clave. A partir de 2026, la recomendación para PBKDF2-HMAC-SHA256 es 600 000 iteraciones. Para PBKDF2-HMAC-SHA1, la recomendación es 1 300 000 iteraciones, porque SHA1 produce una salida de 160 bits y es ligeramente más rápida por iteración.

Estos números no son arbitrarios. Están calibrados para que un solo intento de contraseña tome aproximadamente 0,1 segundos en hardware de consumo moderno. Ese retraso es imperceptible para un usuario legítimo, pero hace que los ataques de fuerza bruta sean prohibitivamente lentos. Un atacante con un clúster de 100 GPUs solo puede intentar unos pocos cientos de contraseñas por segundo, no miles de millones.

El recuento de iteraciones debe aumentarse con el tiempo a medida que el hardware mejora. OWASP actualiza sus recomendaciones periódicamente. AppVault utiliza 600 000 iteraciones para PBKDF2-HMAC-SHA256, coincidiendo con la guía de 2026.

Compensaciones del Recuento de Iteraciones

Recuentos de iteraciones más altos hacen que los ataques de fuerza bruta sean más difíciles, pero también aumentan el tiempo necesario para derivar la clave en el dispositivo legítimo. En un iPhone, 600 000 iteraciones de HMAC-SHA256 toman aproximadamente 0,2 segundos. Eso es aceptable para un desbloqueo del cofre. Pero si el recuento de iteraciones se elevara a 10 millones, el tiempo de desbloqueo superaría los 3 segundos, degradando la experiencia del usuario.

También hay una compensación en el consumo de energía. Los dispositivos móviles tienen batería limitada. Cada iteración consume ciclos de CPU. AppVault equilibra seguridad y usabilidad eligiendo un recuento de iteraciones que proporciona una protección sólida sin agotar la batería ni frustrar al usuario.

Otra compensación es el uso de memoria. PBKDF2 no es intensivo en memoria. Utiliza una cantidad pequeña y fija de memoria independientemente del recuento de iteraciones. Esto lo hace vulnerable a ataques de GPU y ASIC que pueden paralelizar muchos intentos de contraseña. Las funciones intensivas en memoria como Argon2id y scrypt requieren una gran cantidad de memoria por intento, lo que hace que los ataques paralelos sean mucho más costosos. PBKDF2 compensa su falta de intensidad de memoria con un alto recuento de iteraciones y, en el caso de AppVault, con vinculación al hardware mediante el Secure Enclave.

PBKDF2 vs. Argon2id, bcrypt y scrypt

PBKDF2 no es la única función de derivación de clave basada en contraseña. Otras tres funciones se usan comúnmente: bcrypt, scrypt y Argon2id. Cada una tiene diferentes objetivos de diseño y propiedades de seguridad.

Bcrypt fue diseñado en 1999 y utiliza un programa de clave basado en Blowfish. Es resistente a ataques de GPU porque requiere una cantidad fija de memoria (4 KB) y tiene un factor de coste incorporado. Bcrypt está ampliamente soportado pero tiene una longitud máxima de contraseña de 72 bytes. No se recomienda para sistemas nuevos porque es más lento en CPU que Argon2id y no admite uso variable de memoria.

Scrypt fue diseñado en 2009 y es intensivo en memoria. Requiere una gran cantidad de memoria (configurable) y tiempo de CPU. Scrypt es resistente a ataques de ASIC y GPU porque el ancho de banda de la memoria se convierte en el cuello de botella. Se utiliza en algunas carteras de criptomonedas y herramientas de cifrado de archivos. Sin embargo, scrypt está menos implementado que PBKDF2 y no tiene un estándar NIST.

Argon2id es el ganador del Password Hashing Competition de 2015. Es el KDF más moderno y recomendado para sistemas nuevos. Argon2id es intensivo en memoria, intensivo en CPU y resistente a ataques de canal lateral. Tiene tres variantes: Argon2d (dependiente de datos), Argon2i (independiente de datos) y Argon2id (híbrido). OWASP recomienda Argon2id para aplicaciones nuevas.

PBKDF2 sigue siendo el KDF más implementado porque es simple, estandarizado y está disponible en todas las bibliotecas criptográficas importantes. Es el predeterminado en CommonCrypto de iOS, KeyStore de Android y muchos sistemas empresariales. Para aplicaciones que no pueden usar Argon2id debido a limitaciones de plataforma o requisitos de compatibilidad, PBKDF2 con un alto recuento de iteraciones y vinculación al hardware es una opción sólida.

Cómo AppVault Usa PBKDF2

AppVault utiliza PBKDF2-HMAC-SHA256 con 600 000 iteraciones y una sal de 128 bits por instalación. La sal se genera durante la configuración inicial y se almacena en el Secure Enclave del dispositivo. La clave derivada luego se envuelve con una clave generada dentro del Secure Enclave, que nunca sale del chip. Esto proporciona una protección ligada al hardware: incluso si un atacante extrae la salida de PBKDF2, no puede usarla sin la clave del Secure Enclave.

El Bloqueo de Patrón en la cuadrícula 5×5 de AppVault se convierte en una cadena de contraseña. Esa cadena se introduce en PBKDF2 junto con la sal. La clave derivada resultante se usa para cifrar el catálogo del cofre y cada archivo individualmente usando AES-256-GCM con un nonce único de 96 bits por archivo.

La arquitectura de conocimiento cero de AppVault significa que la contraseña nunca sale del dispositivo. La derivación PBKDF2 ocurre completamente en el iPhone. Los servidores de AppVault (que no existen) nunca ven la contraseña ni la clave derivada. El modelo de amenazas asume que un atacante puede obtener acceso físico al dispositivo, pero sin la contraseña y la clave del Secure Enclave, el cofre permanece sellado.

Otras aplicaciones de cofres en esta categoría toman diferentes enfoques para la derivación de clave. Los desgloses arquitectónicos — recuentos de iteraciones, manejo de sales, custodia de clave con vinculación al hardware versus solo software — se encuentran en las páginas de comparación dedicadas: AppVault vs Vaultaire y AppVault vs Keepsafe. AppVault publica su pila criptográfica completa con citas de fuentes primarias, que es el requisito previo para cualquier verificación independiente.

Consideraciones Prácticas para Desarrolladores

Si estás implementando PBKDF2, sigue estas pautas:

• Usa HMAC-SHA256 como PRF. SHA1 es aceptable pero requiere más iteraciones.
• Genera una sal aleatoria de al menos 16 bytes por usuario o por instancia.
• Establece el recuento de iteraciones en la recomendación actual de OWASP (600 000 para SHA-256 a partir de 2026).
• Almacena la sal y el recuento de iteraciones junto con la clave derivada (o los metadatos del cofre) para que la derivación pueda repetirse.
• Considera la vinculación al hardware (ej. Secure Enclave, TPM) para proteger la clave derivada incluso si el dispositivo se ve comprometido.
• No uses PBKDF2 para almacenamiento de contraseñas en sistemas de autenticación si Argon2id está disponible. PBKDF2 es más adecuado para la derivación de clave en escenarios de cifrado local.

Conclusión

PBKDF2 es una función de derivación de clave probada en batalla que ha protegido contraseñas y claves de cifrado durante más de dos décadas. No es el KDF más moderno, pero es el más ampliamente soportado y, cuando se configura correctamente, proporciona una protección sólida contra ataques de fuerza bruta. La recomendación OWASP 2026 de 600 000 iteraciones para SHA-256 asegura que cada intento de contraseña sea lo suficientemente costoso para disuadir a los atacantes.

AppVault utiliza PBKDF2 con 600 000 iteraciones, una sal por instalación y envoltura del Secure Enclave para proteger tus archivos. La combinación de un alto recuento de iteraciones y vinculación al hardware hace que el cofre sea resistente a ataques tanto por software como físicos. Sin restablecimiento de contraseña, sin puerta trasera, sin recuperación de clave en el servidor. La seguridad de tus datos depende de la fortaleza de tu contraseña y de la integridad de la derivación PBKDF2.

Para una mirada más profunda a cómo AppVault implementa su criptografía, consulta la visión general del cifrado y el modelo de amenazas.