Passkeys: o fim da senha chegou ao seu sistema?

Senha é o mecanismo de autenticação mais usado e o mais problemático que existe. Ela é reutilizada entre serviços, vaza em lote, é adivinhada por força bruta e — o pior — pode ser entregue voluntariamente a um site falso por alguém convencido de que está no lugar certo.

Passkeys resolvem essas quatro categorias de uma vez, e não por serem uma senha melhor. Elas eliminam o segredo compartilhado.

Como funciona, sem jargão

No cadastro, o dispositivo da pessoa gera um par de chaves. A privada nunca sai de lá — fica protegida por biometria ou PIN. A pública é enviada ao seu servidor e guardada junto com a conta.

No login, o servidor manda um desafio aleatório. O dispositivo assina com a chave privada, depois de confirmar a identidade localmente. O servidor verifica a assinatura com a chave pública que já tinha.

Três consequências decorrem diretamente disso:

• Não há segredo no seu banco. Um vazamento entrega chaves públicas, que são inúteis para quem as obtiver.
• Phishing deixa de funcionar. A assinatura é vinculada ao domínio. Um site falso em outro endereço não recebe assinatura válida, mesmo que a pessoa queira entregar.
• Nada para digitar, logo nada para interceptar, reutilizar ou anotar.

É a mesma ideia da chave SSH, aplicada à web e com a chave protegida por biometria — o paralelo ajuda quem já opera servidor a entender o modelo rapidamente.

O que mudou para valer a adoção

A tecnologia não é nova; o que mudou foi o entorno.

Os navegadores atuais suportam o padrão. Os sistemas operacionais sincronizam as chaves entre dispositivos da mesma conta, o que resolvia o pior obstáculo — trocar de celular significava perder tudo. E os gerenciadores de senha passaram a armazenar passkeys, o que dá uma saída independente de plataforma.

Some a adoção pelos grandes serviços, que fez a interface deixar de ser desconhecida. A pessoa que já entrou em outro lugar com o rosto ou a digital não estranha ao ver o mesmo na sua aplicação.

O que muda no servidor

Você não implementa criptografia. O trabalho é integrar uma biblioteca do padrão WebAuthn na sua linguagem e armazenar alguns campos.

No cadastro, o servidor gera um desafio, recebe a credencial e guarda:

credential_id       identificador único da chave
public_key          a chave pública
sign_count          contador, para detectar clonagem
transports          como o autenticador se comunica
usuario_id          a quem pertence
apelido             "iPhone da Mariana", para a pessoa gerenciar
criado_em
ultimo_uso

No login, gera outro desafio, recebe a assinatura e verifica. A biblioteca faz a parte criptográfica.

Dois detalhes de implementação que costumam causar retrabalho.

O identificador da parte confiável é o domínio, e ele fica gravado na credencial. Se o seu site é app.empresa.com.br e um dia migra para empresa.com.br, as passkeys existentes deixam de funcionar. Vale escolher o domínio raiz desde o início, porque subdomínios podem ser cobertos por ele.

E o desafio precisa ser aleatório, de uso único e com validade curta, guardado do lado do servidor. Reaproveitar desafio abre exatamente o tipo de brecha que a tecnologia deveria fechar.

Recuperação, que é onde tudo desanda

Aqui está a parte difícil, e é onde a maioria das implementações se compromete.

Se a autenticação é forte mas a recuperação é "clique aqui e receba um link no e-mail", a segurança real do sistema é a do e-mail. Todo o esforço vira decoração.

O que funciona:

• Exigir mais de uma passkey. No cadastro, pedir o registro de um segundo dispositivo. É o equivalente à segunda cópia da chave.
• Códigos de recuperação, gerados uma vez e guardados fora do dispositivo. Modelo já conhecido de quem usa segundo fator.
• Aproveitar a sincronização. Passkeys sincronizadas pela conta do sistema operacional ou pelo gerenciador de senhas sobrevivem à perda do aparelho — o que resolve o caso mais comum sem nenhum mecanismo adicional.
• Recuperação assistida, com verificação de identidade proporcional ao risco, para sistema onde a conta vale muito.

O que não funciona é oferecer "entrar com senha" como alternativa permanente. Isso mantém a senha viva como caminho de ataque, e um atacante sempre escolherá o caminho mais fraco. Se a senha continua existindo, você tem os problemas dela mais a complexidade da passkey.

