Passkeys e WebAuthn em Produção: Porque a Recuperação de Passwords Devia Estar Extinta em Web Apps Modernas

Passkeys e WebAuthn em Produção: Porque a Recuperação de Passwords Devia Estar Extinta em Web Apps Modernas

O segredo partilhado é um erro arquitetural com quarenta anos

Em produção, não existe fluxo de código mais detestado pelos utilizadores, mais dispendioso para as equipas de suporte técnico e mais frequentemente explorado por atacantes do que o botão "Esqueceu-se da palavra-passe?".

Reflete sobre o absurdo estrutural da forma como a web gere a identidade digital desde a década de 1980. Para provar quem é, o servidor pede ao ser humano que invente uma sequência complexa de caracteres, a memorize e a transmita pela rede. Como nenhum ser humano consegue memorizar oitenta sequências aleatórias únicas de 24 caracteres, as pessoas reutilizam variações da mesma palavra-passe em dezenas de plataformas. Para mitigar fugas de bases de dados, o servidor queima ciclos preciosos de CPU a executar algoritmos pesados de hashing (Argon2id ou bcrypt). E quando o utilizador inevitavelmente se esquece da palavra-passe, o sistema recorre ao envio de uma hiperligação por e-mail não cifrado ou de um código de 6 dígitos por SMS — nivelando imediatamente a segurança de toda a arquitetura pelo elo mais fraco da cadeia de recuperação.

Mais grave ainda é o facto de muitos diretores técnicos (CTOs) continuarem a acreditar que adicionar um código TOTP de 6 dígitos ou um SMS à palavra-passe torna o seu portal empresarial “imune ao phishing”. Não torna.

Nos últimos três anos, a disseminação de plataformas de proxy inverso Adversary-in-the-Middle (AitM) — como o Evilginx e o Modlishka — reduziu a autenticação de dois fatores clássica a um obstáculo trivial. Quando um atacante envia a um diretor financeiro uma ligação para um domínio falso configurado como proxy inverso, o servidor malicioso apresenta em tempo real o ecrã verdadeiro da aplicação. A vítima digita a sua palavra-passe e o código de 6 dígitos da aplicação de autenticação no domínio falso; o proxy reencaminha ambos no mesmo milissegundo para o servidor legítimo, captura o cabeçalho Set-Cookie da sessão autenticada e sequestra a conta em menos de dois segundos.

Na Webxtek, quando desenhamos portais empresariais, plataformas B2B e Websites de Alta Performance, tratamos as palavras-passe baseadas em segredos partilhados como dívida técnica obsoleta. Sustentadas pela FIDO Alliance e pela especificação Web Authentication (WebAuthn Nível 3) do W3C, as Passkeys eliminaram todas as vulnerabilidades estruturais da autenticação por palavra-passe. No final de 2026, lançar uma aplicação web nova que dependa primariamente de palavras-passe e recuperações por SMS é negligência arquitetural.

Porque é que a criptografia assimétrica ao nível do sistema operativo derrota o phishing

Para compreender porque é que as Passkeys são categoricamente superiores às palavras-passe e aos códigos OTP, precisamos de observar o que ocorre exatamente dentro do navegador e do sistema operativo durante uma cerimónia WebAuthn.

Em vez de um segredo partilhado conhecido tanto pelo cliente como pelo servidor, uma Passkey é um par de chaves criptográficas assimétricas (tipicamente ECDSA P-256 ou Ed25519) gerado diretamente no hardware seguro do dispositivo do utilizador (Secure Enclave nos processadores Apple, chip Titan M no Android, TPM 2.0 no Windows ou um cofre cifrado).

  1. Registo (navigator.credentials.create): A chave privada fica trancada dentro do enclave seguro do dispositivo, protegida pela leitura biométrica local (Touch ID, Face ID, Windows Hello) ou código PIN do equipamento. O servidor recebe apenas a chave pública e o identificador da credencial. Se um atacante exfiltrar toda a tua base de dados de produção amanhã de manhã, encontrará apenas chaves públicas matematicamente inúteis — não existem hashes de palavras-passe para quebrar offline.
  2. Autenticação (navigator.credentials.get): Quando o utilizador regressa para iniciar sessão, o servidor gera um desafio criptográfico aleatório de utilização única (challenge, com pelo menos 16 bytes de entropia) e envia-o ao navegador.
  3. Assinatura Vinculada à Origem (Origin-Bound): É aqui que reside o mecanismo que destrói definitivamente o phishing por proxy inverso. Antes de o sistema operativo pedir a impressão digital ao utilizador para assinar o desafio, o próprio navegador vincula criptograficamente a assinatura ao rpId (Relying Party ID / domínio de origem) validado no certificado TLS.

