Contexto
Os requisitos de senha fazem parte da tarefa, não são uma surpresa depois do envio. A pessoa precisa saber o que será aceito antes de criar a senha, com linguagem simples e feedback que acompanhe o preenchimento.
Como princípio, priorize comprimento, bloqueio de senhas comuns ou comprometidas e compatibilidade com gerenciadores. Evite regras de composição que só parecem rigorosas, mas induzem padrões previsíveis e dificultam a memorização.
Mostre os requisitos junto ao campo antes da pessoa começar a digitar. Separe o que é obrigatório de dicas opcionais e atualize o estado de cada requisito à medida que ele for atendido. Não faça a pessoa descobrir as regras em uma mensagem depois do envio.
Defina a política com segurança e informe os limites reais. Como referência, o NIST SP 800-63B-4 estabelece mínimo de 15 caracteres para senhas usadas como fator único e permite mínimo de 8 quando a senha faz parte de um fluxo com múltiplos fatores; a aplicação deve seguir seu nível de risco e a norma aplicável. Permita senhas longas, passphrases, espaços e caracteres suportados pelo sistema, sem truncar silenciosamente.
Prefira bloquear senhas comuns, previsíveis ou encontradas em bases de comprometimento a exigir combinações arbitrárias de maiúsculas, minúsculas, números e símbolos. Se uma senha for recusada, diga o motivo em termos acionáveis, sem revelar qual regra interna ou dado sensível foi usado para a decisão.
Permita colar, preencher automaticamente e usar gerenciadores de senha. Ofereça mostrar ou ocultar a senha com um controle acessível. Valide no cliente para orientar e no servidor para garantir a regra; os dois lados devem usar a mesma política.
Porque isso importa?
Requisitos ocultos transformam a criação da senha em tentativa e erro. A pessoa pode preencher o formulário inteiro, receber uma rejeição tardia e não saber qual parte precisa mudar.
O NIST e a OWASP desaconselham regras de composição sem justificativa, porque elas oferecem benefício menor do que se imagina e incentivam alterações previsíveis, como acrescentar um número ou símbolo. Comprimento, bloqueio de senhas comprometidas e suporte a passphrases tendem a comunicar melhor a política real.
O Baymard documenta que feedback inline e positivo ajuda a detectar problemas enquanto a entrada ainda está recente. O W3C também orienta que campos de autenticação tenham nome acessível, permitam colar e possam ser reconhecidos por navegadores e gerenciadores. O resultado é uma tarefa mais compreensível, segura e recuperável.
Quando usar?
- Na criação de uma conta.
- Ao trocar a senha.
- Durante a recuperação de acesso.
- Em convites para novos usuários.
- Ao configurar um novo fator de autenticação.
- Quando a política de segurança mudar.
- Durante a digitação, se o feedback não interromper.
- Antes do envio, para confirmar a regra completa.
Quando evitar?
- Depois do envio como único feedback.
- Com uma lista longa de regras técnicas.
- Com combinações sem base no risco.
- Com limite máximo curto ou oculto.
- Ao bloquear colar ou gerenciadores.
- Ao rejeitar espaços sem necessidade.
- Com medidor sem explicação.
- Usando apenas cor ou ícone.
Recomendações
Faça
- Mostre antes de digitar.
- Priorize comprimento.
- Bloqueie senhas comprometidas.
- Aceite passphrases.
- Indique cada estado.
- Informe os limites.
- Permita colar.
- Suporte gerenciadores.
- Ofereça mostrar senha.
- Valide no servidor.
Evite
- Não esconda requisitos.
- Não valide só no envio.
- Não exija classes sem base.
- Não imponha limite curto.
- Não bloqueie colar.
- Não rejeite espaços sem motivo.
- Não use medidor opaco.
- Não dependa de cor.
- Não mude a regra no servidor.
