Trocar de senha todo mês não protege

A regra nasceu em 1985 pedindo um ano, não noventa dias

O documento que inventou prazo de validade de senha é o CSC-STD-002-85, o “Green Book” do Departamento de Defesa americano, de 12 de abril de 1985. Ele diz, na seção 4.2.2.1: “recomenda-se que a validade máxima de uma senha não seja maior que 1 ano”.

E não é chute. O apêndice C traz a fórmula que sustenta o número: P = L × R ÷ S, em que P é a probabilidade de a senha ser adivinhada, L é o tempo em que ela vale, R é quantos chutes por unidade de tempo o atacante consegue dar e S é o tamanho do espaço de senhas. A validade é uma das três variáveis, e só faz sentido junto com as outras duas. Encurtar L era o recurso de quem não podia aumentar S — em 1985, com senhas geradas pelo sistema e um espaço minúsculo.

Ou seja: a regra dos 30, 60 ou 90 dias não vem do documento que inventou a validade de senha. Ele pedia um ano. Os prazos curtos vêm de outro lugar, e dá para apontar o dedo.

Os 42 dias que ninguém escolheu

Abra a política de senha de qualquer domínio Windows antigo e o campo “idade máxima da senha” está em 42 dias. Esse número não foi decidido por ninguém da sua empresa: é o padrão de fábrica da política de domínio documentado pela Microsoft — 42 dias no servidor autônomo, no controlador de domínio e no cliente.

A mesma página, que ainda é a que aparece na busca, se contradiz em dois parágrafos. Em “boas práticas” ela manda “definir a idade máxima da senha entre 30 e 90 dias”. Logo abaixo, numa nota, avisa que “a linha de base de segurança recomendada pela Microsoft não contém a política de expiração de senha, por ser menos eficaz que as mitigações modernas”. As duas frases convivem na mesma tela, e a primeira é a que virou política interna em meio mundo corporativo.

A recomendação atual da Microsoft para contas em nuvem não tem meio termo. Está no guia de política de senha do Microsoft 365: “a configuração recomendada é as senhas nunca expirarem”. E o motivo, na mesma página, serve para o artigo inteiro: “praticamente toda regra que você impõe aos usuários resulta em enfraquecimento da qualidade das senhas”.

A medição que derrubou a regra

Em 2010, três pesquisadores da Universidade da Carolina do Norte publicaram no CCS o primeiro estudo de larga escala sobre o assunto: The Security of Modern Password Expiration. Eles conseguiram 51.141 hashes MD5 de 10.374 contas desativadas da universidade, usadas entre 2004 e 2009, com 4 a 15 senhas gravadas por conta — o histórico inteiro de cada pessoa, em ordem.

A política daquela universidade é a que você provavelmente cumpre hoje: troca obrigatória a cada 3 meses, mínimo de 8 caracteres, obrigação de letra e número, obrigação de caractere especial e proibição de repetir a senha do último ano. Um retrato do padrão corporativo brasileiro, quinze anos antes.

Eles quebraram 31.075 dessas senhas e passaram a fazer a única pergunta que importa: dada uma senha antiga de alguém, dá para adivinhar a próxima? Os números da conclusão:

• 41% das contas tiveram a senha seguinte quebrada a partir da anterior num ataque offline, com esforço médio de menos de 3 segundos por conta num processador de 2,67 GHz — de 2010.
• 17% das contas caíram num ataque online, com menos de cinco tentativas em média. Cinco. É menos que o limite de bloqueio de qualquer sistema.
• Entre as contas que já haviam transformado uma senha em outra alguma vez, a taxa sobe para 63%. Quem fez uma vez, faz de novo.

O motivo é humano e previsível: obrigado a trocar, ninguém inventa uma senha nova. As pessoas transformam a que já existe. Trocam “a” por “@”, sobem a primeira letra, empurram o número do fim para cima — “Marina2024!” vira “Marina2025!”. O estudo transformou essa intuição em algoritmo de busca e mostrou que ela vale para quatro em cada dez contas.

É por isso que a troca forçada pode piorar a situação. Ela não fabrica uma senha desconhecida: fabrica uma senha vizinha da anterior, e o único atacante que ela deveria atrapalhar é justamente o que tem a anterior na mão.

Quanto vale trocar de senha, em bits

