FIDO2, passkeys e autenticadores de hardware

Durante décadas, a segurança digital se apoiou em um pressuposto frágil: que os usuários seriam capazes de custodiar segredos de forma consistente em sistemas cada vez mais complexos. Senhas únicas, longas, trocadas periodicamente e nunca reutilizadas. O problema nisso não foi a falta de regras, mas a expectativa irreal de cumprimento humano.

O resultado é conhecido — e um pouco do que eu comentava em Pare de trocar senhas periodicamente : reutilização massiva de credenciais, phishing cada vez mais sofisticado e mecanismos de “duplo fator” que na prática não resistem a um ataque bem executado. Grande parte da segurança moderna ainda se baseia em segredos que podem ser copiados, interceptados ou enganados.

Do ponto de vista técnico, o problema é estrutural. Do ponto de vista filosófico, é ainda mais simples: se algo pode ser copiado sem dificuldade, não pode ser considerado uma prova sólida de identidade.

Nos últimos anos, começou a se popularizar o conceito de passkeys   , uma forma moderna de autenticação definida dentro do padrão FIDO2/WebAuthn   . Uma passkey não é uma senha aprimorada, mas sim um par de chaves criptográficas assimétricas gerado para um serviço específico, em que a chave privada permanece protegida no dispositivo do usuário (hardware dedicado, sistema operacional ou autenticador externo) e a chave pública é armazenada pelo serviço. A autenticação é realizada por meio de assinaturas criptográficas e validação do contexto, eliminando a necessidade de compartilhar segredos reutilizáveis. Essa abordagem é padronizada pela FIDO Alliance e adotada pelos principais sistemas operacionais e navegadores modernos.

Nesse contexto surgem os autenticadores de hardware para armazenar essas passkeys e, em particular, as YubiKey que utilizo no meu dia a dia. Não como uma solução mágica, mas como uma mudança de paradigma: passar de provar o conhecimento de um segredo para provar a posse verificável de um objeto físico, respaldada por criptografia assimétrica e validação do contexto em que ocorre a autenticação.

Este artigo não pretende evangelizar nem vender dispositivos. A intenção é analisar que problema real os autenticadores de hardware resolvem, em quais cenários eles oferecem segurança tangível e onde, simplesmente, adicionam complexidade desnecessária. Porque segurança não se trata de acumular controles, mas de reduzir superfícies de ataque sem perder controle operacional.

O que é um autenticador de hardware (e o que não é)?

Um autenticador de hardware é um dispositivo físico de autenticação projetado para comprovar identidade por meio de mecanismos criptográficos padrão. Ele não armazena senhas de serviços nem atua como um contêiner genérico de segredos. Sua função principal é comprovar presença física e posse de uma chave privada que não pode ser extraída do dispositivo.

Do ponto de vista técnico, um autenticador de hardware como a YubiKey implementa diversos protocolos abertos — principalmente FIDO2/WebAuthn, mas também U2F, OTP, PIV e OpenPGP, dependendo do modelo — que permitem a um sistema remoto verificar identidade sem a necessidade de compartilhar segredos reutilizáveis. A chave privada nunca sai do dispositivo; o único elemento que trafega é uma assinatura criptográfica gerada em resposta a um desafio específico.

Esse detalhe é central: não existe um segredo que possa ser copiado. Diferentemente de uma senha ou de um código TOTP, não há informação que um atacante possa interceptar e reutilizar posteriormente. A autenticação está vinculada tanto ao dispositivo físico quanto ao contexto de uso (por exemplo, o domínio web que solicita a autenticação).

O que é um autenticador de hardware

• Um dispositivo físico que funciona como autenticador baseado em criptografia assimétrica.
• Um mecanismo de prova de posse com verificação de presença física.
• Um segundo fator forte ou, em alguns cenários, o fator principal de autenticação.
• Um componente que pode ser integrado a fluxos modernos de identidade, como Zero Trust ou passwordless.

Em termos práticos, um autenticador de hardware muda o foco da segurança de “algo que você sabe” para “algo que você tem”, reduzindo drasticamente a superfície de ataque associada ao phishing e ao roubo de credenciais.

O que não é um autenticador de hardware

• Não é um gerenciador de senhas.
• Não é um pendrive nem um repositório de segredos em texto claro.
• Não é uma garantia absoluta de segurança.
• Não substitui o desenho correto de acessos, monitoramento ou resposta a incidentes.