Se um colaborador for induzido a clicar num endereço fraudulento como https://portal-webxtek.com em vez de https://webxtek.com, o olho humano pode não reparar no hífen. O subsistema WebAuthn do navegador nunca falha. Como o domínio não coincide com webxtek.com, o equipamento não encontra credenciais associadas a essa origem e a chave privada recusa terminantemente assinar qualquer desafio para o domínio impostor.

A economia de extinguir a recuperação de palavras-passe

Além do salto na cibersegurança, a migração de palavras-passe para Passkeys proporciona um ganho imediato e mensurável nas taxas de conversão comercial e nas margens operacionais.

De acordo com os estudos de referência publicados pela FIDO Alliance e confirmados em plataformas europeias de comércio eletrónico e serviços financeiros:

Métrica de Autenticação Password Legada + 2FA por SMS/TOTP Passkeys Modernas (WebAuthn Nível 3 + Conditional UI) Impacto em Produção
Tempo Mediano de Início de Sessão 28,4 segundos (digitação + troca de app para código) 3,1 segundos (toque biométrico via preenchimento) Autenticação 89% mais rápida
Taxa de Sucesso à Primeira Tentativa 67% a 74% (erros de digitação e códigos expirados) 98,2% em dispositivos móveis e computadores Elimina o abandono no checkout
Custo Telecom de SMS OTP por 100k Logins 4.500 € a 12.000 € (mais risco de fraude de tráfego SMS) 0,00 € (assinatura criptográfica nativa no dispositivo) Eliminação de 100% da fatura de SMS
Vulnerabilidade a Phishing por Proxy Inverso (AitM) 100% Vulnerável (o humano digita o segredo no site falso) 0% Vulnerável (vinculado criptograficamente ao rpId) Cumpre normas NIST SP 800-63B AAL2/AAL3
Responsabilidade Legal em Fuga de Base de Dados Elevada (hashes Argon2id sujeitos a ataques de dicionário) Zero segredos partilhados guardados no servidor Reduz drasticamente o impacto em auditorias RGPD

Repara na terceira linha da tabela: Custo Telecom de SMS OTP. Nos últimos dois anos, durante intervenções de Consultoria Técnica, assistimos a várias plataformas europeias de média dimensão a serem atingidas por ataques de Fraude de Tráfego SMS (SMS Pumping) — em que redes de bots disparam dezenas de milhares de pedidos falsos de envio de código SMS para gamas internacionais de tarifa majorada controladas por intermediários fraudulentos, gerando faturas de 15.000 € na Twilio ou na Vonage numa única noite. A transição para Passkeys WebAuthn elimina para sempre os custos de envio de SMS e a superfície de ataque financeira associada.

Implementar WebAuthn em produção sem criar atrito na experiência do utilizador

Um receio frequente entre gestores de produto é a ideia de que o protocolo WebAuthn é complexo de implementar ou que as janelas do navegador confundem utilizadores menos técnicos. Essa crítica era justa em 2019, quando o padrão FIDO2 exigia ligar uma chave física USB YubiKey e navegar por caixas de diálogo crípticas.

Em 2026, duas especificações fundamentais tornaram as Passkeys invisíveis e intuitivas: as Credenciais Descobertas Multi-Dispositivo (Synced Passkeys) e a WebAuthn Conditional UI conjugada com a WebAuthn Signal API.

Recorrendo a bibliotecas auditadas como o SimpleWebAuthn e seguindo as recomendações técnicas da OWASP e da publicação especial 800-63B do NIST, podemos integrar a Conditional UI diretamente no campo habitual de e-mail ou nome de utilizador. Quando a página carrega, o navegador verifica silenciosamente em segundo plano se o equipamento possui uma Passkey para o teu domínio. Assim que o utilizador toca no campo de texto, a sua Passkey surge integrada no menu nativo de preenchimento automático — basta um toque no sensor biométrico e a sessão fica iniciada.

