Diretrizes de palavras-passe NIST 2026: O que exige a SP 800-63B-4

A NIST SP 800-63B-4, que reúne as diretrizes de palavras-passe NIST, exige que as palavras-passe utilizadas como único fator de autenticação tenham, pelo menos, 15 caracteres. Muitos resumos descrevem este valor como uma recomendação, mas a secção 3.1.1.2 apresenta-o como um requisito.

Na SP 800-63B-4 (versão final desde julho de 2025), as diretrizes fixam 15 caracteres como mínimo para o início de sessão apenas com palavra-passe e 8 quando a palavra-passe é um dos fatores da autenticação multifator. Proíbem as regras de composição e as alterações periódicas, e exigem que os verificadores bloqueiem palavras-passe expostas em fugas de dados, comuns e específicas do contexto.

Este guia classifica cada requisito de palavras-passe em SHALL, SHOULD e MAY, com os números das secções, mostra o que mudou desde a Rev 3, corrige seis interpretações erradas frequentes e termina com uma lista de verificação para a implementação.

Diretrizes de palavras-passe NIST: O que é a SP 800-63B-4 e a quem se aplica

A NIST SP 800-63B-4 é o volume dedicado à autenticação das Digital Identity Guidelines (SP 800-63-4) do NIST. O NIST publicou a versão final em julho de 2025, que substitui a SP 800-63B de março de 2020. A norma foi redigida para os sistemas de informação do governo dos EUA, pelo que, para organizações na Europa e noutras regiões, é uma orientação voluntária e um ponto de referência para a política interna.

A SP 800-63-4 tem quatro volumes: o documento principal, a comprovação de identidade (63A), a autenticação (63B) e a federação (63C). Segundo a página da SP 800-63-4 do NIST, a revisão demorou quase quatro anos, com duas versões preliminares públicas e quase 6000 comentários públicos.

O âmbito está definido no resumo. A diretriz «centra-se na autenticação de sujeitos que interagem com sistemas de informação governamentais» e «não pretende restringir o desenvolvimento ou a utilização de normas fora deste propósito». Para as agências federais dos EUA e os respetivos fornecedores de serviços de credenciais, os requisitos são normativos.

O NIST utiliza um vocabulário próprio, diferente da linguagem dos fornecedores:

Requisitos de palavras-passe NIST: O mapa SHALL, SHOULD e MAY

Os requisitos de palavras-passe NIST têm três graus de obrigatoriedade. SHALL e SHALL NOT assinalam regras de conformidade obrigatórias da própria norma, SHOULD assinala uma recomendação cuja omissão tem de ser justificada e MAY assinala uma opção permitida. Na SP 800-63B-4, os comprimentos mínimos, as proibições de regras de composição e de alterações periódicas, as verificações na lista de bloqueio, a limitação de tentativas e o hash com salt são todos SHALL.

Utilize a política de palavras-passe SHALL-first como método de trabalho: implemente todos os requisitos obrigatórios antes de qualquer requisito recomendado. O nível 1 é a base SHALL, o nível 2 é o reforço SHOULD e o nível 3 corresponde às permissões MAY, que só se adotam quando se adequam aos utilizadores. A tabela seguinte distribui cada requisito de palavras-passe por esses níveis, com a secção em que o NIST o estabelece.

Construa a política primeiro a partir das linhas SHALL. Cada linha SHOULD que não aplicar precisa de um motivo registado, e as linhas MAY são opções a adotar ou não.

O que mudou da SP 800-63B Rev 3 para a Rev 4

A Rev 4 eleva o mínimo da palavra-passe de fator único para 15 caracteres (antes eram 8) e passa duas recomendações da Rev 3, sem regras de composição e sem alterações periódicas, de SHOULD NOT para SHALL NOT. As FAQ do NIST indicam que ambas eram antes desaconselhadas, mas permitidas. As verificações na lista de bloqueio, as proibições de dicas e de KBA, o hash com salt e a limitação de tentativas já eram obrigatórios na Rev 3.

