Passkeys ultrapassaram o ponto de inflexão — Senhas estão perdendo

Durante anos, o futuro sem palavra-passe foi um slide do PowerPoint — promissor, perpetuamente "a chegar em breve", e nunca realmente a chegar. Isso mudou. Em meados de 2026, as passkeys ultrapassaram a linha de funcionalidade experimental para autenticação padrão para centenas de milhões de contas. Google, Apple, Microsoft, Amazon, GitHub, Shopify, PayPal e WhatsApp ou padronizaram as passkeys ou tornaram-nas a credencial primária recomendada. A transição já não é teórica. Está a acontecer, e os dados de segurança que a suportam são impressionantes.

O que são realmente as Passkeys

As passkeys são uma implementação do padrão FIDO2/WebAuthn, uma especificação desenvolvida conjuntamente pela FIDO Alliance e pelo W3C. Na sua essência, as passkeys usam criptografia de chave pública assimétrica: quando regista uma passkey num serviço, o seu dispositivo gera um par de chaves. A chave privada nunca sai do seu dispositivo (ou do seu keychain sincronizado). O serviço armazena apenas a chave pública. Quando autentica, o serviço envia um desafio criptográfico; o seu dispositivo assina-o com a chave privada; o servidor verifica a assinatura com a chave pública armazenada.

Nenhuma palavra-passe é transmitida. Não existe nenhum segredo partilhado no servidor para roubar. Uma violação de base de dados que divulgue todas as credenciais armazenadas divulga apenas chaves públicas — inúteis para um atacante sem as chaves privadas correspondentes que permanecem nos dispositivos dos utilizadores.

Passkeys Vinculadas ao Dispositivo vs. Sincronizadas

Existem dois modelos de implementação fundamentalmente diferentes, e a distinção é importante tanto para a segurança como para a usabilidade:

• Passkeys vinculadas ao dispositivo (também chamadas credenciais vinculadas ao hardware ou não localizáveis) são armazenadas num módulo de segurança de hardware — um chip TPM no Windows, o Secure Enclave no silício da Apple, ou uma chave de hardware FIDO2 como um YubiKey. A chave privada é fisicamente não exportável. Se o dispositivo for perdido, a passkey desaparece. Este é o modelo de maior segurança e é apropriado para empresas, contas de alto valor e indivíduos preocupados com a segurança dispostos a gerir chaves de backup.
• Passkeys sincronizadas são armazenadas num keychain com suporte na nuvem — iCloud Keychain da Apple, Google Password Manager, ou um gestor de terceiros como 1Password ou Bitwarden. O material da chave privada é encriptado, sincronizado entre os seus dispositivos e pode sobreviver à perda do dispositivo. Isto sacrifica uma garantia restrita de atestação de hardware em troca de uma usabilidade e recuperação dramaticamente melhores. Para a grande maioria dos casos de uso do consumidor, as passkeys sincronizadas representam uma enorme melhoria de segurança em relação às palavras-passe, sem praticamente nenhuma desvantagem significativa no mundo real.

A atualização da especificação de 2023 da FIDO Alliance padronizou formalmente as passkeys sincronizadas depois de reconhecer que as passkeys apenas de hardware criavam uma barreira de adoção que mantinha os utilizadores nas palavras-passe — o pior resultado para a segurança geral.

O Fluxo de Autenticação, Passo a Passo

Compreender o que acontece nos bastidores durante uma autenticação WebAuthn ajuda a esclarecer porque é que os ataques de phishing falham contra passkeys:

• Registo: O navegador chama navigator.credentials.create() com um desafio do servidor. O autenticador (dispositivo, plataforma ou chave de hardware) gera um par de chaves com âmbito definido para o ID exato da parte confiante (o domínio). A chave pública e um ID de credencial são enviados para o servidor e armazenados.
• Autenticação: O servidor emite um novo desafio aleatório. O navegador chama navigator.credentials.get(). O autenticador verifica se a origem e o ID da parte confiante correspondem exatamente — uma passkey registada para google.com recusar-se-á a assinar um desafio de g00gle.com. Após verificação biométrica ou PIN, a chave privada assina o desafio. O servidor verifica a assinatura.
• A barreira do phishing: Como a passkey está vinculada à origem exata no momento do registo, um site de phishing não pode intercetar ou reproduzir credenciais. Mesmo que um utilizador seja enganado e visite um site semelhante, o autenticador recusa-se a produzir uma assinatura válida para uma origem diferente. Este é o mecanismo por detrás da taxa de phishing quase nula para contas com passkey.

Números de Adoção: O que os Dados Mostram