Um autenticador de hardware pode fortalecer um sistema mal projetado, mas não consegue corrigir decisões estruturalmente frágeis.

Uma mudança de modelo, não uma melhoria incremental

A diferença mais importante introduzida por um autenticador de hardware não é tecnológica, mas conceitual. Senhas e muitos mecanismos tradicionais de MFA se baseiam em segredos compartilhados. Os autenticadores de hardware rompem com esse modelo: a verificação é realizada sem compartilhar o segredo, e a identidade é validada por meio de uma prova criptográfica vinculada a um objeto físico específico.

Essa mudança de abordagem é o que justifica sua adoção em ambientes onde a identidade é um ativo crítico.

Os protocolos importam mais do que o hardware

Até aqui venho falando principalmente pensando em YubiKeys (e continuarei falando delas neste e em outros artigos do blog, como já disse: é o hardware que utilizo). Mas assumir isso como padrão seria um erro conceitual: a segurança não está na marca, mas nos protocolos que o dispositivo implementa. A YubiKey é relevante porque adota padrões abertos e amplamente suportados, não porque seja um artefato mágico; de fato, existem outros dispositivos com compatibilidade equivalente que mencionarei mais adiante.

De uma perspectiva técnica, o valor de um autenticador de hardware é determinado por dois fatores:

1. quais protocolos ele suporta,
2. como esses protocolos são implementados.

O dispositivo é intercambiável; o protocolo não.

FIDO2 / WebAuthn: o padrão que muda as regras

FIDO2, em conjunto com o WebAuthn, é hoje o protocolo mais relevante em autenticação forte. Ele define um modelo baseado em criptografia assimétrica no qual:

• Cada serviço recebe um par de chaves exclusivo.
• A chave privada nunca sai do dispositivo.
• A autenticação está criptograficamente vinculada ao domínio que a solicita.
• É exigida presença física (e, opcionalmente, PIN ou biometria).

Isso elimina pela raiz classes inteiras de ataques como phishing, replay, credential stuffing e roubo de bases de senhas reutilizáveis.

O ponto importante não é que uma YubiKey suporte FIDO2, mas que qualquer autenticador que o implemente corretamente herda essas propriedades.

U2F: antigo, mas ainda vigente

O U2F é o predecessor do FIDO2. Embora hoje seja considerado “legacy”, ele ainda é amplamente suportado e, do ponto de vista da segurança, continua sendo muito superior ao TOTP ou ao SMS.

Limitações:

• não suporta passwordless
• menor flexibilidade
• menos controle de políticas

Ainda assim, um dispositivo U2F bem implementado continua sendo uma melhoria real em relação a MFAs fracos.

OTP e TOTP: úteis, mas insuficientes

Muitos autenticadores de hardware oferecem geração de códigos OTP ou TOTP. Tecnicamente funcionam, mas conceitualmente não resolvem o problema de fundo:

• continuam sendo segredos reutilizáveis
• são vulneráveis a phishing em tempo real
• não validam contexto nem origem

São um passo intermediário, não um objetivo final. Úteis quando não há outra opção (o caso de muitos serviços hoje em dia), mas não comparáveis ao FIDO2.

PIV / OpenPGP: casos mais especializados

Alguns dispositivos suportam PIV (certificados X.509 / smartcard) e OpenPGP. Esses modos são muito úteis em contextos específicos: autenticação empresarial tradicional, assinatura de código, e-mail criptografado, SSH com chaves não exportáveis, etc.

São casos de uso bem mais técnicos, não pensados para o usuário médio, mas, nesses ambientes com requisitos técnicos específicos, quando bem gerenciados, continuam sendo ferramentas sólidas.

A YubiKey não está sozinha: existem várias alternativas

A YubiKey é provavelmente o dispositivo mais conhecido, mas não é o único nem um requisito para adotar autenticação forte.

Existem alternativas de diferentes portes, como:

• SoloKeys
• Nitrokey
• Google Titan
• Thales SafeNet eToken Fusion

e inclusive autenticadores integrados ao hardware (como o Secure Enclave em dispositivos Apple ou plataformas FIDO integradas). Até mesmo o chip TPM pode ser usado para isso (o Windows Hello utiliza o TPM quando não há um autenticador físico separado).

O fato é que todas essas opções podem ser válidas se implementarem corretamente o FIDO2/WebAuthn, utilizarem padrões abertos e tiverem suporte estável nos serviços utilizados.

