Uma autenticação válida demonstra que determinado mecanismo foi satisfeito; não necessariamente quem realizou a operação nem se a transação específica foi conscientemente autorizada.
Em uma frase
Autenticação, controle do autenticador, identidade humana e autorização da transação são proposições diferentes.
Resumo executivo
A expressão “operação autenticada” pode esconder arquiteturas radicalmente diferentes: senha, OTP, token físico ou lógico, biometria local, push approval, certificado, chave criptográfica ou passkey. Para fins periciais, o ponto decisivo é compreender o que o mecanismo realmente prova, como a credencial foi emitida, vinculada e recuperada, e quais registros demonstram sua utilização. Este artigo apresenta uma leitura técnica dos principais mecanismos de autenticação contemporâneos, com base nas diretrizes NIST e no WebAuthn Level 3, e discute os cuidados necessários para transformar eventos de autenticação em evidência processual tecnicamente defensável.
Palavras-chave: autenticação; biometria; token; MFA; WebAuthn; passkeys; fraude bancária.
1. “Autenticado” não responde sozinho à pergunta de autoria
Quando um sistema informa que uma operação foi autenticada, a perícia precisa perguntar: por qual mecanismo, com qual nível de garantia e em qual contexto?
Autenticação é o processo pelo qual um sistema verifica uma alegação de identidade ou posse de credencial. O NIST SP 800-63B-4 diferencia autenticadores e níveis de garantia, reconhecendo que métodos distintos oferecem resistências diferentes a phishing, replay, roubo de credenciais e comprometimento.[1]
Uma senha correta demonstra conhecimento de um segredo. Um OTP demonstra acesso temporário a um canal ou gerador. Uma chave privada demonstra controle operacional daquela chave. Uma biometria pode liberar localmente uma chave, sem que a aplicação receba qualquer dado biométrico. Essas evidências não são intercambiáveis.
2. Três fatores clássicos — e a arquitetura por trás deles
A autenticação costuma combinar fatores de três categorias:
algo que o usuário sabe:
senha, PIN;
algo que possui:
telefone, token, chave criptográfica;
algo que é:
característica biométrica.
O uso de múltiplos fatores tende a elevar a resistência a certos ataques, mas a segurança efetiva depende da independência entre fatores e do processo de recuperação. Um sistema pode exigir MFA no login e, ainda assim, permitir recuperação de conta por um fluxo mais fraco. Em investigação de fraude, o elo mais fraco pode estar justamente na emissão, migração ou reset da credencial.
Por isso, a linha do tempo deveria incluir não apenas a transação, mas também:
emissão inicial do autenticador;
cadastro de novo aparelho;
troca de telefone ou e-mail;
recuperação de conta;
redefinição de senha/PIN;
ativação de token;
inclusão ou remoção de biometria;
revogação de credenciais.
3. Senhas e PINs: conhecimento não é identidade
Senha e PIN são autenticadores baseados em conhecimento. O fato de uma senha correta ter sido usada é relevante, mas não demonstra como ela foi obtida.
Phishing, reutilização de senha, malware, engenharia social, shoulder surfing e compartilhamento voluntário ou involuntário são hipóteses possíveis. A perícia não precisa presumir nenhuma delas; deve procurar registros que as tornem mais ou menos compatíveis com os eventos observados.
Questões úteis incluem número de tentativas, origem das tentativas, mudança recente de senha, método de reset e existência de alertas de risco.
4. OTP, SMS e tokens temporários
One-time passwords possuem vida curta e reduzem o valor de uma senha estática roubada. Contudo, seu valor probatório depende do canal e do desenho do protocolo.
Um OTP por SMS demonstra que o código enviado ao número foi apresentado ao sistema; não necessariamente demonstra quem estava com o telefone. Ataques envolvendo SIM swap, engenharia social e acesso remoto precisam ser tecnicamente distinguíveis quando houver dados disponíveis.
Tokens gerados em aplicativo podem ter propriedades diferentes. É importante saber se a validação foi puramente temporal, vinculada a transação específica, associada ao dispositivo ou combinada a confirmação contextual.
5. Biometria: verificação probabilística e arquitetura local
Biometria costuma ser um dos elementos mais superestimados em documentos técnicos simplificados.
Primeiro, a comparação biométrica é probabilística: um sistema decide se uma amostra é suficientemente semelhante a um template segundo parâmetros de operação. Segundo, em plataformas móveis modernas, o banco pode não receber imagem de face ou impressão digital. O sistema operacional pode realizar a verificação em ambiente protegido e apenas liberar o uso de uma chave ou informar sucesso à aplicação.
Isso é diferente de uma verificação biométrica remota, na qual o prestador recebe uma amostra ou um resultado de matching associado a processo próprio. Em perícia, dizer apenas “houve biometria” sem identificar qual dessas arquiteturas foi usada pode produzir uma conclusão tecnicamente ambígua.
Assim, “autenticado com biometria” pode significar, tecnicamente, “o sistema operacional informou que sua política local de autenticação foi satisfeita”. Para avaliar o peso desse evento, interessa saber:
modalidade biométrica;
onde ocorre o matching;
onde o template é armazenado;
se há fallback por PIN;
se novas biometrias podem ser adicionadas sem revalidação bancária;
qual chave ou operação é liberada após sucesso;
se o banco registra apenas sucesso/falha ou também contexto adicional.
As diretrizes NIST de 2025 reforçaram requisitos e considerações sobre biometria dentro de identidade digital.[1][2] No ambiente Pix, requisitos operacionais de registro de dispositivos e confirmação reforçada de identidade também tornam relevante reconstruir a cronologia de cadastramento do aparelho, especialmente quando ele é novo ou foi alterado próximo à transação.[7]
6. Chaves públicas, passkeys e WebAuthn
A autenticação baseada em chave pública representa mudança importante. Em vez de enviar um segredo compartilhado, o autenticador usa uma chave privada para produzir uma prova criptográfica verificável pelo serviço.
O WebAuthn Level 3, Recomendação W3C publicada em agosto de 2026, define credenciais de chave pública vinculadas ao relying party e mediadas por autenticadores, com mecanismos de assinatura e, quando aplicável, attestation.[3]
Do ponto de vista pericial, isso pode fornecer evidência técnica forte de que determinada credencial criptográfica participou do protocolo. Mas permanece necessário separar:
controle da chave ≠ identidade física de quem acionou o autenticador.
A inferência para autoria humana requer compreensão do desbloqueio do autenticador, do dispositivo, da sincronização de passkeys, do fluxo de recuperação e de eventual comprometimento. Em credenciais sincronizadas, por exemplo, a investigação pode precisar considerar a conta de sincronização, a inclusão de novos dispositivos e o processo de recuperação — não apenas o terminal em que a operação foi observada.
7. Push approval e fadiga de autenticação
Aplicativos bancários e corporativos podem solicitar aprovação por push. Esse modelo facilita a experiência do usuário, mas pode sofrer ataques de MFA fatigue, nos quais múltiplas solicitações são enviadas até que uma seja aprovada por engano ou pressão.
Em uma perícia, o registro “push approved” precisa ser contextualizado:
quantas solicitações ocorreram?
em qual intervalo?
o push mostrava valor e destinatário?
a aprovação exigia biometria/PIN?
o dispositivo estava previamente vinculado?
houve novo login ou recuperação de conta antes do evento?
A semântica do evento é tão importante quanto seu status.
8. Autenticação da sessão e autorização da transação não são a mesma coisa
Outro ponto decisivo é distinguir login de autorização transacional.
Um usuário pode autenticar-se às 10h e realizar transação às 10h40 dentro da mesma sessão. A aplicação pode ou não exigir step-up authentication para determinadas operações. Por isso, é necessário mapear:
início da sessão;
validade da sessão;
reautenticações;
alterações de contexto;
operação que disparou step-up;
credencial usada especificamente para autorizar o pagamento.
Afirmar que uma transferência “teve biometria” exige demonstrar se a biometria se relaciona àquela transação ou apenas ao login anterior.
Uma forma útil de organizar a prova é separar quatro proposições: (1) identidade cadastrada, (2) posse ou controle do autenticador, (3) autenticação da sessão e (4) autorização da transação específica. Cada uma pode estar sustentada por registros diferentes. A evidência de uma etapa não deve ser silenciosamente promovida a prova da etapa seguinte.
9. Que evidência deveria ser preservada
Um pacote tecnicamente útil pode incluir:
identificadores da credencial, sem expor segredo;
data de emissão e vinculação;
histórico de dispositivos;
logs de autenticação e autorização;
mecanismo e assurance level interno;
desafio e resultado criptográfico quando tecnicamente cabível;
eventos de recuperação e reset;
notificações enviadas;
timestamps sincronizados;
identificadores de sessão;
versões do aplicativo e sistema operacional;
logs antifraude associados.
A ISO/IEC 27037 e o NIST SP 800-86 fornecem princípios de identificação, coleta, preservação e análise de evidência digital.[4][5] A ISO/IEC 27042 complementa esse conjunto ao exigir que análise e interpretação sejam suficientemente documentadas para permitir avaliação de validade, reprodutibilidade e repetibilidade.[8]
10. Perguntas periciais que realmente discriminam hipóteses
Em vez de “a biometria confirma a transação?”, perguntas melhores são:
qual autenticador foi usado na operação contestada?
a autenticação ocorreu no login ou na autorização específica?
o mecanismo era phishing-resistant?
houve cadastro ou recuperação recente de credencial?
qual dispositivo mantinha a chave/token?
existe fallback para método menos robusto?
o servidor registra a prova criptográfica ou apenas um status derivado?
o fluxo de recuperação apresenta nível de segurança equivalente ao fluxo normal?
há convergência entre autenticação, dispositivo, rede, sessão e comportamento?
O objetivo não é tornar o laudo mais complexo, mas torná-lo epistemicamente mais claro.
11. Conclusão
A evolução de MFA, biometria, passkeys e autenticação criptográfica aumenta a segurança dos sistemas e pode produzir evidências técnicas muito mais ricas. Mas nenhuma tecnologia elimina a necessidade de interpretação.
A pergunta correta não é apenas “o sistema aceitou a autenticação?”. É: qual credencial foi aceita, em qual etapa, sob quais condições, como ela foi emitida ou recuperada e até onde esse evento permite inferir autoria?
Para litígios bancários, essa distinção é central. A prova técnica se fortalece quando identifica claramente o objeto medido, o protocolo executado, as premissas de segurança e os limites da conclusão.
Referências
NIST.
SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management
. 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final
NIST.
SP 800-63-4: Digital Identity Guidelines
. 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final
W3C.
Web Authentication: An API for accessing Public Key Credentials — Level 3
. W3C Recommendation, 25 Aug. 2026. https://www.w3.org/TR/webauthn/
ISO/IEC.
ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence
. https://www.iso.org/standard/44381.html
NIST.
SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
. https://doi.org/10.6028/NIST.SP.800-86
Banco Central do Brasil.
Segurança no Pix
. https://www.bcb.gov.br/estabilidadefinanceira/pix-seguranca
Banco Central do Brasil.
Instrução Normativa BCB nº 491/2024 — requisitos e procedimentos relacionados ao registro de dispositivos para transações Pix
, versão vigente atualizada em 2025. https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?numero=491&tipo=Instru%C3%A7%C3%A3o+Normativa+BCB
ISO/IEC.
ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence
. https://www.iso.org/standard/44406.html
Nota editorial: autenticação é uma propriedade do protocolo e da credencial; atribuição de autoria humana requer análise contextual e correlação com outras evidências.