Muitas regras comuns para senhas dificultam a vida de quem as usa sem impedir ataques modernos. Veja quais controles as orientações atuais do NIST, do NCSC e da Microsoft recomendam.
A política de senhas costuma ser tratada como uma lista de requisitos: exigir uma letra maiúscula, um número, um símbolo e uma troca a cada 60 ou 90 dias. Essas regras são visíveis e fáceis de auditar, mas visibilidade não é sinônimo de eficácia. Invasores exploram escolhas humanas previsíveis, credenciais reutilizadas, processos de recuperação frágeis e bancos de dados de senhas mal protegidos.
Uma política útil deve reduzir esses riscos concretos sem dificultar tanto o uso a ponto de levar as pessoas a contorná-la.
Tamanho mínimo
O tamanho amplia o espaço de busca, mas apenas quando a senha não é uma frase comum nem segue um padrão previsível. As orientações atuais do NIST exigem pelo menos 15 caracteres quando a senha é o único fator de autenticação e permitem um mínimo menor, de oito caracteres, quando ela faz parte de uma autenticação multifator. Os sistemas devem aceitar pelo menos 64 caracteres para que gerenciadores de senhas e frases-senha funcionem adequadamente.
O tamanho é um requisito básico, não uma garantia de força. É necessária uma lista de bloqueio de senhas comprometidas, pois uma senha longa que já é conhecida por invasores continua insegura.
Expiração periódica de senhas
Trocas obrigatórias em intervalos fixos tendem a gerar alterações pequenas e previsíveis. Elas também impõem um custo a cada usuário sem que haja evidências de que todas as senhas tenham sido expostas. O NIST, o NCSC do Reino Unido e a Microsoft desaconselham a expiração periódica. Em vez disso, a senha deve ser alterada quando houver evidências ou uma suspeita razoável de comprometimento, quando se descobrir que o armazenamento é vulnerável ou quando um evento de recuperação de conta exigir a troca.
As organizações ainda precisam detectar problemas e redefinir senhas rapidamente. Eliminar a troca periódica não significa manter uma senha sabidamente comprometida.
Regras de composição
A exigência de letras maiúsculas, minúsculas, números e símbolos incentiva padrões como uma primeira letra maiúscula e um dígito ou símbolo no final. As ferramentas de ataque já levam essas substituições em conta. Os serviços devem permitir espaços e uma ampla variedade de caracteres, evitar regras arbitrárias de composição e comparar a senha proposta inteira com senhas comuns e comprometidas.
Bloquear sinais de pontuação porque poderiam ser usados em injeção de SQL ou ataques de scripts entre sites é um sinal de alerta. O código da aplicação deve usar consultas parametrizadas ao banco de dados e tratar a saída de forma segura. Restringir a senha de um usuário não substitui a correção de vulnerabilidades de injeção.
Reutilização de senhas e credenciais vazadas
A reutilização é um dos riscos de maior impacto, pois um vazamento em um provedor pode permitir o acesso a contas em outro. A política deve exigir uma senha exclusiva para o serviço, oferecer suporte a gerenciadores de senhas e verificar as senhas propostas contra valores sabidamente comprometidos por meio de um método que preserve a privacidade. As organizações também devem monitorar padrões de ataques de credential stuffing e comportamentos incomuns de login.
O histórico de senhas pode impedir a reutilização exata dentro de um serviço, mas listas de histórico muito longas podem incentivar mudanças apenas superficiais. Ele não consegue detectar a reutilização em outros provedores e não deve ser tratado como a principal defesa.
Armazenamento seguro de senhas
As senhas devem ser transmitidas ao serviço somente por uma conexão TLS protegida e nunca devem ser registradas em logs. No servidor, cada senha deve ser processada com um salt aleatório exclusivo e uma função lenta de hash de senhas, projetada para essa finalidade. A OWASP geralmente recomenda Argon2id; scrypt, bcrypt ou PBKDF2 podem ser adequados, desde que respeitadas as restrições especificadas. Os fatores de custo precisam ser revisados periodicamente à medida que o hardware evolui.
Um pepper armazenado fora do banco de dados de senhas pode acrescentar outra camada de proteção, mas cria responsabilidades de gerenciamento e rotação de chaves. Ele não substitui um salt nem uma função robusta de hash de senhas. Funções de hash rápidas e de uso geral, como MD5 e SHA-1/SHA-2 sem proteção adicional, não são adequadas, por si só, para armazenar senhas.
O que uma política eficaz inclui
Tamanho mínimo adequado ao risco e suporte a senhas longas.
Bloqueio de senhas comuns, previsíveis e sabidamente comprometidas.
Suporte a gerenciadores de senhas, colagem e preenchimento automático.
Hash de senhas com salt exclusivo, função lenta e fatores de custo revisados.
Limitação de frequência em camadas e detecção de tentativas de adivinhar senhas, pulverização de senhas e credential stuffing.
MFA resistente a phishing ou chaves de acesso, especialmente para contas privilegiadas e sensíveis.
Recuperação segura, substituição de autenticadores, revogação de sessões e redefinições motivadas por comprometimento.