A Google reportou no Google I/O 2024 que mais de 800 milhões de contas Google tinham passkeys ativadas, acima dos 400 milhões no final de 2023. No início de 2025, a Google começou a solicitar aos utilizadores que criassem passkeys durante os fluxos de início de sessão e começou a definir por padrão os novos registos de conta como passkey-first. Dados internos da Google citados no seu blogue de segurança mostraram que os inícios de sessão com passkey estavam a ser concluídos a uma taxa 4x mais rápida do que os fluxos de palavra-passe + 2FA por SMS.

Mais importante: as métricas internas de phishing da Google para contas que migraram para autenticação apenas com passkey mostraram taxas de comprometimento por phishing próximas de zero — em comparação com uma linha de base de contas com palavra-passe onde, mesmo com 2FA, ataques de phishing SIM-swap e AiTM (adversário-no-meio) continuaram a ter sucesso.

A Apple lançou suporte para passkey no iOS 16 e macOS Ventura (2022) e, em 2025, tornou as passkeys o método sugerido por defeito no gestor de credenciais do Safari. A Microsoft ativou passkeys para contas Microsoft de consumidores em 2023 e expandiu para o Entra ID (Azure AD) para empresas em 2024. O GitHub tornou as passkeys geralmente disponíveis em 2023 e tem visto uma adoção particularmente forte entre contas de programadores — um segmento de alvo de alto valor onde a resistência ao phishing é crítica.

Suporte de Plataforma e Ecossistema

Apple: iCloud Keychain Passkeys

A implementação da Apple sincroniza passkeys com encriptação ponta a ponta através do iCloud Keychain. As passkeys funcionam em iPhone, iPad, Mac e — desde o iOS 17 — podem ser partilhadas com membros da família ou usadas em dispositivos não Apple através de autenticação de proximidade por código QR. O Secure Enclave impõe verificação biométrica (Face ID ou Touch ID) antes de qualquer operação de assinatura. A Apple também suporta chaves de segurança de hardware como autenticadores passkey através da sua API de autenticador de plataforma.

Google: Password Manager Passkeys

O Google Password Manager agora sincroniza passkeys através do Android e do Chrome em qualquer plataforma, incluindo Windows e macOS. A sincronização é encriptada ponta a ponta com o PIN da conta Google do utilizador. Uma adição significativa em 2024: o Google começou a suportar a exportação de passkeys em alguns fluxos e adicionou suporte para passkey ao seu Programa de Proteção Avançada — anteriormente domínio exclusivo de chaves de segurança físicas.

Windows Hello

O Windows Hello fornece passkeys vinculadas ao dispositivo ligadas ao chip TPM e desbloqueadas através de reconhecimento facial, impressão digital ou PIN. A implementação da Microsoft está fortemente integrada com o armazém de credenciais do Windows. Em ambientes empresariais, o Windows Hello for Business estende isto para autenticação baseada em certificados com o Entra ID, permitindo fluxos sem palavra-passe em ambientes corporativos geridos.

Gestores de Palavras-passe de Terceiros

Tanto o 1Password como o Bitwarden adicionaram armazenamento de passkeys em 2023-2024, tratando as passkeys como um novo tipo de credencial ao lado das palavras-passe. Isto é significativo: desacopla o armazenamento de passkeys dos fornecedores de plataforma, permite o uso de passkeys entre plataformas sem dependência da Google ou Apple, e dá às empresas um caminho para gerir passkeys na infraestrutura de cofres existente. A implementação de código aberto do Bitwarden foi auditada de forma independente.

Os Problemas Complexos que Persistem

Perda de Dispositivo e Recuperação de Conta

A perda de dispositivo é o obstáculo mais emocionalmente saliente à adoção de passkeys. A resposta correta — e que requer educação explícita do utilizador — é registar múltiplas passkeys em diferentes dispositivos ou autenticadores antes de precisar delas. Registe uma passkey no seu telemóvel, no seu portátil e numa chave de hardware guardada num local seguro. A maioria dos serviços que implementam bem passkeys solicita isto. Mas a realidade é que a maioria dos utilizadores regista uma única passkey e descobre o problema de recuperação apenas quando o seu dispositivo desaparece.

Para passkeys sincronizadas, o iCloud Keychain e o Google Password Manager têm ambos mecanismos de recuperação de conta. Se perder o seu iPhone, mas conseguir recuperar a sua conta iCloud (através de uma chave de recuperação ou dispositivo confiável), recupera as suas passkeys. Isto move o limite de segurança da posse do dispositivo para a segurança da conta — o que pode ser uma regressão se a sua conta iCloud ou Google tiver segurança fraca. A solução é tratar a sua conta primária na nuvem como uma raiz de alta segurança: chave de recuperação forte, 2FA de hardware, nada mais fraco.

