Autenticação, senhas e múltiplos fatores

Autenticação demonstra controle de um autenticador

Autenticação digital é o processo pelo qual alguém demonstra controlar um ou mais autenticadores vinculados a uma conta. Ela não pergunta apenas “qual nome foi informado?”, mas busca evidência de que o solicitante é o titular esperado daquela identidade digital.

Um autenticador é um meio usado para demonstrar o controle de um fator de autenticação. Uma senha, um dispositivo que guarda uma chave criptográfica e um aplicativo capaz de gerar códigos são exemplos diferentes. Cada um possui ameaças, limitações e formas de recuperação próprias.

Autenticação não determina, por si só, o que a conta pode fazer. A aula sobre controle de acesso e princípio do menor privilégio é a referência para autorização. Aqui, o foco está na etapa anterior: como verificar a identidade digital com uma garantia proporcional ao risco?

Identidade passa por etapas diferentes

Termos próximos representam problemas distintos:

• identificação: a entidade apresenta um identificador, como nome de usuário;
• prova de identidade: uma organização relaciona uma pessoa real à identidade declarada com determinado nível de confiança;
• inscrição: a identidade é registrada em uma conta e autenticadores são vinculados a ela;
• autenticação: em um acesso posterior, a pessoa demonstra controlar os autenticadores vinculados;
• autorização: o sistema decide quais recursos e operações aquela identidade pode usar.

Nem todo serviço precisa conhecer a identidade civil de uma pessoa. Um fórum pode aceitar uma conta pseudônima, enquanto um serviço financeiro pode exigir prova de identidade mais robusta. O nível adequado depende dos danos possíveis se a pessoa errada for inscrita, autenticada ou autorizada.

Confundir essas etapas cria controles frágeis. Apresentar um documento sem verificar sua legitimidade não prova identidade. Conhecer um e-mail não autentica seu titular. Entrar corretamente não autoriza qualquer operação. Cada decisão precisa de evidência apropriada ao seu objetivo.

Fatores respondem ao que a pessoa sabe, possui ou é

Os fatores de autenticação são agrupados em três categorias:

• algo que você sabe: senha, frase secreta ou PIN;
• algo que você possui: dispositivo, cartão ou chave que contém um segredo criptográfico;
• algo que você é: característica biométrica, como impressão digital ou face, usada em uma comparação.

O fator não é o objeto aparente, mas a propriedade demonstrada. Receber um código no celular busca demonstrar controle de um canal ou dispositivo; digitar uma senha demonstra conhecimento do segredo. Um PIN que desbloqueia localmente uma chave não é enviado como segunda senha ao serviço: ele ativa o autenticador que guarda o fator de posse.

No modelo da SP 800-63B-4, uma característica biométrica não é considerada um autenticador isolado. Ela é usada junto a um autenticador físico — por exemplo, uma biometria local que ativa uma chave protegida no dispositivo. Essa distinção importa porque características biométricas podem ser observadas, copiadas e não são substituídas com a facilidade de uma senha.

MFA exige categorias diferentes

Autenticação multifator, ou MFA, exige evidência de pelo menos dois fatores de categorias diferentes. Dois elementos de conhecimento continuam sendo um único fator. Portanto:

• senha + pergunta secreta: não é MFA; ambos são conhecimento;
• senha + PIN enviado ao mesmo processo como outro segredo memorizado: não é MFA se ambos apenas provam conhecimento;
• senha + código produzido por dispositivo vinculado: pode formar MFA por conhecimento e posse;
• dispositivo com chave + biometria local para ativá-lo: pode formar um autenticador multifator por posse e inerência;
• duas senhas diferentes: não é MFA.

A independência é importante. Se a mesma fraude, dispositivo comprometido ou processo de recuperação entrega todos os fatores ao mesmo tempo, a combinação oferece menos proteção do que parece. Desenhar MFA exige observar como cada fator é cadastrado, armazenado, usado, substituído e recuperado.

Senha continua útil, mas não resolve tudo

Senhas são fatores de conhecimento amplamente usados. Seu valor depende tanto da escolha do usuário quanto do comportamento do serviço que as recebe e verifica. Uma senha longa e exclusiva pode reduzir adivinhação e reutilização, mas continua exposta a phishing, captura no dispositivo e vazamento do verificador.

A versão final da NIST SP 800-63B-4, publicada em julho de 2025, orienta verificadores no contexto de identidade digital do governo federal dos Estados Unidos. Entre suas recomendações para senhas verificadas centralmente estão:

• exigir pelo menos 15 caracteres quando a senha for o único fator;
• permitir pelo menos 64 caracteres como comprimento máximo aceito;
• não impor regras de composição como mistura obrigatória de maiúsculas, números e símbolos;
• não exigir troca periódica sem evidência de comprometimento;
• comparar novas senhas com uma lista de valores comuns, esperados ou comprometidos;
• limitar tentativas malsucedidas;
• permitir gerenciadores, preenchimento automático e colagem;
• armazenar verificadores de senha com salt e função de derivação ou hash apropriada.

