Passkeys e PRF do WebAuthn para Criptografia de Ponta a Ponta (2025)

O WebAuthn e as Passkeys revolucionaram a autenticação na web, oferecendo logins sem senha e resistentes a phishing por meio de criptografia de chave pública. Mas suas capacidades vão além dos logins. Um recurso interessante é a extensão de Função Pseudo-Aleatória (PRF) do WebAuthn. Essa extensão permite que aplicações web derivem chaves secretas diretamente da passkey de um usuário ou de uma chave de segurança de hardware durante a autenticação. Isso possibilita a criptografia de dados de ponta a ponta ou o desbloqueio de um cofre seguro usando apenas sua passkey, sem a necessidade de uma senha separada. Neste artigo, queremos responder às seguintes perguntas:

• Casos de uso da PRF com Passkeys: Quais são os casos de uso interessantes para a extensão PRF do WebAuthn?
• Suporte à extensão PRF: Qual é o suporte real da extensão PRF do WebAuthn nos sistemas operacionais e navegadores atualmente?

Este artigo analisa a extensão PRF do WebAuthn, explorando suas especificações técnicas, casos de uso, detalhes de implementação, considerações de segurança e o cenário atual de suporte em navegadores e sistemas operacionais. Focamos nas mudanças no ecossistema de 2025 e expandimos o trabalho fundamental de Matthew Miller e Levi Schuck em 2023, cujos artigos anteriores fornecem um background técnico detalhado, exemplos ao vivo e testes online (incluindo criptografia).

A extensão PRF (Pseudo-Random Function) do WebAuthn é formalmente definida na especificação WebAuthn Nível 3. Seu propósito principal é permitir que uma Parte Confiável (Relying Party) (sua aplicação web) solicite a avaliação de uma função pseudo-aleatória associada a uma credencial WebAuthn específica (passkey) durante uma cerimônia de autenticação (navigator.credentials.get()).

Uma PRF utiliza uma chave secreta (mantida de forma segura dentro do autenticador e vinculada à credencial) e um ou mais valores de entrada (fornecidos pela Parte Confiável) para produzir uma saída determinística com aparência criptograficamente aleatória. Essa saída, tipicamente uma string de 32 bytes, pode então ser usada pela aplicação do lado do cliente, mais notavelmente como material de chave simétrica para criptografia com WebAuthn ou derivação de chaves.

Muitos autenticadores, particularmente chaves de segurança FIDO2, implementam uma capacidade subjacente definida no Protocolo Cliente-para-Autenticador (CTAP2) chamada de extensão hmac-secret. Essa extensão CTAP2 fornece acesso a uma função HMAC (Hash-based Message Authentication Code) baseada em hardware, que serve como a função pseudo-aleatória. A extensão PRF do WebAuthn atua como uma forma padronizada para aplicações web acessarem essa capacidade hmac-secret através da API WebAuthn do navegador.

Para evitar possíveis conflitos ou problemas de segurança onde um site possa enganar o autenticador para gerar HMACs destinados a fins não relacionados à web (como login no sistema operacional local), a especificação WebAuthn exige um passo importante: as entradas fornecidas pelo site (primeiro e segundo salts) são primeiro hasheadas com uma string de contexto específica ("WebAuthn PRF" e um byte nulo) antes de serem passadas para a função hmac-secret subjacente. Isso efetivamente particiona o espaço de entrada da PRF, garantindo que as saídas derivadas da web sejam distintas daquelas potencialmente usadas em outros contextos.

A capacidade de derivar chaves vinculadas ao autenticador abre caminho para vários casos de uso interessantes para desenvolvedores:

1. Criptografia do Lado do Cliente / de Ponta a Ponta (E2EE): Este é o principal motivador para a extensão PRF do WebAuthn. Aplicações baseadas em navegador podem derivar uma chave de criptografia única por credencial durante o login. Essa chave pode então ser usada com a API WebCrypto para criptografar dados do usuário armazenados localmente ou no servidor. Os dados permanecem criptografados em repouso e só podem ser descriptografados pelo usuário após autenticação bem-sucedida com a passkey específica, aumentando a privacidade e a segurança dos dados. Os provedores de serviço podem armazenar dados do usuário sem nunca terem acesso ao texto plano. Isso é especialmente útil para aplicações no mundo sem senhas, pois sem a extensão PRF, elas precisariam solicitar adicionalmente um segredo na forma de uma senha, o que contradiz a arquitetura sem senhas.

