Recomendações NIST 2025 sobre senhas: o que mudou
Por CaptainDNS
Publicado em 20 de fevereiro de 2026
- O NIST agora proíbe a expiração periódica de senhas, exceto em caso de comprometimento confirmado
- As regras de complexidade (maiúscula + número + símbolo) foram abandonadas: na prática, elas degradam a segurança
- Mínimo de 8 caracteres obrigatórios, 15 recomendados, e os sistemas devem aceitar pelo menos 64 caracteres
- Cada senha deve ser verificada contra uma base de segredos comprometidos (como Have I Been Pwned) antes de ser aceita
- Dicas de senha e perguntas secretas são proibidas como mecanismos de recuperação
Durante anos, as políticas de senhas nas empresas seguiam a mesma receita: 8 caracteres no mínimo, uma maiúscula, um número, um símbolo e troca a cada 90 dias. Resultado: usuários que escolhem Primavera2025! em janeiro e Verao2025! em abril. O NIST reconheceu oficialmente que essa abordagem produz senhas mais fracas, não mais fortes.
A revisão 4 do SP 800-63B, publicada em 2024 e aplicável a partir de 2025, inverte a maioria dessas práticas. Esse documento é a referência federal americana para autenticação digital, mas sua influência vai muito além das fronteiras: ANSSI, BSI e OWASP alinham progressivamente suas recomendações.
Este artigo analisa as mudanças concretas, explica a lógica por trás de cada decisão do NIST e fornece um plano de ação para adequar sua política de senhas. Para testar imediatamente a robustez de uma senha, use nosso gerador de senhas com seu indicador de força em tempo real.
O que diz o NIST SP 800-63B-4
O SP 800-63B faz parte da suíte NIST SP 800-63 (Digital Identity Guidelines), que cobre todo o ciclo de vida da identidade digital. A revisão 4 substitui a versão 3 de 2017 e introduz mudanças importantes na seção dedicada aos "Memorized Secrets" (senhas e frases-passe).
Escopo do documento
O SP 800-63B é destinado aos provedores de serviços de autenticação (CSP, Credential Service Providers) e aos verificadores. Ele define três níveis de garantia (AAL1, AAL2, AAL3), cada um com exigências crescentes. As recomendações sobre senhas se aplicam principalmente ao nível AAL1 (autenticação por fator único) e são retomadas como base nos níveis superiores.
As 8 mudanças principais
A tabela a seguir resume as regras que mudam entre a versão 3 (2017) e a versão 4 (2024/2025):
| Regra | SP 800-63B-3 (2017) | SP 800-63B-4 (2025) |
|---|---|---|
| Comprimento mínimo | 8 caracteres | 8 obrigatório, 15 recomendado |
| Comprimento máximo | Não especificado | 64 caracteres mínimo suportado |
| Regras de complexidade | Desaconselhadas | Proibidas (SHALL NOT) |
| Rotação periódica | Desaconselhada | Proibida exceto comprometimento |
| Verificação de comprometimento | Recomendada | Obrigatória (SHALL) |
| Dicas de senha | Não mencionadas | Proibidas |
| Perguntas secretas | Desaconselhadas | Proibidas |
| Todos os caracteres Unicode | Recomendado | Obrigatório |
A mudança de "SHOULD NOT" (desaconselhado) para "SHALL NOT" (proibido) é significativa: não é mais uma recomendação, é uma exigência de conformidade.
Por que o NIST abandona a rotação obrigatória?
A rotação periódica de senhas é a regra mais controversa em segurança da informação. O NIST agora a proíbe explicitamente, e a razão é empírica.
O problema documentado
Estudos conduzidos na Universidade da Carolina do Norte (Chappell et al.) mostraram que, quando os usuários são obrigados a trocar suas senhas regularmente, eles adotam padrões previsíveis:
- Incremento:
Minhasenha1→Minhasenha2→Minhasenha3 - Rotação sazonal:
Inverno2024!→Primavera2025! - Transformação mínima:
MeuGato$→MeuGato$1→MeuGato$12
Um atacante que obtém uma senha antiga pode adivinhar a próxima com menos de 5 tentativas em 41% dos casos. A rotação não adiciona segurança, ela incentiva a previsibilidade.
A nova regra
A senha só deve ser trocada em dois casos:
- Comprometimento confirmado: a senha aparece em uma base de dados vazada
- Solicitação do usuário: troca voluntária
Os administradores devem remover toda política de expiração automática (90 dias, 180 dias, anual). O sistema deve, no entanto, monitorar ativamente as bases de comprometimento e forçar a troca se a senha atual aparecer nelas.
Por que as regras de complexidade são contraproducentes?
Exigir "pelo menos uma maiúscula, um número e um símbolo" parece lógico no papel. Na prática, produz o efeito oposto.
O efeito adverso medido
Quando um sistema impõe regras de composição, os usuários convergem para as mesmas estratégias:
- Maiúscula na primeira posição (95% dos casos)
- Números no final (89% dos casos)
- Símbolo:
!ou@(78% dos casos)
Password1! satisfaz todas as regras de complexidade clássicas. É quebrada em menos de um segundo por qualquer ferramenta de brute force que testa padrões comuns. A entropia teórica de uma senha com restrições é mais alta, mas a entropia real cai porque humanos são previsíveis.
O que o NIST recomenda no lugar
O comprimento é o fator dominante. Uma senha de 15 caracteres aleatórios sem restrição de composição oferece mais entropia do que uma senha de 8 caracteres que respeita todas as regras de complexidade. O NIST exige que os sistemas:
- Aceitem todos os caracteres imprimíveis ASCII e Unicode (incluindo espaços)
- Não imponham regras de composição
- Suportem no mínimo 64 caracteres (para permitir frases-passe)
- Normalizem as entradas Unicode (NFKC ou NFKD) para evitar problemas de encoding
Verificação contra bases de senhas comprometidas
Essa é a mudança mais técnica. Cada senha escolhida por um usuário deve ser verificada contra uma lista de segredos comprometidos antes de ser aceita.
Como implementar a verificação?
O NIST não prescreve uma implementação específica, mas o método mais comum usa o serviço Have I Been Pwned (HIBP) de Troy Hunt:
- O sistema calcula o hash SHA-1 da senha candidata
- Envia os 5 primeiros caracteres do hash à API HIBP (k-anonymity)
- A API retorna todos os hashes correspondentes
- O sistema verifica localmente se o hash completo está na lista
Esse mecanismo preserva a confidencialidade: a senha nunca é transmitida em texto claro nem como hash completo. A API HIBP contém mais de 900 milhões de senhas únicas provenientes de vazamentos reais.
Quando verificar?
| Momento | Obrigatório | Recomendado |
|---|---|---|
| Criação de conta | Sim | - |
| Troca de senha | Sim | - |
| Login | - | Sim (verificação periódica) |
Se a senha for encontrada na base de comprometimento, o sistema deve rejeitá-la com uma mensagem clara explicando o motivo e convidando o usuário a escolher outra.
O que o NIST proíbe explicitamente
Além das mudanças principais, várias práticas agora são formalmente proibidas:
Dicas de senha
Os campos de "dica" que exibem um lembrete em caso de esquecimento são proibidos. Eles expõem informações que ajudam um atacante a adivinhar a senha. Uma dica como "nome do meu gato + ano" reduz o espaço de busca a alguns milhares de combinações.
Perguntas secretas
"Qual é o nome de solteira da sua mãe?" ou "Em que cidade você nasceu?": essas perguntas de knowledge-based authentication (KBA) são proibidas como único fator de recuperação. As respostas frequentemente podem ser encontradas em redes sociais ou em bancos de dados públicos.
Truncamento da senha
Um sistema nunca deve truncar a senha para um comprimento fixo antes do hashing. Se um usuário digitar 40 caracteres, os 40 caracteres devem ser considerados. O truncamento reduz silenciosamente a entropia e cria uma falsa sensação de segurança.
Hashing sem salt
O NIST exige que as senhas sejam armazenadas com uma função de hashing resistente (bcrypt, scrypt, Argon2id ou PBKDF2) e um salt único por usuário. SHA-256 sozinho não é aceitável: é rápido demais e vulnerável a ataques de rainbow tables.
Comparação NIST, OWASP, ANSSI
O NIST não é a única referência. Veja como suas recomendações se comparam com outros padrões importantes:
| Critério | NIST SP 800-63B-4 | OWASP ASVS 4.0 | ANSSI (2021) |
|---|---|---|---|
| Comprimento mín. | 8 (15 recomendado) | 12 | 12 (16 para admin) |
| Comprimento máx. suportado | 64+ | 128 | Não especificado |
| Complexidade | Proibida | Desaconselhada | Aceita sob condições |
| Rotação | Proibida exceto comprometimento | Desaconselhada | 1 ano máx. |
| Verificação de comprometimento | Obrigatória | Recomendada | Não mencionada |
| MFA | Obrigatório AAL2+ | Obrigatório nível 2+ | Recomendado |
| Perguntas secretas | Proibidas | Proibidas | Não mencionadas |
Os três referenciais convergem nos princípios fundamentais (comprimento > complexidade, sem rotação desnecessária), mas divergem no nível de exigência. A ANSSI permanece mais conservadora em relação à complexidade e rotação. O OWASP é mais rigoroso quanto ao comprimento mínimo.
🎯 Plano de conformidade
Para administradores de sistemas e CISOs que precisam adaptar sua política:
- Remova a expiração periódica: desative as políticas de troca a cada 90/180 dias no Active Directory, LDAP ou seu IAM. Configure o monitoramento de comprometimento em seu lugar
- Elimine as regras de composição: remova as exigências de "maiúscula + número + símbolo". Aumente o comprimento mínimo para 15 caracteres e o máximo suportado para pelo menos 64
- Integre a verificação HIBP: implemente a verificação k-anonymity na criação e na troca de senha. Use um gerador de hash para verificar suas implementações SHA-1
- Aceite todos os caracteres: Unicode completo, incluindo espaços. Aplique a normalização NFKC antes do hashing
- Implante o MFA: a senha sozinha não é suficiente. FIDO2/WebAuthn para contas críticas, TOTP no mínimo para as demais
- Documente sua política: crie uma política escrita alinhada ao SP 800-63B-4 e comunique as mudanças aos usuários. Explique por que eles não precisarão mais trocar a senha regularmente
FAQ
O que é o NIST SP 800-63B?
O NIST SP 800-63B é um documento de referência publicado pelo National Institute of Standards and Technology (NIST) dos Estados Unidos. Faz parte da suíte Digital Identity Guidelines e cobre especificamente a autenticação e o gerenciamento do ciclo de vida de credenciais. A revisão 4, publicada em 2024, é a versão em vigor e traz mudanças significativas nas recomendações sobre senhas.
Ainda é necessário trocar a senha regularmente?
Não. O NIST proíbe explicitamente a expiração periódica de senhas (SHALL NOT). Uma senha só deve ser trocada se estiver comprometida (presente em uma base de dados vazada) ou se o usuário solicitar voluntariamente. Estudos mostram que a troca obrigatória leva os usuários a criarem senhas previsíveis e mais fracas.
As regras de complexidade ainda são necessárias?
Não. O NIST proíbe as regras de composição ("pelo menos uma maiúscula, um número, um símbolo"). Essas regras produzem padrões previsíveis (maiúscula no início, números no final, símbolo !) que reduzem a entropia real. O comprimento é o fator dominante: uma senha longa e aleatória é mais segura do que uma senha curta e "complexa".
Qual é o comprimento mínimo para uma senha em 2025?
O NIST exige um mínimo de 8 caracteres e recomenda 15. O OWASP e a ANSSI recomendam 12. Na prática, mire em 15+ caracteres para contas de usuário e 20+ para contas de administrador. Os sistemas devem aceitar no mínimo 64 caracteres para permitir o uso de frases-passe.
Como verificar se uma senha está comprometida?
Use o protocolo k-anonymity com a API Have I Been Pwned: faça o hash da senha em SHA-1, envie os 5 primeiros caracteres do hash à API e verifique se o hash completo aparece nos resultados. A senha nunca é transmitida em texto claro. Essa verificação deve ser feita na criação de conta e a cada troca de senha.
O NIST se aplica fora dos Estados Unidos?
O SP 800-63B é uma norma federal americana, mas sua influência é mundial. O OWASP se inspira diretamente nele, o BSI alemão e a ANSSI francesa alinham progressivamente suas recomendações. Para empresas internacionais ou que tratam dados de cidadãos americanos, seguir o NIST é um padrão de facto, mesmo sem obrigação legal direta.
Qual algoritmo de hashing usar para armazenar senhas?
O NIST recomenda Argon2id, bcrypt, scrypt ou PBKDF2, com um salt único por usuário. SHA-256 ou MD5 sozinhos são inaceitáveis: são rápidos demais e vulneráveis a ataques de rainbow tables e brute force por GPU. Argon2id é a escolha recomendada pelo OWASP em 2025, com parâmetros de memória e tempo adaptados à sua infraestrutura.
Glossário
- SP 800-63B: Special Publication do NIST que define as exigências de autenticação digital, parte B (Authentication and Lifecycle Management). A revisão 4 (2024) é a versão em vigor.
- AAL (Authentication Assurance Level): nível de garantia de autenticação definido pelo NIST, de AAL1 (fator único) a AAL3 (hardware criptográfico resistente a phishing).
- k-anonymity: técnica criptográfica que permite verificar se um dado pertence a um conjunto sem revelar o dado em si. Utilizada pelo Have I Been Pwned para verificação de senhas.
- Salt: valor aleatório único adicionado à senha antes do hashing, impedindo ataques por tabelas pré-calculadas (rainbow tables).
- Argon2id: função de hashing de senhas vencedora do Password Hashing Competition (2015), resistente a ataques por GPU e ASIC graças ao seu consumo de memória configurável.
Verifique a robustez das suas senhas agora: teste se suas URLs estão sendo exploradas por phishing com nosso detector de phishing, um complemento essencial para qualquer política de senhas sólida.
📚 Guias de segurança de senhas relacionados
- Passkeys vs senhas: vale a pena abandonar as senhas em 2025?
- Frase-passe vs senha: qual é realmente mais segura?