Dá para colocar preço nisso, e a conta é curta. Trocar de senha a cada 90 dias significa que, ao longo de um ano, quem já tem sua senha antiga precisa testar 4 variações em vez de uma. Isso multiplica o trabalho dele por 4, o que em bits de entropia é 2. Todo mês, doze variações, 3,58 bits.

Um caractere a mais na senha, no alfabeto de 74 caracteres que o gerador daqui usa com os quatro tipos ligados, compra 6,44 bits. De uma vez, para sempre, e contra qualquer atacante — inclusive contra quem nunca viu senha nenhuma sua.

Os bits das duas últimas linhas são a diferença entre duas chamadas do mesmo bitsDeEntropia que o gerador usa. As duas primeiras linhas são log₂ do número de trocas — e são generosas com a troca periódica, porque assumem que a senha nova não tem relação com a anterior. Quando tem, o número real é o do estudo de 2010: cinco chutes.

Um caractere a mais vale mais que um ano inteiro de trocas trimestrais. Quatro caracteres a mais valem mais que uma década delas. E nenhum deles exige que ninguém decore nada novo em fevereiro.

A política que exige troca costuma aceitar senha de 3 minutos

Aqui está o problema de verdade das políticas brasileiras: elas gastam toda a paciência do usuário na regra que não funciona e liberam a que funcionaria. A tabela abaixo põe lado a lado o mínimo que uma norma de 2025 aceita, o mínimo que o NIST de 2025 exige e o padrão do gerador daqui.

“No chute” é o cenário ruim de propósito: banco de senhas vazado, ataque offline, um trilhão de tentativas por segundo. É a mesma escala de quanto tempo leva para quebrar uma senha, e os números saem do mesmo módulo.

A leitura é essa: a norma exige que você troque de senha quatro vezes por ano para proteger uma senha que cai em 3 minutos. Quinze letras minúsculas, sem símbolo, sem número e sem troca nenhuma, aguentam 27 anos. É por isso que a regra nova do NIST tem tamanho mínimo de 15 e proibição de exigir mistura de tipos: a complexidade que se cobra do usuário rende quase nada, e o tamanho rende tudo.

O que o NIST escreveu, em 2017 e em 2025

Vale ler a evolução, porque o verbo mudou. A revisão 3, de junho de 2017, seção 5.1.1.2, dizia: “Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)”. “Não deveriam”. Recomendação.

A revisão 4, de julho de 2025, seção 3.1.1.2, item 6, virou obrigação: “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised”. “Não devem” — e no vocabulário do NIST, SHALL NOT é proibição, não sugestão.

No mesmo item 5 a mesma revisão proíbe exigir mistura de tipos de caractere. As duas regras que toda política corporativa brasileira aplica — troque a cada 90 dias, use símbolo — são as duas que o documento hoje proíbe impor.

O Reino Unido tinha chegado lá antes. O NCSC publicou em 5 de outubro de 2016 que “quanto mais os usuários são forçados a trocar de senha, maior a vulnerabilidade geral ao ataque”, e listou o porquê: a senha nova costuma ser parecida com a antiga, senha roubada é usada imediatamente, senha trocada tem mais chance de ser anotada num papel, e forçar a troca não dá nenhuma informação sobre se houve invasão.

A porta que a troca deveria fechar já está fechada — ou nunca esteve

A ideia por trás da expiração é elegante: se alguém pegou sua senha sem você saber, a troca expulsa essa pessoa. O problema é o prazo. Quem rouba uma senha usa no mesmo dia, muitas vezes na mesma hora — para mandar phishing dos seus contatos, para pedir Pix, para mexer no que interessa. Esperar 90 dias para expulsar alguém que entrou na terça é chegar três meses atrasado.

E quem entrou não fica dependendo da senha. Cria regra de encaminhamento no email, autoriza um aplicativo, gera uma chave de API, mantém a sessão aberta. Nada disso morre quando você digita uma senha nova. É por isso que a orientação séria não é “troque de tempos em tempos”, e sim: ao suspeitar, troque a senha, encerre todas as sessões e confira o que foi criado enquanto você não estava olhando.

O caso em que a troca é obrigatória continua existindo, e o NIST o escreve na mesma frase em que proíbe o resto: havendo evidência de comprometimento, o sistema deve forçar a troca. A regra não é “nunca troque”. É “troque quando houver motivo”.

Quando trocar de senha de verdade

Vale a pena trocar quando:

• a senha apareceu num vazamento — o fascículo Autenticação do CERT.br é explícito: “ao ficar sabendo que alguma senha sua foi exposta é importante trocá-la imediatamente”;
• você digitou a senha numa página que depois se revelou falsa, ou num computador de terceiro;
• você usou a mesma senha em outro site e aquele site vazou;
• alguém viu você digitando, você contou a senha, ou ela estava anotada em lugar que mudou de dono;
• o serviço avisou de acesso estranho, ou apareceu login de um lugar onde você não estava.

Todos esses têm uma coisa em comum: são eventos. Não é o calendário que dispara a troca, é um fato. E quando o fato acontece, trocar em 30 dias não serve — tem que ser agora.

O que fazer no lugar

A revisão 4 do NIST não só tira a troca periódica: ela diz o que colocar no lugar, e a lista é boa. Para quem opera um sistema:

• Mínimo de 15 caracteres quando a senha é o único fator (8 quando há segundo fator), e permitir até 64. Tamanho é a única regra que rende.
• Comparar a senha nova com uma lista de senhas vazadas e recusar as que estão nela. O Have I Been Pwned oferece isso de graça e sem receber a senha: o site manda só os cinco primeiros caracteres do hash SHA-1 e compara o resto por conta própria.
• Limitar tentativas de login. É o que segura o ataque online, e é o que torna a lista de bloqueio suficiente mesmo sem ser gigante.
• Aceitar gerenciador de senha e o comando colar. O NIST manda permitir os dois. Bloquear o colar não protege nada e empurra a pessoa para a senha que ela consegue digitar de cabeça.
• Nada de pergunta secreta nem de dica de senha visível — os dois estão proibidos na mesma seção.
• Segundo fator. É a medida que sobra quando a senha vaza, e nenhuma política de troca substitui.

Para quem só quer resolver a própria vida: uma senha longa e diferente por serviço, guardada num gerenciador. O CERT.br sugere três palavras aleatórias como receita de memorização, e vale um aviso honesto — três palavras sorteadas da lista que o gerador daqui usa dão ≈30 bits, que esta casa classifica como fraca. Palavra sorteada funciona, mas em quantidade: o padrão daqui é 7.

“Mas a auditoria exige”

Às vezes exige mesmo, e não adianta discutir com o formulário. Dois recados para esse caso.

No Brasil, nenhuma lei manda trocar de senha. A LGPD não usa a palavra “senha” uma única vez — o texto da lei foi contado, não estimado. O art. 46 pede “medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais”, e o § 1º permite que a ANPD publique padrões técnicos mínimos. O guia da própria ANPD para agentes de pequeno porte fala de senha em quatro pontos — complexidade, senha padrão de fábrica, não compartilhar, e o elogio à autenticação em dois fatores — e em nenhum deles pede troca periódica.

O que existe são normas internas. A Norma Complementar nº 12 da ANAC, de 13 de março de 2025, é um exemplo publicado e datado: o art. 15 diz que “as senhas de acesso serão renovadas a cada 90 (noventa) dias” e que quem não trocar tem o acesso bloqueado, enquanto o art. 14 exige oito caracteres com os quatro tipos e proíbe repetir as quatro últimas. Norma interna se revisa por dentro — e a justificativa para revisar está toda neste artigo, com link em cada afirmação.

O caso mais duro é o de quem processa cartão. O PCI DSS, na versão 4, tem o requisito 8.3.9, que trata de senha usada como único fator de autenticação e oferece duas saídas: trocar a cada 90 dias ou analisar dinamicamente a postura de segurança das contas. Está escrito aqui com essa moldura porque não conseguimos abrir o PDF oficial: ele fica atrás do portal do PCI Security Standards Council, com aceite de termos, e responde 403 fora dele. O texto exato do requisito, portanto, não foi lido nesta pesquisa, e quem depende disso deve ler no portal antes de mudar qualquer coisa. Também não citamos a ISO/IEC 27002 em lugar nenhum deste artigo pelo mesmo motivo: é norma paga e não foi lida.

Como esta página foi feita

Os bits e os tempos não foram digitados: saem do mesmo módulo que o gerador de senha usa para desenhar a barra de força, calculados quando esta página é montada. A comparação central — o que a troca compra contra o que um caractere compra — é uma subtração entre duas chamadas da mesma função de entropia, e não duas contas diferentes que poderiam discordar.

As oito fontes da tabela foram abertas no original. Duas não foram, e estão declaradas acima. Se você achar erro em qualquer número desta página, é erro nosso e queremos saber — o endereço está em contato.