2. Desbloqueio de Cofres sem Senha: Serviços como gerenciadores de senhas (ex: Bitwarden, 1Password) ou aplicativos de notas seguras (ex: Notesnook, Reflect) podem usar a PRF para substituir a senha mestra tradicional. O usuário se autentica com sua passkey, a extensão PRF deriva a chave de descriptografia do cofre e o cofre é desbloqueado — sem necessidade de senha mestra. O Bitwarden anunciou suporte para isso. Além disso, o Dashlane adotou recentemente a extensão PRF do WebAuthn para fortalecer a resistência a phishing e aumentar a segurança no acesso a cofres criptografados. Os usuários se autenticam usando suas passkeys, permitindo que a PRF derive as chaves de descriptografia do cofre de forma segura, eliminando completamente a necessidade de uma senha mestra.

3. Rotação Segura de Chaves: A extensão PRF do WebAuthn permite fornecer dois "salts" de entrada (primeiro e segundo) durante a autenticação. Isso facilita esquemas de rotação de chaves criptográficas. Um servidor poderia solicitar a chave "atual" usando o primeiro salt e a "próxima" chave usando o segundo. Com o tempo, o servidor pode atualizar qual salt corresponde à chave atual, permitindo uma rotação transparente sem interromper a experiência do usuário. Isso é especialmente importante caso requisitos regulatórios ou políticas internas exijam que todas as chaves sejam rotacionadas dentro de um cronograma específico, aumentando a segurança.

4. Carteiras de Identidade e Sistemas sem Custódia: A PRF pode derivar chaves para proteger dados de identidade dentro de carteiras digitais ou habilitar sistemas sem custódia onde as chaves privadas nunca são expostas do lado do servidor.

Embora a especificação esteja definida, o suporte real nos navegadores e plataformas é o fator crítico para os desenvolvedores. O suporte tem evoluído e, até recentemente, estava limitado principalmente a navegadores baseados em Chromium. Rastrear o suporte pode ser desafiador, pois não há uma entrada dedicada no CanIUse.com para a extensão PRF em si (pesquisar por "webauthn" mostra o suporte geral da API, mas não de extensões específicas). As informações muitas vezes precisam ser coletadas de notas de lançamento de navegadores, rastreadores de bugs e páginas de status. Usar com sucesso a extensão PRF do WebAuthn requer um esforço coordenado em três camadas distintas da pilha de tecnologia. O suporte à extensão PRF deve estar presente em cada nível para que o recurso funcione:

1. O Autenticador: Este é o hardware (como uma chave de segurança) ou componente de plataforma (como Windows Hello, iCloud Keychain e o módulo de hardware correspondente, por exemplo, TPM ou Secure Enclave) que armazena de forma segura a chave secreta da credencial e realiza o cálculo da função pseudo-aleatória (tipicamente usando a capacidade CTAP2 hmac-secret). Se o autenticador não tiver essa capacidade criptográfica fundamental, a PRF não pode funcionar.

2. O Sistema Operacional (SO): O SO atua como a ponte entre o navegador e o autenticador. Ele fornece os drivers e as APIs de nível de sistema necessários para que o navegador descubra, comunique-se e solicite operações dos autenticadores (especialmente autenticadores de plataforma e aqueles conectados via USB/NFC/Bluetooth). O SO deve ser capaz de reconhecer e expor a capacidade PRF (hmac-secret) do autenticador para o navegador. Se o SO não fornecer esse caminho, o navegador não poderá acessar o recurso.

3. O Navegador: Como a interface para a aplicação web, o navegador deve implementar a API JavaScript do WebAuthn, reconhecer especificamente a extensão prf, traduzir a solicitação da web para os comandos apropriados para o SO/autenticador, lidar com o passo crucial de segurança de hashear as entradas com a string de contexto e analisar e retornar corretamente os resultados para a aplicação.

Uma falha ou falta de suporte em qualquer uma dessas três camadas — capacidade do Autenticador, exposição pelo SO ou implementação do Navegador — impedirá o funcionamento da extensão PRF.

Este diagrama de sequência mostra uma versão simplificada de como esses atores trabalham juntos para facilitar o suporte à PRF.

