Passkeys: por que a autenticação sem senha ainda confunde os usuários

O que são passkeys

Passkeys são credenciais digitais que substituem senhas tradicionais usando criptografia de chave pública. Em vez de você criar e lembrar uma senha, o seu dispositivo gera um par de chaves: uma pública, enviada ao servidor, e uma privada, que fica no dispositivo e nunca sai dele.

O padrão foi desenvolvido pela FIDO Alliance, fundada em 2012, junto com o W3C. A especificação técnica se chama WebAuthn, publicada como recomendação oficial do W3C em 2019. Apple, Google e Microsoft aderiram de forma sincronizada em 2022, o que fez o assunto explodir.

A ideia central e simples: se a chave privada nunca trafega pela rede, ela não pode ser roubada por phishing, vazamentos de banco de dados ou ataques man-in-the-middle. E matematicamente impossível falsificar a autenticação sem ter acesso físico ao dispositivo.

Como funciona na prática

Quando você se cadastra num site com passkey, seu dispositivo cria o par de chaves e armazena a chave privada em um chip seguro (Secure Enclave no iPhone, Titan no Android, TPM no Windows). O site guarda apenas a chave pública.

No login, o site manda um desafio aleatório. Seu dispositivo assina esse desafio com a chave privada, usando biometria (Face ID, Touch ID, Windows Hello) para confirmar que é você. O servidor verifica a assinatura com a chave pública. Se bater, acesso liberado.

A sincronização entre dispositivos e feita pelos gerenciadores de senha dos sistemas: iCloud Keychain (Apple), Google Password Manager, ou gerenciadores de terceiros como 1Password e Bitwarden. O passkey sincroniza criptografado entre seus próprios dispositivos.

Principais recursos e diferenciais

O maior diferencial técnico e a resistência nativa ao phishing. O passkey só funciona no domínio para o qual foi criado. Se alguém criar um site falso imitando seu banco, o passkey não vai nem aparecer como opcao. Isso e diferente de qualquer solução com senha, onde o usuário pode digitar em qualquer lugar.

Outros pontos relevantes:

• Sem reutilização de credenciais: cada site tem seu próprio par de chaves, então um vazamento em um serviço não compromete outro
• Sem reset de senha: o fluxo de recuperação e diferente, baseado em dispositivos confiados
• Biometria local: a biometria e processada no dispositivo, o servidor nunca ve sua impressão digital
• Suporte a QR code: você pode autenticar num computador apontando a camera do celular

Como começar: criando sua primeira passkey

Para usuários finais, o processo e simples. Veja como fazer no Google como exemplo:

Passo 1: Acesse myaccount.google.com e va em Segurança. Procure a secao de passkeys e chaves de acesso.

Passo 2: Clique em criar uma passkey. O sistema vai solicitar biometria (impressão digital, face ou PIN do dispositivo) para confirmar.

Passo 3: A passkey e criada e armazenada localmente. Da próxima vez que fizer login no Google, o browser vai oferecer autenticação via passkey automaticamente.

// Criando passkey via WebAuthn API (JavaScript)
const publicKeyCredential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "Meu App", id: "meuapp.com.br" },
    user: {
      id: userId,
      name: "usuá[email protected]",
      displayName: "Nome do Usuário"
    },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: { userVerification: "required" }
  }
});

Exemplo prático: implementando passkeys no backend

A parte mais trabalhosa de implementar passkeys e o backend. Você precisa armazenar a chave pública, o ID da credencial e um contador de uso por usuário. Existem bibliotecas que abstraem isso bem.

Em Node.js, a biblioteca SimpleWebAuthn facilita bastante. No Python, existe o py_webauthn. Em Java, o webauthn4j. Todas seguem o mesmo padrão da especificação FIDO2.

# Python com py_webauthn
pip install webauthn

from webauthn import verify_authentication_response

verified = verify_authentication_response(
    credential=credential_response,
    expected_challenge=expected_challenge,
    expected_rp_id="meuapp.com.br",
    expected_origin="https://meuapp.com.br",
    credential_public_key=stored_public_key,
    credential_current_sign_count=stored_sign_count,
)

O servidor precisa salvar no banco: o ID da credencial, a chave pública em formato COSE, o contador de assinaturas (para detectar clonagem) e o ID do usuário vinculado. Simples de implementar com qualquer ORM.

Comparação com alternativas

As alternativas mais comuns para autenticação forte são senhas com MFA via TOTP (Google Authenticator), magic links por email e SMS OTP. Cada uma tem seu tradeoff.

Passkey vs senha + TOTP: Passkey e mais seguro porque não pode ser phishado. TOTP funciona com qualquer smartphone mas um código de 6 dígitos pode ser interceptado em ataques em tempo real.

Passkey vs magic link: Magic link depende que o email esteja seguro e acessível no momento. Passkey funciona sem conexão de internet para a parte de biometria. Magic link e mais familiar para usuários não-técnicos.

• Use passkey quando segurança e crítica e você controla o dispositivo
• Use TOTP quando precisar de compatibilidade máxima com usuários variados
• Use magic link quando seu público for menos técnico e simplicidade for prioridade

Pontos positivos e limitações reais

Os pontos positivos já foram bastante destacados: resistência a phishing, sem vazamento de senha, biometria local. Mas as limitações reais merecem atenção antes de adotar.

Limitação 1 - modelo mental: Usuários acostumados com o fluxo de esqueci minha senha ficam perdidos quando o processo de recuperação muda. Se você perde todos os dispositivos confiados e não tinha backup do passkey, a recuperação da conta pode ser complicada dependendo do serviço.

Limitação 2 - fragmentação de ecosistema: Um passkey criado no iPhone via iCloud não aparece nativamente no Chrome do Windows. Você precisa usar o QR code ou instalar um gerenciador de terceiros que funcione cross-platform.

Casos de uso reais

Passkeys fazem mais sentido em contextos específicos. Veja quem já esta usando com sucesso:

Apps financeiros e bancos: Onde phishing e o maior risco. A proteção contra sites falsos e o argumento mais forte nesse segmento, e vários bancos brasileiros já estão pilotando o recurso.

Plataformas developer: GitHub, GitLab e Bitbucket suportam passkeys. Para devs que acessam repositórios de vários dispositivos, passkey pode ser mais ágil que digitar senha mais TOTP toda hora.

Ferramentas corporativas: Google Workspace e Microsoft 365 suportam passkeys para funcionários. Em ambientes com MFA obrigatório, passkey substitui o app de autenticação com melhor UX para quem já tem o dispositivo corporativo configurado.

E-commerce: Amazon, PayPal e outros grandes players internacionais já implementaram. No Brasil, a adoção ainda e lenta mas crescente, especialmente em fintechs.

Dicas e boas práticas

Vale a pena adotar passkeys?

Para desenvolvedores: sim, vale estudar e implementar agora. A API e estável, as bibliotecas existem para todas as linguagens principais, e Apple, Google e Microsoft estão todos comprometidos com o padrão. Quem implementar cedo tem vantagem na experiência do usuário.

Para usuários técnicos: já vale usar onde estiver disponível, especialmente em contas críticas como email, banco e acesso ao trabalho. O ganho de segurança contra phishing e real e imediato.

Para usuários não-técnicos: a experiência ainda e confusa, especialmente no fluxo de recuperação e na troca de dispositivos. A crítica que viralizou no Hacker News sobre engenheiros sem entender o consumidor tem um ponto real: a tecnologia por baixo e excelente, mas os fluxos de recuperação e a comunicação ainda precisam evoluir bastante para o grande público. O padrão vai ganhar espaço, e só questão de maturidade dos sistemas de backup e sincronização.