As FAQ de implementação do NIST enumeram os novos requisitos de palavras-passe, e a SP 800-63B Rev 3 (2020) confirma a redação anterior. A tabela compara os dois textos.

A Rev 4 acrescenta ainda requisitos para autenticadores sincronizáveis, como as passkeys sincronizadas (Apêndice B), e uma definição de autenticadores resistentes a phishing (secção 3.2.5), ambos indicados no registo de alterações do NIST (Apêndice E). Numa política redigida segundo a Rev 3, o comprimento mínimo, as regras de composição e as definições de expiração são os primeiros pontos a mudar.

Seis interpretações erradas frequentes das regras de palavras-passe do NIST

Circulam seis erros nos resumos da SP 800-63B-4: tratar os 15 caracteres como opcionais, citar 8 como o mínimo geral, confundir os limites de 100 e de 10 tentativas, considerar o SMS proibido, exigir a opção de colar em vez dos gestores de palavras-passe e apresentar a verificação na lista de bloqueio como uma novidade. Cada linha indica o requisito real e a secção que o estabelece.

Comprimento, caracteres e listas de bloqueio: O que os verificadores têm de verificar

Os verificadores têm de exigir 15 caracteres para o início de sessão apenas com palavra-passe, contar cada ponto de código Unicode como um carácter, rejeitar regras de composição e comparar na íntegra cada nova palavra-passe com uma lista de bloqueio de valores expostos em fugas de dados, comuns e específicos do contexto. Quando uma palavra-passe é rejeitada, o verificador tem de explicar porquê e dar orientações para escolher uma palavra-passe forte.

A regra do comprimento tem dois níveis. Uma palavra-passe utilizada como único fator precisa de 15 caracteres. Uma palavra-passe utilizada apenas como parte da autenticação multifator pode ter menos de 15, mas precisa de, pelo menos, 8 (secção 3.1.1.2). É possível definir um único mínimo de 15 para todos os percursos, porque o NIST o permite e as orientações aos utilizadores ficam reduzidas a um só número.

Acima do mínimo, os verificadores devem aceitar, pelo menos, 64 caracteres e têm de verificar a palavra-passe completa, sem truncagem. Cada ponto de código Unicode conta como um carácter. Quando o Unicode é aceite, deve aplicar-se a normalização NFC antes do hash, porque o NIST alerta para o facto de alguns terminais representarem certos caracteres de forma diferente, o que pode impedir a autenticação.

Os conjuntos de caracteres são abertos: os verificadores devem aceitar todos os caracteres ASCII imprimíveis, o espaço e o Unicode. Não podem impor outras regras de composição, como exigir combinações de tipos de caracteres (secções 3.1.1.1 e 3.1.1.2). O Apêndice A explica porquê: os utilizadores «respondem de formas muito previsíveis aos requisitos impostos pelas regras de composição», pelo que password passa a Password1 e depois a Password1!. O artigo sobre a razão pela qual as regras de composição falham na prática analisa esse comportamento e os cálculos de entropia.

Quando um utilizador define ou altera uma palavra-passe, o verificador tem de a comparar com uma lista de bloqueio de valores frequentes, previsíveis ou comprometidos. A comparação abrange a palavra-passe completa, não subcadeias nem palavras contidas nela. A lista pode basear-se em três fontes:

• palavras-passe de compilações de fugas de dados anteriores
• palavras do dicionário
• palavras específicas do contexto, como o nome do serviço, o nome de utilizador e os respetivos derivados

Se a palavra-passe constar da lista, o verificador tem de exigir outra, indicar o motivo da rejeição e dar orientações para escolher uma palavra-passe forte. As orientações são mais importantes após uma rejeição, porque desencorajam alterações triviais de uma palavra-passe da lista.

O tamanho tem limites. O NIST afirma que «listas de bloqueio excessivamente grandes trazem pouco benefício adicional de segurança, porque a lista de bloqueio serve para defender contra ataques online, que já estão limitados pelos requisitos de limitação de tentativas». O objetivo é uma lista suficientemente grande para travar as palavras-passe que um atacante tentaria antes de atingir o limite de tentativas (SHOULD).

