Segurança Digital

PBKDF2

Ao contrário de um hash rápido como SHA‑256, PBKDF2 aplica uma função pseudorrandômica repetidamente para elevar o custo de cada palpite de senha. Definida no PKCS #5 e na RFC 8018, usa salt, contagem de iterações, tamanho de saída e PRF, normalmente HMAC‑SHA‑256. O requisito de implantação é calibrar o custo no hardware e armazenar os parâmetros. Em novos serviços com memória suficiente, Argon2id costuma oferecer maior resistência a GPU; PBKDF2 permanece relevante por compatibilidade, FIPS e suporte em plataformas legadas.

🛡 Níveis de Segurança

Compatível

PBKDF2-HMAC-SHA-256 calibrado

PBKDF2 é uma função de derivação de chave baseada em senha. Ela recebe senha, salt, contagem de iterações, tamanho desejado e uma PRF. HMAC-SHA-256 é uma escolha moderna e amplamente interoperável. A função calcula blocos pela aplicação repetida de HMAC e combina resultados com XOR. A contagem aumenta o custo linearmente. Um servidor pode usar centenas de milhares ou mais de iterações, mas o número correto depende de hardware e orientação atual. O projeto mede para atingir uma latência aceitável, como 100–500 ms por verificação, sem comprometer disponibilidade. O salt deve ser aleatório e único, normalmente pelo menos 16 bytes. O banco armazena algoritmo, hash, salt, iterações e tamanho. Formatos de frameworks variam; a migração precisa entender. PBKDF2 possui suporte em OpenSSL, Java, .NET, Python, Web Crypto, Node.js, Android, iOS e módulos criptográficos validados. Isso é seu principal benefício. Em ambientes que exigem FIPS 140, uma implementação validada de PBKDF2/HMAC pode ser mais simples de aprovar que Argon2, dependendo do módulo. A conformidade é da implementação e do módulo, não apenas do algoritmo. O serviço deve usar biblioteca do sistema ou framework. Não escrever o loop. A senha entra como bytes; codificação e normalização precisam ser consistentes. O resultado deve ser comparado em tempo constante. Contas inexistentes precisam executar trabalho equivalente para evitar enumeração. O endpoint também usa rate limiting e MFA.

Aplicado

PBKDF2 para derivação de chave de arquivo

PBKDF2 também deriva uma chave de uma senha para cifrar um backup, cofre ou configuração. Nesse caso, a saída alimenta uma cifra autenticada, como AES‑GCM. A função não cifra. O formato guarda salt, PRF, iterações, nonce e ciphertext. O salt é público. O nonce da cifra precisa ser único. A senha mestra deve ter alta entropia porque o arquivo pode ser atacado offline. Uma contagem de 600 mil iterações HMAC-SHA-256 pode ser um exemplo em hardware atual, mas não deve ser copiada sem benchmark e orientação. Em notebooks modernos pode levar fração de segundo; em microcontroladores, segundos. O produto deve informar progresso e evitar congelar. Se o arquivo precisa abrir em Java, .NET e Web, PBKDF2 oferece interoperabilidade. Todos devem usar a mesma codificação, PRF e tamanho. Um erro comum é uma plataforma usar UTF‑16 e outra UTF‑8. Testes com vetores. A chave derivada pode ser separada em chaves de cifra e autenticação por HKDF, embora AES-GCM já integre autenticação. Não reutilizar a saída diretamente para várias finalidades sem separação. O formato precisa de versão para aumentar iterações. Ao abrir com sucesso, pode recriptografar com parâmetros novos. Backups antigos continuam fracos até migrar. Uma chave de recuperação independente pode ser envolvida, mas aumenta risco.

Transição

PBKDF2 legado com HMAC-SHA-1

PBKDF2-HMAC-SHA-1 é amplamente encontrado em WPA2-Personal, PKCS #5 antigo, cofres e sistemas legados. HMAC-SHA-1 não sofre a mesma quebra de colisão de SHA-1 puro no mesmo grau, mas a escolha moderna costuma ser HMAC-SHA-256 ou SHA-512 quando o formato permite. Em WPA2-PSK, a especificação usa PBKDF2-HMAC-SHA-1 com 4096 iterações e SSID como salt para derivar a PSK. Esse parâmetro é fixo por interoperabilidade e hoje é baixo para senhas fracas. A defesa é uma senha Wi‑Fi longa e aleatória, WPA3 quando disponível e proteção contra captura. Não é possível simplesmente aumentar iterações sem quebrar compatibilidade. Para um banco próprio, migrar. O sistema pode reconhecer o hash antigo e rehash após login. Não aplicar SHA-256 sobre a saída antiga e chamar de migração. É necessário usar a senha. Em arquivos, abrir e recriptografar. O suporte legado deve ficar isolado e monitorado. Novas contas não usam. A documentação precisa separar algoritmo aceito para verificação e algoritmo usado para criação. Isso evita regressão. Um atacante pode forçar downgrade se o formato não é autenticado; o arquivo deve proteger metadados.