Um fluxo de trabalho PRF funcional exige que todas as camadas na cadeia WebAuthn ↔ CTAP cooperem.
Para maior clareza, separamos a discussão em (1) comportamento do navegador + sistema operacional e (2) comportamento do autenticador.

A jornada em direção a um amplo suporte à PRF destaca um desafio comum com as extensões de padrões da web: a implementação é muitas vezes escalonada, com problemas específicos da plataforma precisando de resolução. Nosso objetivo é manter esta tabela atualizada, mas lembre-se de que, como a extensão PRF é uma das adições mais recentes que exigem a adaptação de toda a cadeia de compatibilidade, ajustes contínuos são esperados.

Abaixo, detalhamos o suporte por sistema operacional.

O suporte para a extensão PRF do WebAuthn no Windows é limitado, pois o autenticador de plataforma nativo (Windows Hello) atualmente não possui a capacidade hmac-secret necessária. A funcionalidade PRF, portanto, depende de chaves de segurança externas.

Com o macOS 15, o suporte à PRF chegou para os autenticadores de plataforma. Tanto o Safari quanto o Chrome suportam PRF via iCloud Keychain. O suporte do Firefox para o autenticador de plataforma ainda está pendente. Chaves de Segurança só funcionam com o Chrome.

O status no iOS e iPadOS espelha o do macOS, com a PRF funcionando via iCloud Keychain. No entanto, existem ressalvas significativas: um bug nas primeiras versões do iOS 18 pode levar à perda de dados, e o suporte para chaves de segurança externas ainda não foi implementado.

O Android atualmente oferece o suporte mais robusto e difundido para a extensão PRF do WebAuthn. As Passkeys armazenadas no Google Password Manager incluem suporte a PRF por padrão, e funciona na maioria dos principais navegadores, com exceção do Firefox.

Na tabela acima, incluímos as combinações mais importantes para o suporte de provedores de passkeys primários. No entanto, ao usar gerenciadores de senhas como provedores de passkeys de terceiros, suas capacidades específicas devem ser consideradas separadamente. Por exemplo, o 1Password suporta PRF em sua versão para Android, mas não em sua versão para iOS. Além disso, o Perfil do Chrome como autenticador não suporta prf. Para mais detalhes sobre autenticadores, veja abaixo.

Enquanto o WebAuthn especifica o que uma Parte Confiável (Relying Party) pode pedir, o Protocolo Cliente-para-Autenticador (CTAP) define como o autenticador deve se comportar. Na prática, os autenticadores se enquadram em quatro categorias:

1. Sem suporte a PRF: Autenticadores de plataforma mais antigos (ex: Windows Hello), chaves de segurança legadas sem a extensão hmac‑secret e provedores de terceiros que ainda não adotaram a extensão prf.

2. PRF apenas se a flag PRF foi definida na criação da credencial: Algumas chaves de segurança CTAP 2.0/2.1 expõem hmac‑secret, mas recusarão avaliações de PRF a menos que a Parte Confiável tenha solicitado isso quando a credencial foi criada pela primeira vez para inicializar os segredos.

3. PRF disponível na autenticação mesmo quando não solicitado na criação: Tokens de hardware de nova geração, o iCloud e o Google Password Manager expõem a funcionalidade hmac‑secret incondicionalmente; credenciais criadas sem a flag ainda funcionam com PRF durante navigator.credentials.get().

4. Conformidade total com CTAP 2.2 (PRF + primeiro valor PRF na criação): Autenticadores de plataforma que sincronizam passkeys—como o iCloud Keychain e o Google Password Manager—podem, sob solicitação, retornar a primeira saída PRF já durante navigator.credentials.create(), otimizando os fluxos de estabelecimento de chaves.

Saber a qual categoria um autenticador pertence é essencial ao projetar sua lógica de backup, migração ou estabelecimento de chaves. Também incluímos testes para esses cenários em nossa demonstração.

Você pode experimentar a extensão PRF do WebAuthn diretamente usando nossa aplicação de demonstração interativa de PRF do WebAuthn. Nesta demonstração), você poderá:

• Registrar uma passkey com PRF e confirmar se seu autenticador suporta esta poderosa extensão.
• Autenticar usando sua passkey e ver o valor criptográfico gerado pela PRF em ação.