Na escolha de uma palavra-passe, há dois pedidos proibidos. Os verificadores não podem permitir que um subscritor armazene uma dica visível para um requerente não autenticado, nem pedir autenticação baseada em conhecimento (KBA) ou perguntas de segurança.

Alterações de palavras-passe, limitação de tentativas e armazenamento

Os verificadores não podem exigir alterações periódicas de palavras-passe, mas têm de impor uma alteração perante evidências de comprometimento. As tentativas falhadas consecutivas estão limitadas a 100 por autenticador, e as palavras-passe armazenadas têm de ter salt e hash, com um salt de, pelo menos, 32 bits. Estas regras constam das secções 3.1.1.2 e 3.2.2.

Alterações. A expiração por calendário deixou de ser admitida, e as FAQ do NIST referem que as alterações periódicas de rotina eram «antes desaconselhadas, mas permitidas» na Rev 3. Uma alteração forçada é obrigatória quando há evidências de que o autenticador foi comprometido. O NIST não define essas evidências, pelo que tem de ser a política interna a fazê-lo. Uma denúncia do subscritor e a correspondência de uma palavra-passe existente com uma compilação de fugas de dados são dois acionadores práticos, e ambos são opções de política, não eventos definidos pelo NIST.

Limitação de tentativas. Um verificador tem de limitar as tentativas falhadas consecutivas num único autenticador a um máximo de 100 «desativando esse autenticador», e um autenticador desativado tem de ser novamente associado à conta antes de voltar a funcionar (secções 3.2.2 e 4.1). O limite é um teto, e são permitidos limites inferiores. Para impedir que os atacantes bloqueiem utilizadores legítimos, o verificador pode acrescentar um desafio de deteção de bots, uma espera que aumenta de 30 segundos até uma hora ou sinais baseados no risco. Compare o comportamento de bloqueio do IdP com a formulação «desativando». Os segredos de ativação, como o PIN de um dispositivo que nunca sai do dispositivo, seguem outra regra: pelo menos 4 caracteres (6 recomendados) e um máximo de 10 tentativas falhadas consecutivas (secção 3.2.10).

Armazenamento. As palavras-passe têm de ser armazenadas com salt e hash, através de um esquema de hash de palavras-passe adequado, e o salt tem de ter, pelo menos, 32 bits e ser escolhido de forma a minimizar colisões entre contas. Os verificadores devem utilizar um esquema aprovado da SP 800-132 mais recente ou de orientações atualizadas do NIST, definir o fator de custo tão elevado quanto possível e aumentá-lo ao longo do tempo. Devem ainda acrescentar um hash com chave, com uma chave secreta armazenada separadamente dos hashes, idealmente num módulo de segurança de hardware (HSM) ou num ambiente de execução fidedigno. O NIST deixou de enumerar algoritmos específicos porque os requisitos de armazenamento mudam rapidamente.

Onde se enquadram as palavras-passe nos níveis AAL1, AAL2 e AAL3

A autenticação apenas com palavra-passe só é permitida no AAL1, razão pela qual a regra dos 15 caracteres se aplica a esse nível. No AAL2, a palavra-passe tem de ser combinada com um autenticador físico, e os verificadores têm de oferecer uma opção resistente a phishing. O AAL3 exige um autenticador criptográfico com uma chave privada não exportável, sendo a palavra-passe permitida apenas como fator adicional.

Os valores provêm das secções 2.1 a 2.3 da norma do NIST. Seguem-se três notas.