A pergunta correta, então, não é “qual marca eu compro?”, mas sim: “Quais protocolos eu preciso, que estejam disponíveis e bem suportados no meu stack?”

Então, por que o FIDO2 é diferente?

A maioria dos mecanismos de autenticação falham pelo motivo que já mencionei: confiam em segredos reutilizáveis. Senhas, códigos OTP, TOTP ou links mágicos são variações do mesmo padrão. A forma muda, mas não a natureza do problema: se o segredo pode ser capturado ou reenviado, ele pode ser vulnerado.

O FIDO2 rompe com esse modelo. E faz isso sem adicionar mais uma camada sobre a senha; ele simplesmente elimina a necessidade de compartilhar um segredo.

Autenticação baseada em desafio, não em segredos

No FIDO2, o fluxo é fundamentalmente diferente dos mecanismos mencionados anteriormente:

1. O serviço gera um desafio criptográfico único.
2. O autenticador assina esse desafio com uma chave privada armazenada em hardware.
3. O serviço valida a assinatura usando a chave pública registrada previamente.

Aqui está um diagrama que ilustra esse fluxo de autenticação:

Portanto, não há informação reutilizável, não há código válido por um determinado período, nem nada que possa ser interceptado. Cada autenticação é um evento único, não a repetição de um segredo pré-existente.

O domínio importa (e isso bloqueia o phishing)

Um dos aspectos centrais do FIDO2 é o binding à origem. O autenticador valida o domínio que solicita a autenticação e só responde se ele corresponder ao domínio para o qual a chave foi gerada.

Isso tem uma consequência direta e prática: um site falso pode parecer idêntico, pode usar HTTPS e até ter um certificado válido, mas não consegue obter uma assinatura válida, porque não controla o domínio legítimo.

Em outras palavras: o phishing deixa de ser um problema de “educação do usuário” e de ferramentas para bloqueá-lo, e passa a ser um problema técnico do atacante. E é exatamente assim que deveria ser. Por isso falamos do FIDO2 como um mecanismo de autenticação resistente a phishing.

Presença física verificável

O FIDO2 exige uma ação física do usuário: tocar o dispositivo, inserir um PIN ou usar biometria (dependendo do autenticador). Isso introduz uma prova de presença que não pode ser automatizada nem simulada remotamente. O usuário participa ativamente do evento de autenticação.

Chaves únicas por serviço

Cada serviço recebe um par de chaves distinto. Isso elimina outro problema histórico: o impacto em cascata no qual se baseiam ataques como credential stuffing. Se um provedor for comprometido, não há credenciais reutilizáveis nem forma de se mover lateralmente para outros serviços. Dessa forma, o comprometimento fica contido por design.

A seguir, um diagrama de como um autenticador é associado a um serviço:

FIDO2 como base para passwordless

Tudo o que foi descrito anteriormente permite algo que, anos atrás, era impraticável em escala: eliminar completamente a senha. Não estamos falando de um ideal teórico, mas sim de uma implementação real que grandes provedores como a Microsoft já estão adotando e impulsionando. O passwordless é uma consequência natural de um modelo de identidade melhor projetado.

Uma reflexão filosófica

Durante anos tentou-se compensar as fraquezas humanas com mais regras, mais complexidade e mais avisos. O FIDO2 propõe o oposto: aceitar as limitações humanas e projetar o sistema em torno delas.

Não se trata de confiar que o usuário não cairá em um engano. Trata-se de construir um sistema no qual cair em um engano não seja suficiente para comprometer a identidade. Na minha opinião, trata-se de uma correção conceitual importante e necessária.

Usos reais: onde um autenticador de hardware oferece segurança tangível

Nem todos os sistemas se beneficiam igualmente de um autenticador de hardware. Em alguns casos, o impacto é marginal, embora em outros, representa um grande avanço na segurança da identidade. Como você pode imaginar, a diferença não está na tecnologia, mas em qual risco se está tentando reduzir.

Não vou listar tudo o que pode ser feito com esses dispositivos, mas sim alguns casos que realmente valem a pena. Em artigos futuros, pretendo desenvolver estes e outros cenários de uso.

Proteção de contas críticas

As contas que permitem recuperar outras contas — principalmente o e-mail e o gerenciador de senhas — são o ponto de partida lógico.

Aplicar o FIDO2 nesses serviços tem um efeito imediato: o phishing deixa de ser viável, o roubo de sessão se torna drasticamente mais difícil e o impacto de um comprometimento é reduzido.