Um caminho de adoção realista

Ninguém troca a autenticação de um sistema em produção de uma vez. A sequência que funciona:

• Ofereça passkey como alternativa ao método atual, e meça a adoção.
• Torne padrão para conta nova, com a senha disponível apenas se a pessoa recusar.
• Convide quem já tem conta a registrar, com o argumento certo: é mais rápido entrar assim.
• Comece pela equipe interna, onde você controla os dispositivos e o suporte.
• Só então avalie desativar senha, e mesmo assim provavelmente por perfil — conta administrativa primeiro, onde o ganho é maior.

Uma observação sobre o argumento de venda para o usuário: segurança convence pouco. Conveniência convence. "Entrar com a digital, sem digitar nada" tem adesão bem maior que "sua conta ficará mais segura".

Onde isso encaixa na infraestrutura

Para quem opera servidor, o paralelo mais próximo já está em uso. Acesso administrativo a máquina deveria seguir o mesmo princípio — chave em vez de segredo compartilhado —, e é exatamente o que o artigo sobre hardening de SSH defende.

Chaves de segurança físicas em formato FIDO2 funcionam tanto para login web quanto para SSH:

ssh-keygen -t ed25519-sk -O resident -C "chave fisica"

Isso cria uma chave SSH que exige o toque no dispositivo físico para autenticar. A chave privada não pode ser copiada da máquina, o que elimina o cenário de notebook comprometido entregando acesso aos servidores.

Para painel administrativo de infraestrutura, essa combinação — passkey no painel, chave física no SSH — fecha as duas portas de entrada com o mesmo modelo mental.

O que ainda incomoda

Vale ser honesto sobre as arestas.

Dispositivo compartilhado é desconfortável: passkey pressupõe um aparelho pessoal, e computador de uso coletivo não se encaixa bem no modelo.

A sincronização depende de ecossistema. Migrar entre plataformas nem sempre é tranquilo, e o gerenciador de senhas independente é a saída — mas exige que a pessoa tenha um.

E o suporte precisa aprender a lidar com "não consigo entrar" em um vocabulário novo, onde a resposta não é mais redefinir senha.

Nada disso é impeditivo, e todos esses pontos vêm melhorando. A leitura razoável hoje é que passkey é a direção clara para autenticação de usuário, com adoção gradual e sem pressa — e que o momento de começar é o próximo sistema novo, onde não há histórico para migrar.

O que fazer com o segundo fator atual

Uma dúvida frequente de quem já implementou autenticação em duas etapas: passkey substitui ou complementa?

Substitui, na maior parte dos casos. O segundo fator existe para cobrir a fraqueza da senha — algo que você sabe precisa ser reforçado por algo que você tem. Passkey já é algo que você tem, protegido por algo que você é. Exigir um código adicional depois disso adiciona atrito sem ganho proporcional.

A exceção são as contas de maior valor, onde faz sentido exigir confirmação extra para operações específicas — transferência, alteração de credencial, exclusão de dados — em vez de no login. Esse desenho é melhor: o atrito aparece onde o risco está, e não em toda entrada.

Vale planejar a transição com cuidado para não deixar a conta menos protegida durante o processo. A ordem segura é registrar a passkey, confirmar que ela funciona, e só então remover o método antigo — nunca o contrário. É o mesmo cuidado do artigo sobre hardening de SSH: instalar a chave nova e testar antes de desligar a senha.

Por onde começar hoje

Se a adoção completa parece distante, há um primeiro passo de custo baixo e ganho imediato: habilitar passkey nas suas próprias contas administrativas.

Painel do provedor de nuvem, registrador de domínio, repositório de código, gerenciador de senhas. São exatamente as contas cujo comprometimento entrega a infraestrutura inteira — e todas já suportam.

Isso não exige nenhuma mudança na sua aplicação, leva alguns minutos por conta, e fecha o vetor mais explorado contra quem opera infraestrutura: o phishing bem feito contra a conta que controla tudo.

Feito isso, a implementação na sua aplicação deixa de ser urgente e passa a ser planejamento — que é onde ela deve estar. A ordem importa: proteger o acesso administrativo rende muito mais, por muito menos esforço, que migrar a autenticação de milhares de usuários.