Implementação Empresarial: Active Directory e LDAP

Os ambientes empresariais apresentam complexidade genuína. As aplicações legadas que autenticam contra o Active Directory ou LDAP não falam WebAuthn. Ligar passkeys a estes ambientes requer federação através de um fornecedor de identidade (Entra ID, Okta, Ping Identity) que possa traduzir a autenticação WebAuthn em tokens SAML ou OIDC, ou esperar pela modernização da aplicação. A maioria das grandes empresas está num estado híbrido: passkeys para aplicações nativas da nuvem e portais SSO, palavras-passe ou smart cards para aplicações empresariais legadas. A implementação empresarial completa de passkeys é um programa de vários anos, não uma mudança de configuração.

Interoperabilidade Android/iOS

O uso de passkeys entre plataformas — iniciar sessão num dispositivo iOS com uma passkey armazenada num telemóvel Android, ou vice-versa — funciona através do transporte híbrido CTAP2 (fluxo de código QR de proximidade Bluetooth). Na prática, isto funciona de forma fiável quando ambos os dispositivos são modernos, o Bluetooth está ligado e o utilizador percebe o que está a fazer. Não é perfeito para utilizadores menos técnicos e adiciona atrito em cenários como pedir emprestado o dispositivo de outra pessoa. Esta é uma área onde a UX ainda está atrás da capacidade criptográfica subjacente.

Dispositivos Legados sem Biometria

As passkeys requerem alguma forma de verificação do utilizador — biometria (impressão digital, rosto) ou um PIN do dispositivo. Dispositivos sem sensores biométricos podem usar um PIN, mas um PIN curto num dispositivo Android antigo é uma verificação de utilizador mais fraca do que o Face ID. As chaves de segurança de hardware (chaves FIDO2 com PIN + toque) resolvem isto para utilizadores dispostos a transportar uma, mas a adoção entre utilizadores não técnicos é mínima.

A Perspectiva do Programador: Implementar WebAuthn

Se está a construir autenticação, a implementação de WebAuthn está agora bem suportada. As bibliotecas maduras e ativamente mantidas em 2026 incluem:

• SimpleWebAuthn (TypeScript/Node.js) — a biblioteca JS mais usada, lida com registo e autenticação, documentação excelente, lida corretamente com a cerimónia incluindo verificação de desafio e padrões de armazenamento de credenciais.
• py_webauthn (Python) — a implementação Python de referência, usada na stack da Duo Security, suporta tanto FIDO2 como o U2F mais antigo para retrocompatibilidade.
• webauthn4j (Java) — a biblioteca Java madura usada pelo suporte WebAuthn do Spring Security; lida com validação de atestação, integração com serviço de metadados e funciona bem em aplicações Spring Boot.
• go-webauthn/webauthn (Go) — a implementação Go padrão, API limpa, ativamente mantida.

A compatibilidade do navegador já não é um problema para a API WebAuthn principal: Chrome 67+, Firefox 60+, Safari 14+ e Edge 18+ suportam-na. A lacuna de compatibilidade restante está na UI condicional (solicitações de passkey orientadas por preenchimento automático), que requer versões de navegador ligeiramente mais recentes, mas já está amplamente implementada.

Erros de implementação chave a evitar: não vincular o desafio à sessão no lado do servidor (vetor de ataque de repetição), não verificar o rpId e a origem na validação do lado do servidor, saltar a validação de atestação em contextos de alta segurança e não implementar fluxos de registo de múltiplos dispositivos desde o início.

Recomendações Práticas

Ative as passkeys nas suas contas de maior valor primeiro, nesta ordem de prioridade:

• Fornecedor de email — o seu email é o mecanismo de recuperação para tudo o resto. Uma conta de email comprometida afeta todas as outras contas. Ative passkeys no Gmail ou iCloud Mail imediatamente.
• Gestor de palavras-passe — se o seu gestor de palavras-passe suportar início de sessão com passkey (1Password e Bitwarden suportam), ative-o. Esta é a chave mestra para o seu cofre de credenciais.
• Contas financeiras — bancos e corretoras que suportam passkeys (uma lista em expansão) devem ser convertidos. Verifique as definições de segurança da sua instituição.
• Infraestrutura de programador — GitHub, AWS IAM Identity Center e plataformas semelhantes onde um compromisso poderia ter consequências na cadeia de abastecimento.

Quanto à questão vinculada ao dispositivo vs. sincronizada: para a maioria das pessoas, as passkeys sincronizadas são a escolha certa. São vastamente mais seguras do que palavras-passe, resistem completamente a phishing e sobrevivem à perda de dispositivo através de recuperação de conta. As passkeys vinculadas ao dispositivo em chaves de hardware são apropri