Nesse contexto, com uma boa implementação, um autenticador de hardware não atua como “segundo fator”, mas como uma âncora de identidade. Se o atacante não tiver o dispositivo físico, o acesso simplesmente não acontece.

Controle de acesso a repositórios e código

Plataformas como GitHub ou GitLab concentram um volume crescente de ativos críticos: código, pipelines, segredos, tokens e acessos à infraestrutura.

O uso de FIDO2 ou de chaves não exportáveis para login, assinatura de commits ou acesso a runners ou APIs reduz riscos concretos de sequestro de identidade, ataques à cadeia de suprimentos ou introdução de código malicioso com autoria aparentemente legítima.

Acesso à infraestrutura e a sistemas administrativos

Em ambientes de servidores, cloud ou redes, a autenticação forte tem um retorno claro.

Alguns casos típicos incluem:

• SSH com chaves FIDO2 não exportáveis
• bastiões de acesso
• painéis administrativos
• provedores de VPS ou DNS

A diferença em relação às chaves tradicionais é fundamental: o segredo não pode ser copiado, mesmo que o sistema a partir do qual se acessa esteja comprometido.

Linux e controle local do sistema

Este é um caso que utilizei e explorei particularmente, pois em sistemas GNU/Linux um autenticador pode ser integrado para além do navegador:

• sudo com verificação de presença
• login local via PAM
• desbloqueio de volumes criptografados (LUKS)
• assinatura GPG a partir de hardware

Esses usos são especialmente relevantes em laptops, estações de trabalho móveis ou contextos em que o controle físico não é absoluto, pois permitem elevar o custo real de um comprometimento local. Vale esclarecer que vários desses casos têm equivalentes em sistemas Windows, com o Windows Hello e ferramentas de terceiros.

Quando não agrega valor real

Acredito que saber em quais casos não faz sentido adotar um autenticador de hardware é tão importante quanto saber onde ele realmente agrega valor.

Em geral, não se justifica adotar esse tipo de autenticação em:

• sistemas de baixo impacto
• acessos efêmeros sem privilégios
• ambientes sem suporte adequado a protocolos
• substituição de controles básicos mal implementados

Adicionar hardware sem um objetivo claro costuma introduzir fricção sem melhorar a segurança.

Uma regra prática

Se uma conta permite:

• recuperar outras contas
• executar código
• modificar infraestrutura
• acessar dados sensíveis

então ela justifica autenticação forte baseada em hardware. Caso contrário, provavelmente não.

Esses dispositivos e as passkeys não foram pensados para serem usados em todos os lugares, mas sim nos pontos onde a identidade é crítica. É aí que a mudança de modelo introduzida pelo FIDO2 se traduz em uma melhoria de segurança concreta e mensurável.

Erros comuns e más decisões

A adoção de autenticadores de hardware costuma falhar não por limitações técnicas, mas por decisões mal compreendidas. Em muitos casos, o autenticador acaba virando um amuleto de segurança: está presente, mas não altera o modelo de risco.

Usar apenas uma chave

Este é provavelmente o erro mais comum. Um dispositivo como uma YubiKey é um objeto físico (e bastante pequeno). Objetos físicos se perdem, quebram ou ficam inacessíveis. Usar apenas uma chave, sem um método alternativo de recuperação, é uma receita para bloqueio permanente.

Boas práticas mínimas:

• pelo menos dois autenticadores registrados
• um de uso diário
• um de reserva, armazenado offline

Substituir completamente a passphrase sem backup

Eliminar senhas sem um plano de recuperação é passar de passwordless para irrecuperável.

Em serviços críticos ou em cenários de criptografia local, é importante manter um método alternativo (passphrase, chave de recuperação), documentar o processo de recuperação e testá-lo antes de realmente precisar dele.

Usar OTP “porque é o que tem”

Gerar códigos OTP a partir de uma YubiKey é melhor do que SMS, mas não altera o modelo de ameaça. O código continua sendo um segredo reutilizável, suscetível a phishing em tempo real.

Esse erro costuma surgir quando o serviço oferece suporte ao FIDO2, mas ele não é habilitado, ou quando se prioriza compatibilidade em detrimento da segurança. Porém, se o protocolo não elimina a classe de ataque, o benefício é limitado.

Acreditar que o FIDO2 substitui outros controles

O FIDO2 protege a identidade, não o sistema como um todo.

Ele não substitui:

• monitoramento
• detecção de comprometimentos
• gestão de privilégios
• separação de funções
• resposta a incidentes

Um atacante ainda pode ser eficaz se obtiver privilégios indevidos por outros meios. É fundamental entender que a autenticação forte é uma base, não uma defesa completa.

Não entender qual protocolo está sendo utilizado

Muitas implementações falham por desconhecimento: acreditar que MFA implica automaticamente resistência a phishing, não distinguir entre diferentes protocolos e assumir que todos os fluxos são equivalentes é um erro.

O resultado é uma falsa sensação de segurança baseada em rótulos, e não em propriedades reais do protocolo.

Não proteger o canal de recuperação

O ponto mais fraco costuma ser o mecanismo de recuperação de conta.

De pouco adianta usar FIDO2 se:

• a recuperação continua sendo via e-mail + SMS
• é permitido fazer downgrade para MFA fraco
• o suporte pode redefinir acessos sem verificação forte

A segurança deve ser avaliada pelo caminho mais fácil, não pelo mais robusto.

Introduzir fricção sem um objetivo claro

Em um mundo ideal, poderíamos adotar autenticação forte em todos os sistemas, mas no mundo real adicioná-la a sistemas de baixo impacto ou sem privilégios reais costuma gerar rejeição e abandono.

A autenticação forte deve ser aplicada onde o impacto de um comprometimento é alto, a identidade é um ativo crítico e a fricção é justificada.

Conclusão

O erro mais comum ao falar de segurança é pensá-la como uma soma de controles. Mais fatores, mais regras, mais avisos. Na prática, isso costuma produzir sistemas frágeis, difíceis de operar e fáceis de contornar pelo caminho menos esperado.

Um modelo mental mais útil parte de outra premissa: a identidade é um sistema, não um dado.

As senhas falham não porque sejam curtas ou reutilizadas, mas porque são segredos copiáveis. Não importa quantas vezes sejam trocadas ou quantos fatores sejam adicionados ao redor delas; enquanto o modelo depender de algo que pode ser interceptado e reutilizado, o problema persiste.

O FIDO2 introduz uma correção conceitual simples porém profunda: a identidade não é demonstrada compartilhando um segredo, mas provando posse e contexto por meio da criptografia. Não se confia que o usuário memorize melhor, e sim em propriedades matemáticas e na impossibilidade prática de copiar um objeto físico ou algo armazenado em um chip criptograficamente robusto.

Os autenticadores de hardware não são uma solução universal nem um requisito para todos os sistemas. Seu valor aparece quando a identidade passa a ser um ativo crítico.

Usados corretamente, eles permitem:

• eliminar o phishing como vetor efetivo
• reduzir o impacto de comprometimentos parciais
• simplificar modelos de acesso complexos
• habilitar passwordless sem perder controle

Usados de forma incorreta, tornam-se apenas mais uma camada de fricção, sem benefícios proporcionais.

A diferença não está no dispositivo, mas em como o problema é pensado. Adotar o FIDO2 é uma decisão de arquitetura: aceitar que os sistemas devem ser projetados em função das limitações humanas, e não contra elas. Nesse contexto, os autenticadores de hardware não são um fim em si mesmos, mas uma ferramenta bem definida para um problema concreto. E, como toda boa ferramenta, seu valor não está em possuí-la, mas em saber exatamente quando e por que usá-la.

Referências

• YubiKey 5 Series – Technical Manual Documentação oficial sobre os protocolos suportados pela YubiKey (FIDO2, U2F, PIV, OpenPGP, OTP etc.). https://docs.yubico.com/hardware/yubikey/yk-tech-manual/yk5-intro.html  

• Yubico – Authentication Standards (FIDO2 / WebAuthn) Visão geral do padrão FIDO2 e de seu uso para autenticação sem senha. https://www.yubico.com/authentication-standards/fido2/  

• WebAuthn – W3C Recommendation Especificação oficial do padrão WebAuthn, base técnica do FIDO2 e das passkeys. https://www.w3.org/TR/webauthn/  

• FIDO Alliance – Passkeys Definição e explicação do conceito de passkeys dentro do ecossistema FIDO2. https://fidoalliance.org/passkeys/  

• Yubico – WebAuthn Developer Guide Guia técnico para compreender os fluxos de registro e autenticação com FIDO2/WebAuthn. https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/  

• IBM – What is FIDO2? Explicação clara do modelo FIDO2, CTAP e WebAuthn. https://www.ibm.com/think/topics/fido2