Ver o valor da PRF por si mesmo destaca as implicações práticas de usar passkeys para operações seguras baseadas em chaves. Permite que você verifique diretamente a compatibilidade do autenticador para a extensão PRF e observe como as chaves derivadas da PRF podem potencializar a criptografia de ponta a ponta com WebAuthn e o desbloqueio seguro de cofres sem senhas.

Reserve um momento para experimentar a demonstração; entender a capacidade de PRF do seu ambiente específico ajuda a planejar melhor experiências seguras e sem senha, adaptadas aos seus usuários.

Pronto para testar o poder da PRF? Clique na imagem acima ou siga este link para iniciar sua exploração prática.

A extensão PRF do WebAuthn não é a única extensão do WebAuthn relacionada ao armazenamento ou derivação de dados. Como a PRF de passkey se compara?

• PRF vs. credBlob / largeBlob:

  • credBlob: Permite armazenar um pequeno blob estático (32 bytes) com a credencial, possivelmente no momento da criação. Não foi projetado principalmente para segredos, e o suporte é limitado, especialmente para credenciais não detectáveis.

  • largeBlob: Permite armazenar mais dados (~1KB) com credenciais detectáveis, muitas vezes destinado a dados auxiliares como certificados. O suporte também é limitado (suportado pelo iCloud Keychain desde o iOS 17, mas não pelo GPM). Os desenvolvedores do Chrome favoreceram explicitamente o foco na PRF em vez do largeBlob para a maioria dos casos de uso, embora o desenvolvimento possa acontecer no futuro.

  • PRF: Em contraste, a PRF é projetada especificamente para derivar chaves secretas sob demanda durante a autenticação usando um segredo vinculado ao hardware, em vez de armazenar um blob estático. É geralmente considerada o mecanismo padrão mais apropriado e seguro para derivar chaves de criptografia vinculadas a uma passkey. A evolução da discussão sobre blobs para segredos para a padronização e o foco na implementação da PRF sugere uma convergência na PRF como a solução dedicada para este caso de uso.

• PRF vs. Chaves Derivadas de Senha (ex: PBKDF2): Tradicionalmente, as chaves de criptografia do lado do cliente eram derivadas de senhas de usuários. A PRF oferece vantagens significativas:

  • Fonte Mais Forte: As chaves são derivadas de material criptográfico forte dentro do autenticador, não de senhas potencialmente fracas ou reutilizadas.

  • Resistência a Phishing: A derivação está vinculada ao fluxo de autenticação WebAuthn, que é resistente a phishing.

  • Sem Senha: Permite casos de uso como o desbloqueio de cofres sem exigir uma senha.

• PRF vs. Outros Dados do WebAuthn: Tentar derivar chaves de outras partes da resposta do WebAuthn (como a assinatura, authenticatorData ou a chave pública) é fundamentalmente inseguro e incorreto. Esses componentes são públicos, não secretos ou projetados para verificação, não para derivação de chaves.

Para derivar material de chave criptográfica de forma segura e vinculada diretamente a uma credencial WebAuthn ou passkey, a extensão PRF do WebAuthn é a abordagem padrão, desenvolvida especificamente para esse fim e recomendada.

Ao integrar a extensão PRF em sua aplicação, considere estas diretrizes práticas:

As seguintes recomendações ajudam os desenvolvedores a navegar pelo estado atual do suporte à extensão PRF de forma eficaz e a planejar desenvolvimentos futuros:

• Trate a PRF de Forma Oportunista:
  O suporte para a extensão PRF do WebAuthn atualmente varia significativamente entre navegadores, sistemas operacionais e autenticadores. Portanto, trate a integração da PRF como uma melhoria, e não como uma dependência central.

• Evite Dependência Crítica da PRF:
  Evite tornar a PRF essencial para funcionalidades de missão crítica. O suporte atual, particularmente em plataformas como o Safari no macOS e iOS, permanece inconsistente e incompleto.

• Prepare-se para Cenários de Perda de Passkey:
  Lembre-se de que os dados criptografados com chaves derivadas da PRF estão vinculados exclusivamente à passkey específica. Perder a passkey tornará os dados criptografados permanentemente inacessíveis. Sempre implemente mecanismos robustos de backup e recuperação.

• Antecipe um Suporte Mais Amplo até 2026:
  O suporte à extensão PRF está amadurecendo rapidamente. Até 2026, espere uma disponibilidade consistente nos principais navegadores, sistemas operacionais e autenticadores, particularmente com provedores de passkeys primários.