Esses números e requisitos não são uma lei universal de senha. Eles pertencem a uma publicação versionada e precisam ser avaliados junto a obrigações, ameaças, experiência de uso e arquitetura do serviço. A lição evergreen é mais ampla: favorecer comprimento e exclusividade, bloquear escolhas previsíveis, evitar regras que incentivem padrões e proteger a verificação no servidor.

Troca periódica pode criar padrões previsíveis

Obrigar mudanças frequentes sem sinal de comprometimento costuma levar a variações previsíveis, anotações inseguras e reutilização. Mudar “Projeto2026!” para “Projeto2027!” cumpre uma rotina, mas pouco altera a capacidade de adivinhação.

A troca faz sentido quando há evidência de exposição, uso em serviço comprometido, compartilhamento indevido ou outro evento que reduza a confiança no segredo. Ela deve vir acompanhada de investigação, revogação de sessões quando necessária e correção da causa — não apenas de um novo valor.

Perguntas secretas baseadas em fatos pessoais também são frágeis. Respostas podem ser públicas, pesquisáveis, compartilhadas ou fáceis de adivinhar. No contexto da SP 800-63B-4, não devem ser usadas como mecanismo para escolher ou recuperar senhas.

Usuário e verificador possuem responsabilidades diferentes

Para quem usa o serviço, boas práticas duradouras incluem:

• criar senha exclusiva para cada conta;
• preferir comprimento a padrões artificiais de complexidade;
• não compartilhar senha, código temporário ou aprovação de acesso;
• habilitar MFA disponível e manter métodos de recuperação protegidos;
• reagir a alertas de acesso, cadastro de autenticador e recuperação não reconhecidos.

Para quem opera o serviço, pedir uma “senha forte” não basta. O verificador precisa usar canal protegido, limitar tentativas, rejeitar valores previsíveis, proteger o armazenamento, evitar vazamento em logs e oferecer formas seguras e acessíveis de uso e recuperação.

O Service Desk pode orientar e registrar uma solicitação, mas não deve coletar senha ou código de autenticação como evidência. Processos de suporte precisam permitir assistência sem transformar o atendente em destinatário de segredos.

Gerenciadores ajudam a manter senhas exclusivas

Um gerenciador de senhas armazena credenciais em um cofre protegido e pode gerar valores longos e aleatórios para cada serviço. Isso reduz a carga de memorizar dezenas de segredos e dificulta a reutilização em vários sites.

O gerenciador não elimina risco. A conta ou o dispositivo que protege o cofre merece autenticação robusta, recuperação planejada, atualizações e cópias adequadas quando aplicável. Ainda assim, exigir que cada pessoa memorize uma senha complexa e exclusiva para cada serviço cria uma expectativa pouco realista; permitir gerenciadores e colagem melhora segurança e usabilidade.

O preenchimento vinculado ao domínio também pode ajudar a perceber páginas imitadoras, pois um gerenciador não deveria oferecer a credencial em um endereço diferente. Essa ajuda não equivale, por si só, a um protocolo resistente a phishing.

Garantia deve acompanhar o risco da jornada

Nem toda ação produz o mesmo dano. Consultar um calendário público, acessar dados internos e alterar o meio de pagamento da organização exigem níveis diferentes de confiança. Aplicar o mecanismo mais pesado em toda interação pode prejudicar acessibilidade e levar a atalhos; aplicar somente senha em toda situação concentra o risco.

Uma abordagem proporcional combina:

• consequência de autenticação indevida;
• valor e sensibilidade do recurso;
• possibilidade de fraude, captura e repetição;
• contexto da sessão e do dispositivo;
• usabilidade, acessibilidade e disponibilidade dos métodos;
• capacidade segura de recuperação.

Autenticação escalonada ou step-up solicita garantia adicional quando a sessão tenta uma operação mais sensível. Uma sessão comum pode acessar funções de baixo risco, enquanto alteração de dados bancários exige novo gesto com autenticador mais forte. Isso não substitui autorização: primeiro se eleva a confiança na autenticação; depois a política ainda decide se a identidade pode executar a ação.

MFA não significa automaticamente resistência a phishing

Um código temporário digitado manualmente pode adicionar um fator de posse e impedir que apenas a senha seja suficiente. Porém, uma página imitadora pode capturar senha e código e repassá-los imediatamente ao serviço legítimo. Por isso, “possui MFA” e “é resistente a phishing” não são afirmações equivalentes.

Resistência a phishing é a capacidade do protocolo de impedir que um verificador impostor obtenha segredos ou respostas válidas, sem depender apenas da atenção da pessoa. A SP 800-63B-4 reconhece métodos criptográficos que vinculam a resposta ao canal ou ao nome do verificador. Autenticadores com saída digitada manualmente, como certos códigos de uso único, não possuem esse vínculo e não são classificados como resistentes a phishing.

Isso não torna qualquer MFA inútil. A escolha é uma decisão de risco: um segundo fator pode melhorar muito uma conta que dependia apenas de senha, enquanto operações de maior impacto podem justificar uma opção criptográfica resistente a phishing. A aula sobre engenharia social e phishing aprofunda como mensagens enganosas exploram contexto e urgência.

Recuperação de conta faz parte da autenticação