// 1. Lado do Cliente: Inicialização da WebAuthn Conditional UI (Passkeys no Autofill)
import { startAuthentication, browserSupportsWebAuthnAutofill } from '@simplewebauthn/browser';

export async function iniciarPasskeyConditionalUI() {
  // Verifica se o navegador suporta sugestões nativas de Passkey no preenchimento automático
  if (!(await browserSupportsWebAuthnAutofill())) return;

  // Obtém um desafio criptográfico único guardado numa sessão HttpOnly segura
  const resp = await fetch('/api/auth/passkey-opcoes');
  const optionsJSON = await resp.json();

  try {
    // useBrowserAutofill: true associa-se silenciosamente ao <input autocomplete="username webauthn">
    const respostaAssinada = await startAuthentication({
      optionsJSON,
      useBrowserAutofill: true,
    });

    // Valida a assinatura criptográfica contra a chave pública guardada no servidor
    const verificacaoResp = await fetch('/api/auth/passkey-verificar', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(respostaAssinada),
    });

    if (verificacaoResp.ok) {
      window.location.assign('/painel');
    }
  } catch (err) {
    // Falha silenciosamente se o utilizador optar pelo fluxo secundário ou cancelar
    console.debug('Conditional UI em espera:', err);
  }
}

E na marcação HTML, tudo o que precisas para ativar a Conditional UI é acrescentar o marcador webauthn ao atributo autocomplete do campo de identificação:

<!-- Campo de autenticação standard atualizado com suporte a WebAuthn Conditional UI -->
<label for="identificador-login">E-mail Profissional</label>
<input
  id="identificador-login"
  name="email"
  type="email"
  autocomplete="username webauthn"
  placeholder="nome@empresa.pt"
  required
/>

Resolver o problema das “Passkeys Órfãs” com a WebAuthn Signal API

Um caso limite operacional que afetou as primeiras implementações de Passkeys entre 2023 e 2024 era a dessincronização de credenciais. Se um utilizador removesse uma Passkey nas definições de segurança da sua conta no website, o Porta-chaves em iCloud ou o Gestor da Google no telemóvel não sabiam que o servidor tinha revogado essa chave pública — pelo que o navegador continuava a sugerir uma Passkey “morta” no menu de preenchimento automático.

Hoje, com o WebAuthn Nível 3, resolvemos este problema de forma elegante através da PublicKeyCredential Signal API (PublicKeyCredential.signalAllAcceptedCredentials e PublicKeyCredential.signalUnknownCredential). Sempre que um utilizador inicia sessão ou gere os seus dispositivos de segurança, a aplicação informa a API do navegador sobre a lista exata de identificadores de credenciais ativos no servidor. Qualquer Passkey revogada ou órfã é automaticamente ocultada ou limpa do gestor de credenciais local do equipamento.

Passkeys Sincronizadas vs. Chaves Físicas de Hardware: Adequar ao modelo de ameaça

Quando desenhamos arquiteturas de autenticação para clientes alojados na nossa infraestrutura de Alojamento Gerido ou integrados com Websites Estáticos Rápidos, distinguimos dois perfis de atestação WebAuthn com base nos níveis de garantia do NIST:

  1. Comércio Eletrónico, Portais de Cliente e SaaS (AAL2 — Passkeys Sincronizadas): Permitimos credenciais multi-dispositivo (residentKey: 'required', userVerification: 'required') em que os indicadores backupEligible (BE) e backupState (BS) são verdadeiros. Se um cliente deixar cair o telemóvel à água, basta iniciar sessão no equipamento novo com a sua conta Apple ou Google e as suas Passkeys são restauradas automaticamente através de sincronização cifrada ponto-a-ponto — sem gerar um único pedido à equipa de suporte.
  2. Tesouraria Corporativa, Consolas de Administração e Infraestrutura Crítica (AAL3 — Chaves Vinculadas ao Hardware): Para contas de administração interna ou operações financeiras reguladas, configuramos a política de verificação no servidor para inspecionar o identificador de modelo (AAGUID) e rejeitar chaves sincronizáveis na cloud, exigindo chaves físicas FIDO2 dedicadas (como a série YubiKey 5) cuja chave privada jamais pode ser exportada do silício.

Como reformar as palavras-passe na tua organização ainda este ano

