Uma política de senhas deve tornar contas mais difíceis de serem comprometidas sem tornar o comportamento seguro desnecessariamente complicado. As melhores políticas são claras, práticas e alinhadas com a forma como as pessoas realmente trabalham. Elas incentivam senhas longas e únicas, apoiam o uso de gerenciadores de senhas, exigem autenticação multifator quando apropriado e eliminam regras obsoletas que levam usuários a comportamentos previsíveis.
Este artigo explica os pontos positivos e negativos de uma política de senhas moderna, o que evitar, melhores práticas a seguir e um modelo pronto para ser adaptado pela sua organização.
Uma política de senhas é um conjunto de regras que define como as senhas são criadas, armazenadas, utilizadas, compartilhadas, alteradas e protegidas. Ela se aplica a funcionários, prestadores de serviço, administradores, contas de serviço e, em alguns casos, a clientes, dependendo dos sistemas envolvidos.
Uma boa política de senhas deve responder a perguntas práticas:
O objetivo não é criar o conjunto de regras mais complicado. O objetivo é reduzir riscos reais.
O tamanho é uma das defesas mais fortes contra ataques de adivinhação e força bruta. Um único requisito de comprimento mínimo para todos geralmente é mais fácil para as pessoas entenderem e para as equipes de TI aplicarem do que regras separadas para usuários comuns, administradores e casos especiais. Uma recomendação prática é exigir pelo menos 16 caracteres para todas as contas de usuários humanos. Quanto maior, melhor, especialmente quando usuários utilizam gerenciadores de senhas ou frases-senha aleatórias geradas.
Usuários devem poder criar senhas muito maiores que o mínimo exigido. Evite limites máximos baixos, como 16 ou 20 caracteres. Um limite de pelo menos 64 caracteres é razoável e muitos sistemas suportam ainda mais.
Frases-senha devem ser permitidas se forem longas e não baseadas em citações famosas, letras de músicas, nomes de empresas ou frases previsíveis. Por exemplo, uma frase composta por várias palavras aleatórias geralmente é melhor que uma senha curta com substituições forçadas.
Cada conta deve ter uma senha única. O reaproveitamento de senhas é uma das principais razões pelas quais uma violação em um serviço pode resultar na invasão de contas em outro. Gerenciadores de senhas tornam o uso de senhas únicas prático, já que os usuários não precisam memorizar todas as credenciais.
Sua política deve explicitar a permissão e o incentivo ao uso de gerenciadores de senhas aprovados. Usuários devem poder colar senhas em formulários de login, usar preenchimento automático e gerar senhas aleatórias. Bloquear o colar pode parecer protetivo, mas geralmente desestimula o uso efetivo de gerenciadores de senhas.
Senhas devem ser rejeitadas se constarem em listas de violações conhecidas, listas de senhas comuns ou listas restritas específicas da organização. Isso é mais útil que obrigar o uso de uma letra maiúscula, um número e um símbolo.
A autenticação multifator deve ser ativada onde for tecnicamente possível, especialmente para administradores, acessos remotos, serviços em nuvem, e-mail, gerenciadores de senha, sistemas financeiros e outros sistemas críticos. O MFA não substitui senhas fortes, mas reduz o impacto do roubo de credenciais.
Prefira MFA resistente a phishing, como passkeys, chaves físicas de segurança ou autenticadores de plataforma. Aplicativos autenticadores são normalmente melhores que SMS. MFA por SMS não deve ser usado se houver outra opção mais forte, pois números de telefone podem ser interceptados, portados, sofrer troca de SIM ou serem abusados por processos de recuperação de conta.
Isso não é teórico. Em 2018, o Reddit divulgou que atacantes interceptaram autenticação de dois fatores por SMS e acessaram sistemas internos: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. Em 2021, a Coinbase reportou que atacantes roubaram criptomoedas de pelo menos 6.000 clientes abusando de credenciais e de uma falha no processo de recuperação por SMS: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
Senhas devem ser trocadas sempre que houver indícios ou suspeita razoável de comprometimento. Exemplos incluem phishing, malware no dispositivo do usuário, vazamento de credenciais, atividade de login suspeita ou divulgação acidental.
Senhas compartilhadas devem ser evitadas sempre que contas individuais forem possíveis. Se o compartilhamento for inevitável, as credenciais devem ser armazenadas em um gerenciador de senhas aprovado, o acesso deve ser restrito a usuários autorizados e o compartilhamento deve ser registrado, sempre que possível.
O reset de senha costuma ser o ponto mais fraco da segurança das contas. Os fluxos de redefinição devem verificar a identidade, expirar links rapidamente, utilizar tokens de uso único e notificar os usuários quando a senha for alterada.
Exigir trocas obrigatórias todo mês, dois meses ou trimestre geralmente resulta em senhas mais fracas. Usuários tendem a fazer mudanças pequenas e previsíveis, como adicionar um número ou trocar uma estação do ano. As Diretrizes de Identidade Digital do NIST aboliram renovações periódicas automáticas e exigem troca de senha apenas com evidências de comprometimento. Veja a seção 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Exija a troca após suspeita de comprometimento, mudança de função, recuperação de conta ou se a senha não atender mais à política.
Regras como "deve conter maiúscula, minúscula, número e símbolo" não garantem força. Password1! atende muitas regras, mas é fraca. Priorize comprimento, unicidade, aleatoriedade e verificação contra vazamentos.
Bloquear o colar dificulta o uso de gerenciadores de senhas. Isso pode levar os usuários a escolherem senhas curtas e fáceis de digitar. Permita colar e preenchimento automático, salvo motivo de segurança bem documentado para não permitir.
Dicas de senha geralmente expõem informações demais. Se o usuário consegue lembrar a senha pela dica, um atacante também pode. Prefira processos seguros de redefinição.
Sistemas nunca devem armazenar senhas em texto puro ou com criptografia reversível. Utilize algoritmos modernos, lentos e com salt, como Argon2id, bcrypt, scrypt ou PBKDF2, conforme capacidade e requisitos regulatórios do sistema.
Algoritmos rápidos e generalistas como MD5, SHA-1, SHA-256 ou SHA-512 não são apropriados para senhas. Eles são feitos para serem rápidos, o que facilita ataques de força bruta após vazamento. Para mais detalhes, veja nosso artigo sobre a evolução do hashing de senhas.
Senhas não devem ser enviadas por e-mail, chat, ticket, documentos ou prints. Utilize um gerenciador de senhas com compartilhamento seguro e controle de acesso.
Senhas não devem conter nomes, datas de nascimento, nomes da empresa, padrões de teclado, caracteres repetidos ou substituições comuns como @ por a e 0 por o. Atacantes testam esses padrões logo no início.
Estabeleça requisitos fáceis de entender:
Contas administrativas, de serviço e acesso à produção exigem regras mais rígidas. Exija senhas mais fortes, MFA, acesso limitado, monitoramento e rotação imediata se houver mudança de acesso.
Senhas fortes não compensam permissões excessivas. Dê aos usuários apenas acesso aos sistemas e segredos necessários para sua função.
Detecte padrões de login fora do comum, viagens impossíveis, tentativas repetidas falhas, acessos de novos países e logins fora do horário habitual. A política de senhas deve ser acompanhada de monitoramento e resposta a incidentes.
O treinamento deve abordar reutilização de senhas, phishing, páginas de login falsas, fadiga de MFA, compartilhamento seguro e como reportar suspeitas de comprometimento. Não culpe o usuário; facilite o comportamento seguro.
A política deve ser compreensível. Se for longa, vaga ou rígida demais, as pessoas darão um jeito de burlar. A melhor política é aquela que pode ser aplicada e seguida na prática.
Use o modelo abaixo como ponto de partida. Ajuste as seções entre colchetes conforme a organização, os sistemas, o nível de risco e os requisitos legais.
Política de Senhas
Versão: [1.0]
Responsável: [Departamento de Segurança / TI]
Data de vigência: [AAAA-MM-DD]
Ciclo de revisão: [A cada 12 meses]
1. Objetivo
Esta política define os requisitos para criação, uso, armazenamento, compartilhamento e alteração de senhas da [Nome da Organização]. O objetivo é reduzir o risco de acesso não autorizado, roubo de credenciais, invasão de contas e perda de dados.
2. Escopo
Esta política se aplica a todos os empregados, prestadores de serviço, funcionários temporários, fornecedores e qualquer usuário que acesse sistemas, aplicações, redes, serviços em nuvem ou dados da [Nome da Organização].
Esta política se aplica a contas de usuários padrão, contas privilegiadas, contas de serviço, contas compartilhadas e qualquer sistema que utilize senhas para autenticação.
3. Requisitos para criação de senhas
Todas as senhas devem cumprir os seguintes requisitos:
- Contas de usuários humanos devem utilizar senhas com pelo menos 16 caracteres.
- Senhas devem ser únicas e não reutilizadas entre contas pessoais ou de trabalho.
- Senhas não devem conter nomes, logins, nomes da empresa, datas de nascimento, padrões de teclado, caracteres repetidos ou informações de fácil adivinhação.
- Senhas não devem ser baseadas em frases, citações ou letras de músicas populares, nem em substituições previsíveis.
- Senhas não podem constar em listas de senhas vazadas ou listas de senhas comuns.
- Senhas podem incluir espaços, símbolos, números, letras maiúsculas e minúsculas.
- Frases-senha são permitidas se forem longas, únicas e não baseadas em frases públicas ou previsíveis.
4. Gerenciadores de senhas
A [Nome da Organização] exige ou recomenda fortemente o uso de um gerenciador de senhas aprovado para criar, armazenar e compartilhar senhas.
Usuários podem utilizar gerador de senhas, preenchimento automático e função copiar-colar pelo gerenciador aprovado. É proibido armazenar senhas em navegadores, planilhas, documentos, aplicativos de notas, e-mail, mensagens de chat, prints ou ferramentas não autorizadas.
5. Autenticação multifator
O MFA deve estar habilitado sempre que tecnicamente viável, incluindo mas não se limitando a:
- Contas de e-mail
- Sistemas de acesso remoto
- Contas de gerenciador de senha
- Serviços em nuvem
- Contas administrativas
- Sistemas financeiros, RH e outros críticos
- Qualquer sistema classificado como [confidencial / crítico]
Quando disponível, usuários devem usar MFA resistente a phishing, como passkeys, chaves físicas de segurança ou autenticadores de plataforma. Aplicativos autenticadores são preferíveis ao SMS. MFA via SMS é proibido se houver outro método tecnicamente possível, podendo ser usado apenas quando não houver opção mais forte.
6. Troca de senhas
As senhas devem ser trocadas imediatamente quando:
- A senha for conhecida ou houver suspeita de comprometimento.
- O usuário digitou a senha em um site suspeito de phishing.
- A senha foi compartilhada com pessoa não autorizada.
- Malware ou acesso não autorizado for detectado no dispositivo.
- A senha aparecer em uma violação de dados conhecida.
- O cargo ou vínculo de um usuário privilegiado mudar.
- A equipe de Segurança ou TI instruir a troca da senha.
A expiração rotineira de senhas não é obrigatória, salvo exigência legal, contratual ou limitação do sistema. Não troque senhas apenas fazendo alterações previsíveis na antiga.
7. Compartilhamento de senhas
Senhas não devem ser compartilhadas via e-mail, chat, tickets, documentos, prints, ligações ou verbalmente.
Credenciais compartilhadas só são permitidas quando contas individuais não forem possíveis ou mediante aprovação explícita da [Segurança / TI]. Credenciais compartilhadas aprovadas devem ser armazenadas e compartilhadas via gerenciador autorizado com acesso restrito a usuários autorizados.
8. Contas privilegiadas
Contas privilegiadas devem ter senhas únicas e não serem reaproveitadas em contas comuns. Devem utilizar MFA sempre que possível e ser revisadas regularmente.
Senhas privilegiadas devem ser trocadas quando um administrador sair da organização, mudar de função, não precisar mais de acesso ou houver suspeita de comprometimento.
9. Contas de serviço e segredos de aplicações
Senhas de contas de serviço, chaves de API, tokens e segredos de aplicações devem ser armazenados em um sistema de gestão de segredos ou gerenciador aprovado.
Credenciais de contas de serviço não devem ser incluídas em código-fonte, arquivos de configuração, imagens, documentação ou scripts, exceto quando protegidas por processo de gestão de segredos aprovado.
10. Redefinição de senha e recuperação de conta
Processos de redefinição devem verificar a identidade do usuário antes da liberação. Links de reset e senhas temporárias devem ser de uso único, expirar rapidamente e ser enviadas por canais aprovados.
Usuários devem ser notificados sempre que uma senha for alterada ou redefinida. Senhas temporárias devem ser trocadas no primeiro acesso.
11. Controles técnicos
Sistemas que armazenam ou processam senhas devem:
- Nunca armazenar senhas em texto claro.
- Hashear senhas usando algoritmos modernos com salt: PBKDF2, scrypt, bcrypt ou Argon2.
- Não utilizar MD5, SHA-1, SHA-256, SHA-512 ou outros hashes rápidos para senhas.
- Proteger pontos de autenticação com limitação de tentativas ou controles equivalentes.
- Rejeitar senhas fracas, comuns ou já comprometidas.
- Permitir que usuários colem senhas de gerenciadores.
- Suportar senhas de ao menos 64 caracteres, quando possível.
- Registrar eventos de autenticação relevantes para segurança.
12. Relato de suspeitas de comprometimento
Usuários devem reportar imediatamente ao [contato da Segurança / TI] casos de suspeita de comprometimento de senha, phishing, prompts de login ou MFA inesperados, ou divulgação acidental de senha.
13. Exceções
Exceções devem ser documentadas, ter risco avaliado, prazo limitado e aprovação da [liderança da Segurança / TI]. Controles compensatórios devem ser aplicados, se possível.
14. Aplicação
O não cumprimento desta política pode resultar em bloqueio de acesso, treinamento obrigatório de segurança, ação disciplinar ou outras medidas previstas nas políticas da [Nome da Organização] e na legislação vigente.
15. Revisão
Esta política deve ser revisada ao menos anualmente ou após mudanças significativas em sistemas, ameaças, exigências legais ou operações de negócio.
Uma política de senhas forte não é sobre dificultar a vida do usuário, mas sim eliminar hábitos frágeis, apoiar o uso de gerenciadores, exigir MFA e agir rápido ao expor credenciais. Mantenha a política prática, aplicável e focada em ataques reais do mundo, como phishing, vazamento de credenciais, reutilização de senha e contas comprometidas.