1. O mínimo de 15 caracteres está associado à utilização como fator único. As FAQ do NIST descrevem o aumento como aplicável às palavras-passe «utilizadas como fator único de autenticação no AAL1».
2. As palavras-passe não são resistentes a phishing (secção 3.1.1). No AAL2, os verificadores têm de oferecer, pelo menos, uma opção resistente a phishing (secção 2.2.2). A resistência a phishing exige autenticação criptográfica, e os autenticadores que implicam a introdução manual de um resultado, como os códigos OTP e fora de banda, não cumprem esse requisito (secção 3.2.5). O guia sobre como funcionam as passkeys aborda a vertente criptográfica.
3. Os autenticadores sincronizáveis, como as passkeys sincronizadas, podem ser usados no AAL2 quando são cumpridos os requisitos do Apêndice B. Não podem ser usados no AAL3: a sincronização implica que a chave privada é exportável, e o AAL3 exige uma chave não exportável (secção 2.3.2).

Os códigos por SMS e por voz pertencem a uma categoria à parte. A autenticação fora de banda através da rede telefónica é um autenticador restrito. A organização tem de avaliar e aceitar o risco, oferecer, pelo menos, uma alternativa sem restrições, informar os subscritores de forma clara e manter um plano de migração (secções 3.1.3.3 e 3.2.9).

Como aplicar as diretrizes de palavras-passe NIST: Uma implementação SHALL-first

Uma implementação SHALL-first configura todos os requisitos obrigatórios antes de qualquer requisito recomendado. Inventarie cada sistema que verifica palavras-passe, defina o mínimo de 15 caracteres, elimine as regras de composição e de expiração, ative a verificação na lista de bloqueio, confirme a limitação de tentativas, audite o código desenvolvido internamente, ofereça autenticação resistente a phishing e registe as exceções num registo próprio.

1. Inventarie todos os pontos onde é verificada uma palavra-passe: diretório, IdP, VPN, aplicações para clientes e aplicações internas. As obrigações do NIST recaem sobre o verificador, pelo que cada sistema que verifica uma palavra-passe precisa da sua própria linha.
2. Defina o comprimento mínimo. Utilize 15 caracteres em todos os percursos apenas com palavra-passe e decida o mínimo para os percursos com MFA: o NIST permite 8 nesses casos, e uma única regra de 15 para ambos mantém a política e as orientações aos utilizadores simples.
3. Elimine as regras de composição da política de palavras-passe do diretório, da política do IdP e do código das aplicações.
4. Elimine a expiração por calendário. Mantenha a alteração forçada perante evidências de comprometimento e documente o que a aciona.
5. Ative a verificação na lista de bloqueio nas operações de definição e de alteração, incluindo palavras específicas do contexto, como o nome do serviço e o nome de utilizador. A mensagem de rejeição tem de indicar o motivo e dar orientações. Se o diretório não fizer esta verificação de forma nativa, o requisito continua a caber ao verificador, por isso confirme o que o IdP permite fazer.
6. Verifique a limitação de tentativas: no máximo 100 falhas consecutivas por autenticador. Aplique um limite inferior e atrasos progressivos quando a empresa os puder aceitar, e compare o comportamento de bloqueio com a formulação do NIST «desativando esse autenticador».
7. Audite as aplicações desenvolvidas internamente. Devem aceitar 64 ou mais caracteres, Unicode e espaços, permitir colar e o preenchimento automático, nunca truncar e armazenar as palavras-passe com salt e hash, através de um esquema atual. Abandone os filtros de caracteres especiais destinados a travar a injeção de SQL: o Apêndice A observa que uma palavra-passe sem hash nunca é enviada intacta para uma base de dados, pelo que esses filtros são desnecessários.
8. Ofereça autenticação resistente a phishing para acessos privilegiados e remotos. As palavras-passe não são resistentes a phishing, e os verificadores AAL2 têm de oferecer, pelo menos, uma opção resistente a phishing.
9. Registe as exceções. Um contrato ou um quadro de conformidade pode ainda exigir algo diferente, como a rotação periódica. Registe cada exceção com o requisito, o motivo, um responsável e uma data de revisão.

Onde se enquadra um gestor de palavras-passe numa política SP 800-63B-4

A SP 800-63B-4 exige que os verificadores permitam gestores de palavras-passe e o preenchimento automático, e o NIST observa que os gestores aumentam a probabilidade de palavras-passe mais fortes, sobretudo quando têm geradores. Um gestor de palavras-passe abrange as credenciais que o fornecedor de identidade não verifica. Não altera a forma como o diretório ou o IdP verificam as palavras-passe, que continua a ser uma tarefa de configuração à parte.