Não precisas de impor uma transição abrupta que bloqueie os clientes habituais para extinguir as palavras-passe em produção. O plano de migração progressiva que implementamos na Webxtek divide-se em três fases seguras:

  • Fase 1: Ativar a Conditional UI + Convite Pós-Login. Imediatamente após o utilizador concluir um início de sessão tradicional, verifica a disponibilidade de biometria local através de PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable(). Se devolver true, apresenta um convite de clique único: “Ativar Face ID / Touch ID para entrar instantaneamente da próxima vez”. Sincronize o estado através da WebAuthn Signal API.
  • Fase 2: Fluxo de Identificação Passkey-First. Passa a desafiar automaticamente todas as contas com Passkeys registadas assim que introduzem o e-mail, relegando a palavra-passe ou o envio de código por e-mail para uma opção secundária de recurso.
  • Fase 3: Obrigatoriedade Total em Contas Privilegiadas. Exige exclusivamente WebAuthn para todos os colaboradores internos, administradores de sistemas e aprovadores financeiros, desativando por completo a autenticação por palavra-passe e SMS nos painéis de administração.

As palavras-passe tiveram um reinado de quarenta anos que custou centenas de milhares de milhões de euros à economia global em fugas de credenciais, ataques de phishing e carrinhos de compras abandonados. Com o suporte universal dos navegadores e sistemas operativos ao WebAuthn Nível 3 em 2026, manter a recuperação de palavras-passe viva na tua aplicação web deixou de ser uma necessidade técnica — é uma escolha deliberada pelo risco.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como cibersegurança b2b e inteligência corporativa e simuladores web personalizados e interativos. Quando alinhas a tua estrutura através de websites de alta performance e consultoria técnica antes de construir, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.

[+] [ INDEX_DIRECTORY ] 16 tópicos ▼
[ SYSTEM.FAQ ]

Perguntas Frequentes

Porque é que palavras-passe combinadas com códigos de 6 dígitos por SMS ou aplicações de autenticação continuam a ser vítimas de phishing?

Tanto as palavras-passe como os códigos TOTP/SMS de 6 dígitos são 'segredos partilhados' que o utilizador humano pode ser induzido a digitar num website falso. Kits modernos de proxy inverso (Adversary-in-the-Middle) como o Evilginx intercetam a password e o código de 6 dígitos em tempo real, reencaminham-nos para o servidor verdadeiro e roubam o cookie de sessão autenticado.

Como é que as Passkeys e o protocolo WebAuthn tornam o phishing matematicamente impossível?

As Passkeys utilizam criptografia assimétrica de chave pública vinculada estritamente ao domínio verificado no navegador (Relying Party ID). Mesmo que um administrador seja enganado e aceda a um domínio semelhante (`login-empresa.pt` em vez de `empresa.pt`), o subsistema WebAuthn do sistema operativo deteta a diferença de domínio e recusa assinar o desafio criptográfico.

O que acontece se o utilizador perder o telemóvel ou o computador onde usa Passkeys?

Ao contrário das primeiras chaves físicas que ficavam presas a um único dispositivo USB, as Passkeys modernas multi-dispositivo (sincronizadas via Porta-chaves em iCloud, Gestor de Palavras-passe da Google ou 1Password) são cifradas ponto-a-ponto e sincronizadas entre todos os equipamentos do utilizador. Para contas de administração crítica, é possível exigir chaves físicas não exportáveis.

Autenticar com impressão digital ou Face ID através de Passkeys significa que o servidor guarda dados biométricos?

Nunca. Os teus dados biométricos (Face ID, Touch ID, Windows Hello) jamais saem do chip de segurança físico (Secure Enclave ou TPM) do teu equipamento. A validação biométrica local serve apenas para autorizar a chave privada interna a assinar um desafio matemático único enviado pelo servidor. O servidor guarda exclusivamente uma chave pública.

Como é que a funcionalidade Conditional UI do WebAuthn evita confusão nos utilizadores durante a transição?

A Conditional UI (`autocomplete='username webauthn'`) integra a seleção de Passkeys diretamente no menu nativo de preenchimento automático do navegador sobre o campo habitual de e-mail. Os utilizadores com Passkey registada entram com um simples toque biométrico sem digitar nada, enquanto os utilizadores antigos continuam a usar o mesmo campo normalmente.

> INICIAR_PROJETO

Precisa de um website que transmita confiança, apareça na pesquisa e dê mais força à sua presença digital? Comece a conversa aqui.