Evitar

Contagem baixa ou ausência de salt

PBKDF2 com 1000 ou 4096 iterações em um serviço novo é inadequado para senhas humanas em 2026, salvo protocolo fixo e compensações. CPUs e GPUs testam muitas. O algoritmo é compute-hard, não memory-hard, portanto GPUs e ASICs paralelizam melhor que Argon2. Aumentar iterações ajuda, mas também afeta servidor. A escolha deve ser revisada. Salt fixo permite que senhas iguais gerem hashes iguais e reutiliza tabelas. O salt não precisa ser secreto, mas precisa ser único. Não usar e-mail apenas. Uma contagem aleatória por usuário não aumenta significativamente e complica; política comum. Pepper secreta pode complementar, guardada fora do banco. O sistema deve impedir parâmetros vindos do atacante de causar CPU extrema. Ao verificar hash importado, limite iterações máximas e tamanho. Não usar PBKDF2 para gerar tokens aleatórios; use CSPRNG. Não usar uma senha curta para derivar chave de firmware e embuti-la. O atacante extrai salt e testa. Credenciais de dispositivo devem ser aleatórias e únicas, não humanas. Para chaves a partir de material já aleatório, HKDF é mais adequado e barato.

🖥 Aplicações em Hardware

🔒

Hub local

Banco de usuários em software compatível

Um hub Linux antigo que já usa PBKDF2 pode elevar iterações e migrar para HMAC-SHA-256. O formato guarda. O serviço autentica localmente, depois emite sessão. O banco fica em disco cifrado e backup protegido. O hub limita logins. Administradores usam MFA quando a interface permite. Um upgrade pode migrar para Argon2id no login; PBKDF2 fica somente para hashes antigos. Essa estratégia reduz risco sem bloquear. A implementação usa biblioteca do sistema. O firmware atualiza. A política é testada no hardware mínimo suportado.

🔒

Wi‑Fi

WPA2-Personal e derivação da PSK

WPA2-Personal deriva a chave a partir da passphrase e SSID usando PBKDF2-HMAC-SHA-1 com 4096 iterações. Como os parâmetros são fixos, a segurança depende da passphrase. Use 16–20 caracteres aleatórios ou mais, SSID não revelador e WPA3-SAE quando todos os clientes suportam. Uma senha curta pode ser atacada após captura do handshake. O morador deve evitar telefone e endereço. Trocar quando divulgada. Redes de convidados separam. A função é um exemplo de interoperabilidade rígida: não alterar iterações. O roteador e clientes precisam seguir. WPA3 usa SAE, não PBKDF2 do mesmo modo.

🔒

Backup cifrado

Arquivo de configuração exportado

Um fabricante pode usar PBKDF2-HMAC-SHA-256 para derivar uma key-encryption key da senha de exportação e cifrar o backup com AES-GCM. O cabeçalho inclui versão, salt de 16 bytes, iterações, nonce e algoritmo. O cabeçalho relevante é autenticado como AAD. O importador valida limites e tag antes de processar. A senha não é recuperável. Um medidor de força orienta. O arquivo não inclui chave em claro. A equipe publica formato ou garante ferramenta. Aumentar iterações por versão. Não usar ECB/CBC sem MAC. PBKDF2 sozinho não detecta senha errada; a tag AEAD detecta.

🔒

Módulo criptográfico

Ambiente regulado com implementação validada

Soluções que exigem módulo FIPS podem usar PBKDF2 disponível no módulo validado. A equipe verifica certificado, versão, modo aprovado, PRF e uso. Declarar “PBKDF2 é FIPS” é impreciso; a implementação e configuração são avaliadas. HSM ou biblioteca pode. Isso é relevante em plataformas de acesso, hospitais e edifícios. O módulo deve receber senha com segurança. O salt e parâmetros podem ficar no banco. A saída deve ser usada conforme finalidade. Logs não expõem. A certificação pode limitar algoritmos. A equipe de conformidade documenta. Se Argon2 não está disponível, PBKDF2 forte é melhor que algoritmo caseiro.

✓