Quando alguém perde o dispositivo, esquece a senha ou deixa de controlar um autenticador, precisa vincular um novo meio à conta. Se a recuperação for muito mais fraca que o acesso normal, ela se torna o caminho preferido para assumir a identidade.

A SP 800-63B-4 reconhece classes como códigos de recuperação armazenados, códigos enviados a endereços previamente verificados, contatos de recuperação e repetição de parte da prova de identidade. O método adequado depende do risco e do nível de garantia da conta.

Um processo consistente deve:

1. oferecer mais de uma opção acessível quando possível;
2. verificar a solicitação com evidência proporcional;
3. invalidar ou retirar o autenticador perdido;
4. vincular o novo autenticador com proteção adequada;
5. encerrar ou revisar sessões de risco;
6. notificar o titular por canal previamente estabelecido;
7. registrar a mudança para investigação e suporte.

Recuperação não deve depender de informações pessoais fáceis de descobrir nem permitir que um atendente contorne controles por pressão. Exceções precisam de política, supervisão e trilha verificável.

Três jornadas, três decisões de garantia

Considere uma conta corporativa de Lara:

1. Acesso comum: Lara entra no portal interno com senha exclusiva e dispositivo vinculado. O serviço limita tentativas, protege a sessão e registra eventos relevantes.
2. Operação sensível: para alterar dados bancários de um fornecedor, o sistema exige nova autenticação com método resistente a phishing e intenção explícita. Depois, a autorização confirma se o papel de Lara permite solicitar — mas não aprovar — a alteração.
3. Recuperação: após perder o dispositivo, Lara usa um código de recuperação guardado separadamente e passa por validações adicionais. O dispositivo perdido é revogado, sessões são revistas e uma notificação é enviada por canal previamente confirmado.

O cenário combina risco, autenticação e autorização sem fundi-los. A autenticação aumenta a confiança sobre quem controla a conta; a autorização limita a ação; registros e alertas ajudam a detectar uso indevido; recuperação restaura o controle legítimo.

Ciclo de vida inclui cadastro, uso e revogação

Autenticadores precisam ser gerenciados desde o vínculo até a retirada. Cadastrar um novo dispositivo, alterar endereço de recuperação ou gerar novos códigos pode ser tão sensível quanto autenticar. Essas mudanças devem exigir uma sessão suficientemente confiável, produzir notificações e permitir reação a fraude.

Também é importante manter alternativas. Pessoas podem perder um dispositivo, não conseguir usar biometria, ficar sem conectividade ou precisar de tecnologia assistiva. Segurança e acessibilidade não são objetivos opostos: múltiplas opções com garantia comparável tornam o sistema mais resiliente e inclusivo.

Erros comuns em autenticação

• tratar usuário e senha como dois fatores: o identificador não é segredo, e a senha é apenas conhecimento;
• usar duas senhas e chamar de MFA: duas evidências da mesma categoria continuam sendo um fator;
• confundir biometria com segredo imutável: características biométricas podem ser observadas e não são facilmente substituídas;
• forçar troca periódica sem motivo: a rotina pode incentivar padrões previsíveis;
• bloquear colagem e gerenciadores: isso dificulta senhas longas e exclusivas;
• considerar qualquer MFA resistente a phishing: códigos digitados podem ser repassados a um impostor;
• proteger o login e enfraquecer a recuperação: o caminho alternativo passa a dominar o risco;
• esquecer contas técnicas: serviços e aplicações também precisam de autenticadores, rotação e revogação adequadas;
• achar que autenticação concede acesso: a autorização ainda precisa limitar recursos e operações.

O que você deve guardar

• Identificação, prova de identidade, inscrição, autenticação e autorização são decisões diferentes.
• Autenticação demonstra controle de autenticadores vinculados à conta.
• Fatores pertencem às categorias conhecimento, posse e inerência; MFA combina categorias distintas.
• Senhas devem favorecer comprimento e exclusividade, enquanto o verificador precisa proteger tentativa, transmissão e armazenamento.
• Trocas periódicas sem evidência de comprometimento e regras artificiais de composição podem piorar o comportamento.
• MFA reduz dependência de uma única barreira, mas apenas alguns métodos são resistentes a phishing.
• Operações sensíveis podem exigir autenticação escalonada sem substituir autorização.
• Recuperação, cadastro e revogação de autenticadores fazem parte do mesmo ciclo de segurança.

Na aula sobre criptografia, hash e assinatura digital, veremos como esses mecanismos resolvem problemas diferentes. Esse aprofundamento ajuda a compreender as chaves mencionadas aqui sem transformar autenticação e criptografia em sinônimos.

Referências

• NIST — SP 800-63-4: Digital Identity Guidelines. Acesso em 28 ago. 2026.
• NIST — SP 800-63A-4: Enrollment and Identity Proofing. Acesso em 28 ago. 2026.
• NIST — SP 800-63B-4: Authentication and Authenticator Management. Versão final de julho de 2025. Acesso em 28 ago. 2026.
• NIST — Digital Identity Model. Acesso em 28 ago. 2026.
• CISA — Secure Our World. Acesso em 28 ago. 2026.