• Monitore o Ecossistema Windows:
  O suporte do autenticador de plataforma via Windows Hello está atualmente ausente. A integração completa da PRF em ambientes Windows depende fortemente da estratégia de adoção da Microsoft, portanto, mantenha este ecossistema sob observação atenta.

Seguir estas diretrizes garante que os desenvolvedores possam incorporar a PRF de forma suave, mantendo a compatibilidade e a segurança durante sua fase de adoção.

Entender como a PRF se alinha com sua estratégia geral de passkeys ajuda a maximizar seus benefícios sem complicações desnecessárias:

• Integração Flexível:
  Não é necessário decidir se deve aproveitar a PRF no momento da criação da passkey. Passkeys existentes podem ser integradas posteriormente e de forma transparente com casos de uso de PRF, sem sobrecarga adicional de gerenciamento de credenciais.

• Adaptação Retroativa da PRF:
  Como a PRF opera durante a fase de autenticação (navigator.credentials.get()), passkeys criadas anteriormente podem suportar fluxos de trabalho baseados em PRF em um estágio posterior. Isso permite que sua aplicação aprimore a segurança de forma incremental, sem interromper os métodos de autenticação estabelecidos. Essa abordagem funciona com o iCloud Keychain e o Google Password Manager (GPM) e chaves de segurança mais recentes. Para chaves de segurança mais antigas, um hmac-secret pode ser gerado apenas se solicitado na criação da credencial.

• Considerações sobre a Complexidade das Passkeys:
  As complexidades inerentes ao gerenciamento de passkeys—como sincronização de credenciais, autenticação entre dispositivos e processos de recuperação—aplicam-se igualmente ao usar a PRF. Garanta que sua implementação de PRF se alinhe de forma coesa com sua estratégia geral de autenticação com passkeys, mantendo experiências de usuário simplificadas e controles de segurança robustos.

Considerar a PRF como parte de uma estratégia holística de passkeys permite uma transição mais suave para práticas de autenticação mais seguras e fáceis de usar.

Para provedores de serviços empresariais que lidam com dados sensíveis de usuários, a capacidade de aproveitar a PRF do WebAuthn junto com as passkeys abre possibilidades para aprimorar a segurança e a experiência do usuário, particularmente em cenários que exigem criptografia do lado do cliente de Informações de Identificação Pessoal (PII) ou para proteger aplicações que requerem Criptografia de Ponta a Ponta. Embora o Corbado Connect seja projetado principalmente para uma integração empresarial transparente de passkeys, ele também pode facilitar a implementação de extensões de passkey como SPC ou PRF.

Veja como a Corbado pode ajudar as organizações que desejam integrar a PRF:

• Facilitando a PRF para Armazenamento Criptografado: Em ambientes empresariais, às vezes há a exigência de armazenar informações sensíveis de forma segura, talvez até mesmo diretamente do lado do cliente para minimizar a exposição de PII no lado do servidor. O Corbado Connect pode ser configurado para solicitar valores de PRF durante o fluxo de autenticação com passkey (navigator.credentials.get()), permitindo que as aplicações derivem as chaves criptográficas necessárias.
• Padrões de Armazenamento Flexíveis: Os dados criptografados usando chaves derivadas da PRF podem ser armazenados de várias maneiras, dependendo dos requisitos de segurança e da arquitetura:
  • Lado do Cliente: Armazenados diretamente no navegador usando mecanismos como localStorage ou Cookies seguros. Os dados em texto plano existem apenas transitoriamente no cliente durante a descriptografia.
  • Backend da Corbado (E2EE): Embora a Corbado geralmente evite armazenar PII de clientes, o mecanismo de PRF tecnicamente permite o armazenamento de dados criptografados do lado do cliente nos servidores da Corbado. A Corbado não possuiria as chaves para descriptografar esses dados; a descriptografia ainda aconteceria do lado do cliente após uma autenticação de usuário bem-sucedida.
  • Backend do Cliente: Os dados criptografados também poderiam ser enviados e armazenados nos próprios sistemas de backend da empresa, ainda se beneficiando da criptografia do lado do cliente.