Compatibilidade ampla em sistemas e bibliotecas

PBKDF2 está disponível em praticamente todas as pilhas, o que facilita que um hub, aplicativo e serviço verifiquem o mesmo formato. Essa interoperabilidade pode reduzir erros em produtos de longa vida. O morador se beneficia de migrações mais previsíveis e restauração de backups em plataformas diferentes. A equipe precisa padronizar HMAC-SHA-256, salt, iterações, tamanho e UTF‑8. A palavra “PBKDF2” sozinha não basta. Um aplicativo pode usar SHA-1 e 10 mil, outro SHA-256 e 600 mil. Não são compatíveis. O formato precisa carregar. Testes cruzados e vetores. A biblioteca deve ser mantida. A compatibilidade não justifica parâmetros fracos.

✓

Aumento gradual do custo

Ao autenticar, o servidor pode detectar que uma conta usa menos iterações que a política e rehash com a senha fornecida. Isso melhora sem forçar ação. O morador não percebe. O processo deve preservar sessão e tratar falha. A política precisa considerar todos os nós. Primeiro implantar suporte ao novo, depois escrever. Aumentar demais pode causar pico de CPU. Benchmark. Uma troca de hardware pode permitir. A equipe registra data. Contas antigas sem login continuam; para administradores, exigir reset. Em backups cifrados, a atualização exige abrir e salvar. O produto pode oferecer. Não alterar metadados sem recriptografar.

ℹ

Proteção limitada por senhas fracas

Mesmo com muitas iterações, `12345678` ou nome da família pode ser testado cedo. O algoritmo apenas encarece. O serviço deve permitir senhas longas, não impor regras que reduzem, usar lista de bloqueio de senhas vazadas e oferecer passkeys/MFA. A consequência é que uma senha única de 4–6 palavras aleatórias oferece mais proteção. O suporte nunca pede. Recuperação segura. Se o banco vaza, o usuário deve trocar em outros serviços onde reutilizou. O operador notifica. PBKDF2 não impede phishing nem malware.

ℹ

Latência e disponibilidade

A contagem elevada consome CPU em cada login. Um atacante online pode tentar exaurir. Rate limiting por IP e conta, desafio adaptativo, filas e proteção de borda ajudam. A função deve ser executada após validação barata de formato, mas sem revelar existência. O endpoint não aceita senhas de gigabytes; limita tamanho razoável, como 1 KiB, sem truncar silenciosamente. Em um hub ARM, 600 mil HMAC-SHA-256 pode levar segundos. Medir. Talvez Argon2 ou hardware melhor. Não reduzir para 1000. A autenticação pode ser centralizada. Depois, tokens de sessão evitam recalcular em cada chamada.

⚠️

Nota Técnica

PBKDF2 é especificada no PKCS #5 v2 e na RFC 8018. A função constrói blocos `T_i = F(P,S,c,i)`, onde `F` aplica a PRF c vezes e combina as saídas. O tamanho derivado pode exceder o tamanho da PRF por múltiplos blocos, mas para hashing de senha 32 bytes costuma ser suficiente. Mais bytes não aumentam a entropia da senha. A contagem c deve ser positiva e calibrada. HMAC-SHA-256 ou HMAC-SHA-512 são escolhas atuais quando o formato permite. SHA-512 pode ser mais rápido em CPUs de 64 bits, portanto o benchmark deve medir custo para defensor e atacante; não assumir que número maior é mais forte. A força principal vem de senha, salt e trabalho. PBKDF2 é CPU-hard e não memory-hard. Argon2id costuma ser preferido em novos armazenamentos por impor memória. PBKDF2 continua adequado quando compatibilidade, módulos validados ou padrões exigem. O salt deve ser único e aleatório; 128 bits é prática sólida. O formato precisa incluir PRF, contagem, salt, saída e versão. Não usar a mesma derivação para autenticação e criptografia sem separação de contexto. Se precisa múltiplas chaves, derivar uma master com PBKDF2 e expandir por HKDF com labels, ou usar saída longa com especificação clara. Não usar senha diretamente como HMAC key sem derivação. A verificação deve usar comparação constante. O sistema deve impor limites ao importar parâmetros. A função não autentica o protocolo. Senha precisa ser enviada por TLS. Um hash de cliente fixo vira credencial reutilizável. O servidor deve usar nonce/PAKE se quiser evitar. Para dispositivos, credenciais aleatórias de 128 bits não precisam de PBKDF2; podem ser usadas como chaves com KDF apropriada. A gestão de ciclo de vida e rehash é obrigatória.