Há dois grupos de credenciais que ficam fora da configuração do verificador: contas em sistemas SaaS e de fornecedores que a organização não verifica diretamente, e credenciais partilhadas ou privilegiadas que nenhuma política de palavras-passe do diretório abrange. Ambos precisam de palavras-passe longas, aleatórias e únicas.

O Passwork apoia esta utilização com quatro funcionalidades:

• Um gerador de palavras-passe integrado na interface web, na extensão do browser e nas aplicações móveis e de computador. Aplica as regras definidas pela organização e ajuda os utilizadores a criar uma palavra-passe única para cada serviço.
• Um painel de segurança que indica a força das palavras-passe (com base no comprimento e na diversidade de caracteres), a antiguidade (assinala as palavras-passe sem alterações há 180 dias ou mais) e o risco de comprometimento, como palavras-passe ainda acessíveis a utilizadores cujo acesso foi revogado. Os administradores podem filtrar por cofre, pasta, utilizador e categoria de ameaça.
• Uma política de bloqueio configurável pelo administrador para a autenticação local, com número máximo de tentativas falhadas, janela temporal e duração do bloqueio. Rege o início de sessão no próprio cofre e é independente do limite de tentativas que o verificador aplica ao abrigo da secção 3.2.2.
• Início de sessão com passkeys (WebAuthn), TOTP, SAML SSO ou LDAP/AD, bem como um Registo de atividade das ações dos utilizadores, dos administradores e do sistema, exportável para sistemas SIEM.

O indicador de antiguidade é um sinal para revisão, não uma regra de expiração. A secção 3.1.1.2 proíbe exigir alterações periódicas das palavras-passe que o próprio verificador confirma, e a plataforma não altera isso.

Conclusão

As diretrizes de palavras-passe NIST da SP 800-63B-4 resumem-se a uma política curta: um comprimento mínimo, sem regras de composição, sem calendário de expiração, com verificação na lista de bloqueio, limitação de tentativas e hash com salt. Aplique a política de palavras-passe SHALL-first antes de investir esforço nas linhas SHOULD.

Comece por três alterações. Defina 15 caracteres em todos os percursos apenas com palavra-passe e elimine as regras de composição e de expiração. Acrescente a verificação na lista de bloqueio em todos os pontos onde se definem palavras-passe. Ofereça autenticação resistente a phishing aos utilizadores privilegiados. As credenciais de sistemas fora da política de palavras-passe do IdP continuam a precisar de valores longos e únicos, e o lugar delas é num gestor de palavras-passe.

Veja a força, a antiguidade e o risco de comprometimento das palavras-passe de todos os cofres num único painel. Iniciar uma avaliação gratuita do Passwork e verificar o estado das credenciais partilhadas.

Perguntas frequentes

Violação de segurança da Northflank: O que rodar após o incidente

A Northflank pediu aos clientes que assumissem que todas as variáveis de ambiente tinham sido decifradas. A Railway alertou que algumas poderiam ter sido, e a Huntress detetou tokens do M365 roubados e reutilizados em 79 organizações. O que cada uma divulgou e o que rodar.

PassworkPasswork Team

Gestão de acessos NIS2: O que cinco especialistas corrigiriam primeiro

Da política à prática: quem teve acesso a quê, com a aprovação de quem, durante quanto tempo, e é possível prová-lo? Cinco líderes de cibersegurança sobre os controlos de acesso mais difíceis de operacionalizar e as evidências de que as organizações precisam para demonstrar que funcionam.

PassworkPasswork Team

Normas de conformidade para gestores de palavras-passe: O que mudou em 2026

O NIST diz para nunca rodar. A PCI DSS ainda pode exigir a cada 90 dias. Este guia relaciona nove quadros de conformidade e as passkeys com os controlos do cofre e mostra como resolver o conflito pelo âmbito.

PassworkAlex Muntyan