• Fluxo Seguro de Derivação de Chaves: Os componentes do Corbado Connect gerenciam a interação com a API WebAuthn. Quando a PRF é solicitada:
  1. Uma saída PRF específica do usuário é gerada pelo autenticador, vinculada à passkey individual.
  2. Essa saída é retornada de forma segura para a aplicação do lado do cliente.
  3. A aplicação deve então usar uma Função de Derivação de Chave (KDF) através da API WebCrypto (ex: HKDF) para derivar uma chave de criptografia simétrica robusta da saída da PRF.
  4. Essa chave simétrica é usada com a WebCrypto (ex: AES-GCM) para criptografar ou descriptografar a informação alvo (como PII).
• Descriptografia Transparente em Logins Subsequentes: Quando o usuário se autentica novamente usando a mesma passkey, o Corbado Connect inicia a mesma solicitação de PRF. Isso produz a mesma saída PRF, permitindo que a aplicação re-derive a mesma chave simétrica e descriptografe as informações previamente armazenadas do lado do cliente.
• Inteligência de Adoção da PRF: Implementar a PRF requer saber se o ambiente do usuário (SO, navegador, autenticador) a suporta. O Corbado Connect coleta sinais sobre o dispositivo e as capacidades do usuário durante a autenticação. Essa inteligência pode ser usada para:
  • Determinar a prontidão para a PRF em toda a base de usuários antes de ativar totalmente os recursos dependentes da PRF.
  • Implementar a PRF de forma oportunista, fornecendo-a como uma melhoria para usuários suportados, enquanto mantém mecanismos de fallback (como solicitar uma nova verificação ou usar métodos alternativos) para aqueles sem suporte.
• Otimizando a Disponibilidade de PII: Ao usar a PRF para criptografar PII verificadas (ex: atributos de identidade obtidos através de um fluxo de verificação) e armazená-las do lado do cliente, as aplicações podem tornar esses dados imediatamente disponíveis após um login com passkey para interações ou transações subsequentes, reduzindo significativamente o atrito em comparação com fluxos de re-verificação ou baseados em aplicativos.
• Habilitando Sistemas E2EE Personalizados: Embora o Corbado Connect ofereça componentes de UI para fluxos padrão, os princípios subjacentes podem permitir que os desenvolvedores integrem a funcionalidade PRF mais profundamente em aplicações sensíveis. Isso permite a construção de sistemas criptografados de ponta a ponta, onde a aplicação frontend aproveita diretamente as chaves derivadas da PRF para operações criptográficas complexas em dados existentes ou novos. Por enquanto, isso ainda só será possível de forma oportunista, e mecanismos de fallback precisarão implementar uma maneira diferente de armazenar essas informações.

A Corbado visa simplificar as complexidades da integração de passkeys e PRF, permitindo que as empresas aproveitem os padrões de forma segura e eficaz, adaptando-se a casos de uso específicos como a criptografia de PII do lado do cliente, enquanto navegam pelo cenário em evolução.

A extensão PRF do WebAuthn marca um passo importante para tornar as aplicações verdadeiramente sem senha e com criptografia de ponta a ponta uma realidade prática. Ao aproveitar as passkeys para derivar chaves criptográficas de forma segura, ela proporciona uma experiência de usuário transparente e segura, sem comprometer a privacidade.

Respondendo diretamente às perguntas feitas no início deste artigo:

• Casos de uso interessantes da PRF: A PRF possibilita casos de uso atraentes, como armazenamento de dados com criptografia de ponta a ponta, desbloqueio de cofres sem senha para gerenciadores de senhas, esquemas seguros de rotação de chaves criptográficas e carteiras de identidade seguras ou sistemas sem custódia que protegem a privacidade do usuário, garantindo que as chaves privadas nunca saiam dos dispositivos do cliente.

• Estado atual do suporte à PRF (junho de 2025): O suporte permanece fragmentado e em evolução. Enquanto o Android tem um suporte robusto em navegadores e autenticadores, plataformas como macOS e especialmente iOS são instáveis, particularmente como fonte de CDA com um bug grave. O suporte no Windows é limitado principalmente a chaves de segurança externas, com o suporte da plataforma nativa via Windows Hello notavelmente ausente.

Os desenvolvedores que consideram a extensão PRF devem antecipar uma melhoria rápida, mas proceder com cautela, construindo aplicações resilientes que lidem graciosamente com as limitações atuais. À medida que uma adoção mais ampla surge nas principais plataformas e ecossistemas de autenticadores, o futuro da criptografia sem senha habilitada por PRF parece promissor, prometendo maior privacidade e usabilidade na autenticação web.