PBKDF2 Explicado: A Função de Derivação de Chave Baseada em Senha que Protege seu Cofre

TL;DR

PBKDF2 (Password-Based Key Derivation Function 2) é um algoritmo de key stretching definido na RFC 2898. Ele aplica uma função pseudorrandômica (tipicamente HMAC-SHA256) muitas vezes a uma senha e um salt, produzindo uma chave derivada. A contagem de iteração torna os ataques de força bruta exponencialmente mais caros. A OWASP recomenda 600.000 iterações para SHA-256 a partir de 2026. O AppVault usa PBKDF2 com 600.000 iterações, um salt de 128 bits por instalação e envolve a saída com uma chave do Secure Enclave para proteção vinculada ao hardware.

Toda vez que você desbloqueia seu iPhone, insere uma senha em um site ou abre um cofre de arquivos, um software transforma seu segredo em uma chave criptográfica. Essa transformação não é um hash simples. É uma função cuidadosamente projetada para tornar ataques de força bruta caros. A função mais amplamente implantada é o PBKDF2.

PBKDF2 significa Password-Based Key Derivation Function 2 (Função de Derivação de Chave Baseada em Senha 2). Ela é definida na RFC 2898 (PKCS #5 v2.0) e é um padrão recomendado pela NIST há mais de duas décadas. Ela recebe uma senha, um salt, uma contagem de iteração e um comprimento de chave desejado, e produz uma chave derivada que pode ser usada para criptografia, autenticação ou outras operações criptográficas.

Este artigo explica como o PBKDF2 funciona, por que o hashing direto é insuficiente, o papel dos salts e contagens de iteração, a recomendação OWASP 2026 de 600.000 iterações para SHA-256, e como o PBKDF2 se compara a alternativas modernas como Argon2id, bcrypt e scrypt. Também descreve como o AppVault usa PBKDF2 como parte de sua pilha de criptografia.

Por que o Hashing Direto Falha

Se você pegar uma senha e calcular seu hash SHA-256, obtém um valor de 256 bits. Esse valor pode ser usado como chave. O problema é a velocidade. Uma GPU moderna pode calcular bilhões de hashes SHA-256 por segundo. Um atacante com uma única GPU de consumo pode testar todas as senhas minúsculas de 8 caracteres em poucos minutos.

O hashing direto também não tem proteção embutida contra pré-computação. Sem um salt, a mesma senha sempre produz o mesmo hash. Atacantes podem construir tabelas arco-íris — cadeias de hash pré-computadas — e consultar o hash para recuperar a senha instantaneamente.

O PBKDF2 resolve ambos os problemas. Ele repete o hash milhares de vezes, tornando cada tentativa computacionalmente cara. Ele exige um salt, portanto senhas idênticas produzem chaves diferentes. A combinação de contagem de iteração e salt transforma um hash rápido em uma derivação lenta e única.

Como o PBKDF2 Funciona

O PBKDF2 é construído sobre uma função pseudorrandômica (PRF), tipicamente HMAC-SHA256 ou HMAC-SHA1. O algoritmo funciona da seguinte forma:

1. A senha e o salt são combinados.
2. A PRF é aplicada ao salt concatenado com um contador de bloco (para comprimentos de chave maiores que a saída da PRF).
3. A saída é submetida a XOR com o resultado da iteração anterior (para a primeira iteração, o resultado anterior é a própria saída da PRF).
4. As etapas 2-3 são repetidas pelo número especificado de iterações.
5. A saída final é a chave derivada.

A contagem de iteração é o parâmetro crítico. Cada iteração adiciona uma quantidade fixa de trabalho. Se um atacante quiser testar uma senha, ele deve executar toda a cadeia de iterações. Com 600.000 iterações, uma única tentativa de senha leva aproximadamente 600.000 vezes mais tempo que um único hash SHA-256.

O salt deve ser único por usuário ou por instância. Um salt de 128 bits (16 bytes) é o mínimo recomendado pela NIST. O salt é armazenado junto com a chave derivada (ou nos metadados do cofre) para que a derivação possa ser repetida durante a autenticação.

A Recomendação OWASP 2026

A OWASP publica uma Password Storage Cheat Sheet (Folha de Dicas de Armazenamento de Senhas) que fornece recomendações de contagem de iteração para várias funções de derivação de chave. A partir de 2026, a recomendação para PBKDF2-HMAC-SHA256 é 600.000 iterações. Para PBKDF2-HMAC-SHA1, a recomendação é 1.300.000 iterações, porque o SHA1 produz uma saída de 160 bits e é ligeiramente mais rápido por iteração.

Esses números não são arbitrários. Eles são calibrados para que uma única tentativa de senha leve aproximadamente 0,1 segundos em hardware de consumo moderno. Esse atraso é imperceptível para um usuário legítimo, mas torna os ataques de força bruta proibitivamente lentos. Um atacante com um cluster de 100 GPUs só pode tentar algumas centenas de senhas por segundo, não bilhões.

A contagem de iteração deve ser aumentada ao longo do tempo à medida que o hardware melhora. A OWASP atualiza suas recomendações periodicamente. O AppVault usa 600.000 iterações para PBKDF2-HMAC-SHA256, alinhado com a diretriz de 2026.

Compensações da Contagem de Iteração

Contagens de iteração mais altas dificultam ataques de força bruta, mas também aumentam o tempo necessário para derivar a chave no dispositivo legítimo. Em um iPhone, 600.000 iterações de HMAC-SHA256 levam cerca de 0,2 segundos. Isso é aceitável para desbloquear o cofre. Mas se a contagem fosse elevada para 10 milhões, o tempo de desbloqueio excederia 3 segundos, degradando a experiência do usuário.

Há também uma compensação de consumo de energia. Dispositivos móveis têm bateria limitada. Cada iteração consome ciclos de CPU. O AppVault equilibra segurança e usabilidade escolhendo uma contagem de iteração que fornece proteção forte sem drenar a bateria ou frustrar o usuário.

Outra compensação é o uso de memória. PBKDF2 não é memory-hard. Ele usa uma quantidade pequena e fixa de memória, independentemente da contagem de iteração. Isso o torna vulnerável a ataques de GPU e ASIC que podem paralelizar muitas tentativas de senha. Funções memory-hard como Argon2id e scrypt exigem uma grande quantidade de memória por tentativa, tornando ataques paralelos muito mais caros. O PBKDF2 compensa sua falta de memory hardness com uma alta contagem de iteração e, no caso do AppVault, vinculação a hardware via Secure Enclave.

PBKDF2 vs. Argon2id, bcrypt e scrypt

O PBKDF2 não é a única função de derivação de chave baseada em senha. Três outras funções são comumente usadas: bcrypt, scrypt e Argon2id. Cada uma tem diferentes objetivos de design e propriedades de segurança.

Bcrypt foi projetado em 1999 e usa um key schedule baseado em Blowfish. É resistente a ataques de GPU porque exige uma quantidade fixa de memória (4 KB) e tem um fator de custo embutido. Bcrypt é amplamente suportado, mas tem um comprimento máximo de senha de 72 bytes. Não é recomendado para novos sistemas porque é mais lento em CPUs que Argon2id e não suporta uso variável de memória.

Scrypt foi projetado em 2009 e é memory-hard. Exige uma grande quantidade de memória (configurável) e tempo de CPU. Scrypt é resistente a ataques de ASIC e GPU porque a largura de banda da memória se torna o gargalo. É usado em algumas carteiras de criptomoedas e ferramentas de criptografia de arquivos. No entanto, scrypt é menos amplamente implementado que PBKDF2 e não possui padrão NIST.

Argon2id é o vencedor do Password Hashing Competition de 2015. É o KDF mais moderno e recomendado para novos sistemas. Argon2id é memory-hard, CPU-hard e resistente a ataques de canal lateral. Tem três variantes: Argon2d (dependente de dados), Argon2i (independente de dados) e Argon2id (híbrido). A OWASP recomenda Argon2id para novas aplicações.

O PBKDF2 continua sendo o KDF mais amplamente implantado porque é simples, padronizado e disponível em todas as principais bibliotecas criptográficas. É o padrão no CommonCrypto da iOS, no KeyStore do Android e em muitos sistemas empresariais. Para aplicações que não podem usar Argon2id devido a limitações de plataforma ou requisitos de compatibilidade, PBKDF2 com alta contagem de iteração e vinculação a hardware é uma escolha forte.

Como o AppVault Usa PBKDF2

O AppVault usa PBKDF2-HMAC-SHA256 com 600.000 iterações e um salt de 128 bits por instalação. O salt é gerado durante a configuração inicial e armazenado no Secure Enclave do dispositivo. A chave derivada é então envolvida por uma chave gerada dentro do Secure Enclave, que nunca sai do chip. Isso fornece proteção vinculada ao hardware: mesmo que um atacante extraia a saída do PBKDF2, ele não pode usá-la sem a chave do Secure Enclave.

O Bloqueio por Padrão no grid 5×5 do AppVault é convertido em uma string de senha. Essa string é alimentada no PBKDF2 junto com o salt. A chave derivada resultante é usada para criptografar o catálogo do cofre e cada arquivo individualmente usando AES-256-GCM com um nonce único de 96 bits por arquivo.

A arquitetura de conhecimento zero do AppVault significa que a senha nunca sai do dispositivo. A derivação PBKDF2 acontece inteiramente no iPhone. Os servidores do AppVault (que não existem) nunca veem a senha ou a chave derivada. O modelo de ameaça assume que um atacante pode obter acesso físico ao dispositivo, mas sem a senha e a chave do Secure Enclave, o cofre permanece selado.

Outros aplicativos de cofre nesta categoria adotam abordagens diferentes para derivação de chave. As análises arquitetônicas — contagens de iteração, manipulação de salt, vinculação a hardware versus custódia de chave apenas por software — estão nas páginas de comparação dedicadas: AppVault vs Vaultaire e AppVault vs Keepsafe. O AppVault publica sua pilha criptográfica completa com citações de fontes primárias, que é o pré-requisito para qualquer verificação independente.

Considerações Práticas para Desenvolvedores

Se você está implementando PBKDF2, siga estas diretrizes:

• Use HMAC-SHA256 como PRF. SHA1 é aceitável, mas exige mais iterações.
• Gere um salt aleatório de pelo menos 16 bytes por usuário ou por instância.
• Defina a contagem de iteração para a recomendação atual da OWASP (600.000 para SHA-256 a partir de 2026).
• Armazene o salt e a contagem de iteração junto com a chave derivada (ou metadados do cofre) para que a derivação possa ser repetida.
• Considere a vinculação a hardware (ex.: Secure Enclave, TPM) para proteger a chave derivada mesmo se o dispositivo for comprometido.
• Não use PBKDF2 para armazenamento de senhas em sistemas de autenticação se Argon2id estiver disponível. PBKDF2 é mais adequado para derivação de chave em cenários de criptografia local.

Conclusão

O PBKDF2 é uma função de derivação de chave testada em batalha que protege senhas e chaves de criptografia há mais de duas décadas. Não é o KDF mais moderno, mas é o mais amplamente suportado e, quando configurado corretamente, fornece forte proteção contra ataques de força bruta. A recomendação OWASP 2026 de 600.000 iterações para SHA-256 garante que cada tentativa de senha seja cara o suficiente para deter atacantes.

O AppVault usa PBKDF2 com 600.000 iterações, um salt por instalação e envolvimento do Secure Enclave para proteger seus arquivos. A combinação de alta contagem de iteração e vinculação a hardware torna o cofre resistente a ataques tanto de software quanto físicos. Sem redefinição de senha, sem backdoor, sem recuperação de chave no servidor. A segurança dos seus dados depende da força da sua senha e da integridade da derivação PBKDF2.

Para um olhar mais aprofundado sobre como o AppVault implementa sua criptografia, veja a visão geral de criptografia e o modelo de ameaça.