Contexto
“Confirmar senha” pode significar duas coisas diferentes: repetir uma nova senha para detectar erro de digitação ou comprovar novamente a identidade antes de uma ação sensível. Esses usos não devem ser tratados como a mesma regra.
Na criação ou redefinição, um segundo campo acrescenta esforço e pode atrapalhar gerenciadores de senhas. Em muitos casos, permitir revelar a senha é suficiente para conferi-la. Em alterações críticas, porém, a sessão aberta pode não provar que a pessoa presente ainda é a titular; por isso, pode ser necessário pedir a senha atual, um fator adicional ou outra forma de reautenticação proporcional ao risco.
Defina primeiro o objetivo da confirmação. Se a intenção é evitar erro ao criar uma senha, prefira um único campo com opção de mostrar e ocultar, requisitos visíveis e validação clara. Adicione “Confirmar nova senha” somente quando o custo de cadastrar um valor diferente do pretendido superar o esforço adicional.
Se a intenção é autorizar uma ação sensível, solicite reautenticação no momento da ação. A senha atual pode ser adequada em contas baseadas em senha e sessões de menor risco; para alterar e-mail principal, senha, métodos de recuperação, MFA, dados financeiros ou permissões, avalie um fator adicional ou autenticação resistente a phishing.
Explique por que a confirmação é necessária antes do campo. Diferencie “Senha atual”, “Nova senha” e “Confirmar nova senha”; permita colar e preencher com gerenciadores; use os propósitos programáticos corretos: current-password para a senha existente e new-password para a nova senha e sua eventual confirmação.
Valide a correspondência sem apagar valores, informe o erro junto ao campo e não peça credenciais mais vezes do que o risco exige. Depois de uma alteração crítica, confirme o resultado e notifique a pessoa por um canal confiável.
Porque isso importa?
Campos repetidos não garantem que a pessoa escolheu uma boa senha: ela pode repetir o mesmo erro, colar o mesmo valor ou abandonar o fluxo. O GOV.UK conclui que o segundo campo não é necessário em especial quando a interface permite mostrar a senha.
Em contrapartida, uma sessão autenticada pode estar aberta em um dispositivo abandonado ou comprometido. A OWASP recomenda reautenticação após eventos de risco e antes de ações críticas, escolhendo o mecanismo de acordo com o contexto. O NIST também trata reautenticação como confirmação da presença contínua da pessoa em uma sessão.
Acessibilidade e segurança convergem quando o produto permite colar, usar preenchimento automático e gerenciadores. A WCAG 2.2 considera problemático obrigar memorização ou transcrição quando não há alternativa e reconhece o preenchimento programático como apoio importante.
Quando usar?
- Ao alterar senha, e-mail principal ou métodos de recuperação.
- Ao desativar MFA ou adicionar dispositivo confiável.
- Antes de visualizar ou modificar dados muito sensíveis.
- Em transações ou permissões de alto impacto.
- Após inatividade, recuperação de conta ou atividade suspeita.
- Ao criar senha sem forma confiável de revisar o valor.
- Quando testes mostrarem erros relevantes de digitação.
Quando evitar?
- Como segundo campo obrigatório em todo cadastro.
- Quando mostrar a senha já permite conferência suficiente.
- Em ações rotineiras de baixo risco.
- Logo após uma autenticação forte ainda válida.
- Quando a senha não é o melhor fator disponível.
- Para compensar rótulos, mensagens ou requisitos ruins.
- Quando a repetição bloqueia gerenciadores de senhas.
Recomendações
Faça
- Defina o risco da ação.
- Explique o motivo.
- Nomeie cada senha claramente.
- Prefira mostrar e ocultar.
- Permita colar.
- Aceite gerenciadores.
- Use autocomplete correto.
- Valide sem apagar.
- Notifique mudanças críticas.
Evite
- Não repita por padrão.
- Não bloqueie a colagem.
- Não peça a senha em excesso.
- Não confunda senha atual e nova.
- Não dependa só da sessão.
- Não use senha onde MFA é necessário.
- Não apague valores após erro.
- Não revele credenciais em mensagens.
