Passkeys com Códigos QR e Bluetooth: Transporte Híbrido

As passkeys estão cada vez mais a substituir as palavras-passe como o padrão de facto na autenticação de utilizadores. Ao contrário das palavras-passe tradicionais, as passkeys estão vinculadas a um ecossistema (por exemplo, iCloud Keychain, Google Password Manager, Windows Hello ou um gestor de palavras-passe como o 1Password ou o Dashlane); não são concebidas para serem memorizadas, mas sim para se integrarem perfeitamente com os seus dispositivos, oferecendo uma excelente experiência de utilizador imediata.

Imagine que está longe do seu computador pessoal, talvez num terminal público ou no portátil de um amigo, e precisa de iniciar sessão na sua conta protegida por passkey. Este cenário é bastante comum e necessita de um método de autenticação seguro e conveniente, mas com as passkeys, muitas pessoas não sabem o que fazer, pois a sua passkey não está imediatamente disponível nesta situação. Uma das funcionalidades das passkeys para o ajudar em tal situação é a capacidade de empregar as suas passkeys em múltiplos dispositivos através da facilitação de códigos QR e tecnologia Bluetooth. Este processo é formalmente conhecido como transporte híbrido na especificação WebAuthn (em versões anteriores da especificação, é referido como Bluetooth Low Energy assistido por nuvem, ou caBLE).

O processo é simples: precisa de um dispositivo que tenha as suas passkeys armazenadas e seja capaz de tirar fotografias, muito provavelmente um smartphone ou tablet. Este dispositivo pode abrir um túnel para o novo dispositivo apenas para essa instância de autenticação. Isto não só mantém a integridade da sua passkey, como também garante que o acesso à sua conta em novos dispositivos pode ser concedido, não importa onde esteja ou que dispositivo queira usar para iniciar sessão.

No entanto, esta funcionalidade de autenticação multiplataforma das passkeys está rodeada de equívocos e confusão, tanto na sua utilidade como na sua implementação técnica. Isto foi algo que notei novamente recentemente, quando visitei um encontro local de segurança de TI. Através deste artigo, pretendemos desvendar as complexidades e fornecer recomendações para implementar este fluxo de autenticação de passkey multiplataforma (transporte híbrido), garantindo que pode proporcionar a melhor experiência de início de sessão para os seus utilizadores.

As passkeys são uma forma de autenticação de utilizador que substitui a palavra-passe tradicional por um par de chaves criptográficas pública-privada mais seguro e conveniente. Este par de chaves é único para cada utilizador e é usado para verificar a identidade sem o incómodo de lembrar palavras-passe complexas.

As vantagens das passkeys são numerosas em comparação com as suas predecessoras, as palavras-passe. Elas reduzem significativamente o risco de phishing, pois não podem ser enganadas para serem partilhadas com um site falso. Além disso, são imunes a ataques de força bruta e de dicionário, que são métodos comuns usados para quebrar palavras-passe. As passkeys são também mais fáceis de usar, eliminando a necessidade de lembrar ou gerir uma longa lista de palavras-passe.

As passkeys são sincronizadas em contas na nuvem, como as geridas pelo Google Password Manager ou Apple iCloud Keychain (a Microsoft com o Windows Hello seguirá em breve), ou as armazenadas em gestores de palavras-passe modernos prontos para passkeys, como o 1Password ou o Dashlane. No entanto, é essencial saber que, por defeito, as passkeys estão vinculadas ao ecossistema e à respetiva sincronização da conta na nuvem. Os sistemas operativos não fornecem uma interface para exportar as chaves privadas e, na maioria dos dispositivos, existe um componente de hardware que fornece medidas de segurança adicionais para evitar qualquer acesso às chaves privadas, por exemplo, o Secure Enclave em dispositivos iOS ou o Trusted Platform Module (TPM) em dispositivos Windows. Apenas o fornecedor do sistema operativo pode sincronizar as passkeys com outros dispositivos de forma encriptada (em última análise, protegida pela biometria, código de acesso ou PIN do utilizador). As chaves privadas só podem ser restauradas e desencriptadas usando o código de acesso / PIN e serão destruídas caso haja demasiadas tentativas de início de sessão sem sucesso na conta na nuvem (por exemplo, a Apple introduz um limite de taxa para prevenir ataques de força bruta mesmo a partir de uma posição privilegiada no backend da nuvem; a Google faz o mesmo).

Este design inerente significa que, se as passkeys não forem sincronizadas como descrito, aceder às suas passkeys num novo dispositivo pode representar um desafio. É precisamente por isso que existe o método de transporte híbrido para autenticação multiplataforma de passkeys (transporte híbrido) com código QR e verificação de proximidade por Bluetooth. Ele fornece uma ponte segura para as suas passkeys entre dispositivos sem a necessidade de as sincronizar através de uma conta na nuvem / gestor de palavras-passe, mantendo assim o princípio de que as passkeys podem permanecer exclusivamente com o utilizador.

A utilização da autenticação de passkey multiplataforma (transporte híbrido) ajuda a superar problemas entre dispositivos, quando uma conta é acedida puramente através de passkeys. Como nem todas as passkeys são sincronizadas em contas na nuvem ou gestores de palavras-passe, a necessidade de um método fiável para aceder a passkeys em diferentes dispositivos torna-se crítica, especialmente ao transitar para um novo dispositivo ou ao precisar de acesso num dispositivo partilhado.

Para facilitar a autenticação de passkey multiplataforma (transporte híbrido), existem os seguintes requisitos de hardware:

• Suporte WebAuthn: Os dispositivos devem suportar WebAuthn. Isto já é uma realidade em 99% dos dispositivos, de acordo com a nossa última análise de dados de passkeys.
• Câmara para Leitura de Códigos QR: Os dispositivos precisarão de uma câmara capaz de ler códigos QR. A maioria dos smartphones modernos está equipada com câmaras que têm esta funcionalidade. Além disso, a câmara precisa de capacidades de leitura de QR incorporadas (o que a maioria dos dispositivos tem de origem). Se a sua câmara não suportar, um leitor de QR online também é uma boa opção. Caso contrário, instalar uma aplicação de código QR também serve.
• Capacidade Bluetooth: O Bluetooth Low Energy assistido por nuvem (caBLE) é usado para estabelecer uma ligação segura baseada na proximidade entre dispositivos. As versões a procurar são Bluetooth 4.0 ou superior, que permitem a extensão caBLE para WebAuthn.
• Ligação à Internet: É necessária uma ligação estável à Internet em ambos os dispositivos, pois a troca envolve a abertura de um túnel para realizar passos de verificação que requerem transferência de dados em tempo real.

Do ponto de vista do software, existem os seguintes requisitos:

• Configuração do Servidor WebAuthn: Obviamente, precisa de ter um servidor WebAuthn implementado que gira as chaves públicas. Isto também envolve permitir que a conta do utilizador seja associada a múltiplos autenticadores e configurar o servidor para iniciar a cerimónia de autenticação.
• API Web Bluetooth: Para a verificação de proximidade por Bluetooth, precisará de aceder à API Web Bluetooth que aciona as capacidades Bluetooth do dispositivo a partir de um navegador.
• Requisitos do Sistema Operativo: Por favor, consulte a seguinte tabela sobre o suporte da Autenticação Entre Dispositivos para diferentes sistemas operativos a partir de março de 2025. Autenticador significa que o dispositivo pode servir como o dispositivo que detém uma passkey (no nosso cenário, o smartphone). Cliente significa o dispositivo que cria o código QR e onde o utilizador tenta iniciar sessão (no nosso cenário, o desktop):

Fonte: passkeys.dev

O processo para usar a autenticação de passkey multiplataforma (transporte híbrido) através de código QR é o seguinte:

O código QR para a autenticação de passkey multiplataforma (transporte híbrido) é gerado quando um utilizador tenta aceder a um serviço num dispositivo onde a passkey registada não está presente, mas o serviço sabe que o utilizador deveria ter uma passkey. Normalmente, um botão "Ler código QR" ou uma chamada para ação semelhante é fornecida na interface de autenticação.

A pedido do utilizador, o dispositivo inicia a geração de um código QR. Este código QR codifica um identificador de sessão único e sensível ao tempo. Este identificador está ligado a uma sessão que o servidor de autenticação mantém temporariamente, aguardando a conclusão do processo de autenticação.

O utilizador lê este código QR com um dispositivo onde a sua passkey está disponível. As medidas de segurança incluem:

• Uso único: O identificador de sessão dentro do código QR é válido para um único uso, prevenindo ataques de repetição.
• Encriptação: Todos os dados dentro do código QR são encriptados, garantindo que qualquer comunicação intercetada não possa ser decifrada por partes não autorizadas.

O código QR lido contém um URI específico com o esquema FIDO, por exemplo: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

A leitura do código QR faz com que o segundo dispositivo do utilizador (por exemplo, smartphone ou tablet) interprete o URI FIDO e comunique com o servidor de autenticação, enviando um sinal de que o utilizador está a tentar autenticar-se através de um novo dispositivo (por exemplo, o portátil do amigo). Esta ação leva o servidor a gerar um desafio criptográfico, único para esta tentativa de autenticação.

O desafio é enviado de volta para o segundo dispositivo do utilizador (por exemplo, smartphone ou tablet), onde a sua passkey está armazenada. O dispositivo cria então uma assinatura digital usando a chave privada associada à passkey, sem que a chave privada saia do dispositivo (por exemplo, smartphone ou tablet). O desafio assinado (assinatura) é então enviado de volta para o servidor através de um túnel seguro e encriptado pela internet, verificando a integridade e a origem da tentativa de autenticação.

O servidor valida a assinatura usando a chave pública correspondente já associada à conta do utilizador. Após a validação bem-sucedida, o servidor confirma a autenticação, permitindo que o utilizador aceda ao serviço no novo dispositivo.

Alguns aspetos mais importantes de privacidade e segurança a considerar:

• Sem Troca de Dados por Bluetooth, Apenas Internet: É importante notar que nesta autenticação de passkey multiplataforma baseada em código QR (transporte híbrido), o Bluetooth não está envolvido na troca de dados. Este processo depende inteiramente de uma ligação à Internet para a transmissão de dados encriptados entre os dispositivos e o servidor. No entanto, o Bluetooth é usado para uma verificação de proximidade dos dois dispositivos.
• As Chaves Privadas Não Saem do Dispositivo: Durante todo este processo, as chaves privadas do utilizador permanecem seguras no seu dispositivo.
• Sem Exposição de Dados Sensíveis: Nenhuma informação sensível de passkey ou chaves privadas é transferida ou exposta durante o processo de autenticação.
• Criptografia Assimétrica: O mecanismo de desafio-resposta garante que o que está a ser enviado são meramente versões não reutilizáveis e assinadas de desafios que não podem ser explorados para acesso não autorizado.

Ao aderir a estes protocolos técnicos e de segurança, o método de código QR para autenticação de passkey multiplataforma (transporte híbrido) mantém um alto padrão de segurança, ao mesmo tempo que fornece uma forma conveniente para os utilizadores autenticarem as suas identidades em novos dispositivos.

Além do processo de leitura de código QR, existe também a verificação de proximidade via Bluetooth (caBLE). Ter a certeza de que o cliente e o autenticador estão fisicamente próximos um do outro é um dos principais benefícios do protocolo WebAuthn. Mais detalhes sobre o funcionamento interno deste processo são descritos a seguir:

Bluetooth Low Energy (BLE) é uma tecnologia de comunicação sem fios projetada para a troca de dados a curta distância. Desempenha um papel fundamental na confirmação da proximidade física dos dispositivos durante o processo de autenticação.

caBLE é um protocolo que facilita a transferência segura de informações de autenticação entre dispositivos usando BLE. Ao usar caBLE para autenticação de passkey multiplataforma (transporte híbrido), o dispositivo que detém a passkey confirma a proximidade do dispositivo solicitante através de sinais BLE. Uma vez verificada a proximidade, o processo de autenticação prossegue, utilizando o BLE para uma comunicação local e segura.

A experiência do utilizador é melhorada, pois este método geralmente requer menos interação direta do utilizador; dispositivos em proximidade física detetam-se automaticamente. Para a segurança, o caBLE oferece uma vantagem significativa - garante que o processo de autenticação só é realizado quando os dois dispositivos estão próximos um do outro, impedindo que atacantes remotos iniciem o processo de autenticação.

Imagine receber um código QR que redireciona para um site malicioso. Se a autenticação for realizada através deste código QR, existe o risco de a sessão ou o cookie poderem ser sequestrados. O BLE contorna este problema ao não depender de uma leitura visual, mas sim da presença física dos dispositivos. Esta verificação de proximidade minimiza o risco de ataques man-in-the-middle, pois a verificação de proximidade não ocorre pela internet ou por um meio visual.

Ao contrário de outros métodos, o caBLE não troca dados de autenticação como as passkeys. Em vez disso, usa o BLE como um canal de confirmação para estabelecer que os dispositivos estão fisicamente próximos. Esta verificação é projetada para ser parte de um processo de autenticação multifator onde a proximidade BLE é um dos fatores, garantindo que, mesmo que outros fatores sejam comprometidos, sem a proximidade física, o acesso não é concedido.

Ao integrar o protocolo caBLE, os programadores podem oferecer um método seguro e fácil de usar para a autenticação de passkey multiplataforma (transporte híbrido) que melhora a segurança geral do processo de autenticação. A verificação de proximidade adiciona uma camada adicional de proteção que é simples para os utilizadores e, no entanto, protege eficazmente contra certos tipos de ciberataques sofisticados.

Existem os seguintes benefícios deste método de autenticação de passkey multiplataforma (transporte híbrido):

A autenticação de passkey multiplataforma via código QR e Bluetooth (transporte híbrido) é uma forma de melhorar a UX em cenários multiplataforma em comparação com não oferecer qualquer possibilidade. No entanto, o fluxo do utilizador é absolutamente novo para a maioria dos utilizadores e não esperamos que muitos utilizadores não técnicos entendam o que está a acontecer quando se deparam com este fluxo pela primeira vez. A única semelhança da introdução do fluxo de código QR pode ser com os fluxos de início de sessão para, por exemplo, WhatsApp Web ou Discord, onde são empregados códigos QR (aqui a funcionalidade é diferente, no entanto). Assim, o processo de autenticação de passkey multiplataforma analisado via código QR / Bluetooth (transporte híbrido) minimiza o esforço do utilizador no cenário multiplataforma, pois não há necessidade de inserir manualmente quaisquer credenciais, mas ainda assim o fluxo geral é desconhecido para a maioria dos utilizadores.

A segurança da autenticação de passkey multiplataforma (transporte híbrido) é reforçada por técnicas criptográficas avançadas. Quando um código QR é lido ou uma ligação Bluetooth é feita para autenticação, desafios e respostas criptográficas garantem que apenas o dispositivo pretendido pode concluir com sucesso o processo de autenticação.

As verificações de proximidade via Bluetooth adicionam uma camada adicional de segurança, confirmando que a tentativa de autenticação está a ser feita por alguém com acesso físico ao dispositivo secundário.

Durante o processo de autenticação multiplataforma (transporte híbrido), as passkeys nunca são armazenadas temporariamente em dispositivos ou servidores intermediários, o que previne o risco de as passkeys serem intercetadas ou vazadas durante o processo de transferência. A autenticação acontece em tempo real, e a passkey permanece vinculada ao dispositivo principal do utilizador, preservando a sua integridade.

Os métodos de autenticação por código QR e Bluetooth fornecem inerentemente proteção contra phishing. É menos provável que os utilizadores sejam enganados a fornecer uma passkey para um site malicioso porque o processo de autenticação requer ações físicas que são específicas dos dispositivos de confiança do utilizador.

O processo de ler um código QR ou conectar-se via Bluetooth geralmente acontece num ambiente de confiança, reduzindo a chance de os utilizadores comprometerem inadvertidamente as suas credenciais.

Existem as seguintes desvantagens deste método de autenticação de passkey multiplataforma (transporte híbrido):

A introdução de qualquer nova tecnologia pode levar à confusão do utilizador, especialmente se os utilizadores não forem tecnicamente experientes. A autenticação de passkey multiplataforma via código QR e Bluetooth (transporte híbrido) é uma mudança significativa em relação aos métodos de autenticação tradicionais, e alguns utilizadores podem achar o novo processo difícil de entender, levando potencialmente a uma taxa de adoção mais lenta. No entanto, esperamos que os utilizadores acabem por se habituar, pelo que a mudança pode ser mais difícil no início e tornar-se-á mais suave e mais aceite ao longo do tempo.

O sucesso da autenticação de passkey multiplataforma (transporte híbrido) depende fortemente de o dispositivo do utilizador ter as capacidades necessárias, como uma câmara que pode ler códigos QR e funcionalidade Bluetooth. Utilizadores com dispositivos mais antigos que não possuem estas funcionalidades não poderão tirar partido da autenticação de passkey multiplataforma (transporte híbrido), criando uma exclusão digital baseada em limitações de hardware.

O comportamento do utilizador pode ser imprevisível, e a dependência de os utilizadores realizarem ações específicas como ler um código QR ou ativar o Bluetooth pode introduzir erros do utilizador. Por exemplo, o Bluetooth pode por vezes ser visto como um desafio de UX devido a problemas de emparelhamento, problemas de descoberta e desconfiança geral do utilizador em tecnologias sem fios para transações seguras.

Os programadores enfrentam a tarefa de atualizar e manter constantemente os sistemas para suportar os métodos de autenticação mais recentes. A integração da autenticação de passkey multiplataforma (transporte híbrido) em sistemas existentes exige que os programadores se mantenham a par de novos padrões, adotem novas APIs e garantam a retrocompatibilidade, o que pode ser intensivo em recursos e demorado.

Para cada novo dispositivo ou pedido de início de sessão subsequente, uma nova passkey precisa de ser criada se não estiver a usar uma conta na nuvem sincronizada como o iCloud Keychain ou um gestor de palavras-passe. Isto pode adicionar complexidade à experiência do utilizador e pode criar frustração se os utilizadores não estiverem familiarizados com o processo ou se este não for intuitivo.

Existe uma necessidade inerente de educação do utilizador ao implementar novos métodos de segurança como a autenticação de passkey multiplataforma (transporte híbrido). Garantir que os utilizadores entendem como usar códigos QR e Bluetooth de forma segura requer uma comunicação clara e, possivelmente, um suporte ao cliente extensivo.

Embora a autenticação de passkey multiplataforma via código QR e Bluetooth (transporte híbrido) represente um avanço significativo na tecnologia de autenticação, estas potenciais desvantagens destacam a necessidade de um design amigável, sistemas de suporte robustos e uma transição gradual e bem comunicada dos métodos tradicionais para os inovadores. Tal como em qualquer mudança tecnológica, equilibrar os benefícios da inovação com os seus desafios será a chave para uma implementação bem-sucedida e uma ampla aceitação por parte do utilizador.

Como aviso: estamos a ignorar as chaves de segurança de hardware (por exemplo, YubiKeys) no teste seguinte e a usar apenas autenticadores de plataforma que estão integrados nos dispositivos (por exemplo, Face ID, Touch ID, Windows Hello). No caso de chaves de segurança de hardware (por exemplo, YubiKey), os valores para transports seriam [usb ou nfc](https://www.w3.org/TR/webauthn-2/#enum-transport), por exemplo.

Estamos a usar as seguintes combinações de dispositivo / navegador e o Passkeys Debugger para testar o comportamento. O Android não é considerado, pois o Android não pode servir como cliente de autenticação multiplataforma (transporte híbrido) (ver tabela acima):

Para testar o comportamento, criamos para cada combinação uma nova passkey com as seguintes propriedades:

• userName: alex muller (sem influência neste teste)
• authenticatorAttachment: platform (pois queremos excluir chaves de segurança de hardware como YubiKeys)
• residentKey: preferred (sem influência neste teste)
• userVerification: preferred (sem influência neste teste)
• attestation: none (sem influência neste teste)
• hints: empty (ver explicação abaixo)
• usePRF: no (sem influência neste teste)

Após a criação bem-sucedida da passkey, modificamos a entrada da propriedade do servidor WebAuthn allowCredentials e iniciamos um pedido de início de sessão. Queremos simular uma passkey eliminada no dispositivo onde criámos a passkey, para que o dispositivo / navegador procure outro dispositivo que possa fornecer uma passkey via código QR / Bluetooth. Portanto, alteramos o ID da credencial e atribuímos o valor CHANGED-ID, para que a correspondência falhe. Além disso, alteramos a propriedade transports de uma credencial WebAuthn em allowCredentials e atribuímos para cada combinação de dispositivo / navegador os seguintes valores:

1. transports: [internal, hybrid]: As passkeys podem ser usadas a partir do autenticador de plataforma (por exemplo, Face ID, Touch ID, Windows Hello) ou via autenticação multiplataforma
2. transports: [internal]: As passkeys podem ser usadas a partir do autenticador de plataforma (por exemplo, Face ID, Touch ID, Windows Hello)
3. Nenhuma propriedade transports definida: comportamento padrão que não impõe restrições

No site de testes WebAuthn, existe também a nova funcionalidade do WebAuthn Level 3 para dicas de agentes de utilizador (hints). Esta funcionalidade pode melhorar a experiência do utilizador se a parte confiável tiver certas suposições sobre como o pedido de início de sessão pode ser concluído da forma mais amigável para o utilizador. Neste teste, desconsiderámos esta funcionalidade, pois ainda não foi implementada. Por favor, consulte as especificações para mais detalhes.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

De forma bastante confusa, o código QR também é exibido aqui, mesmo que apenas permitamos credenciais internas. Não conseguimos encontrar uma razão válida para este comportamento.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

Por alguma razão, partes do modal aparecem em alemão, que é um dos idiomas instalados.

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR, via dispositivos conhecidos e via chaves de segurança de hardware.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

De forma bastante confusa, o código QR também é exibido aqui, mesmo que apenas permitamos credenciais internas. Não conseguimos encontrar uma razão válida para este comportamento.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

Por alguma razão, partes do modal aparecem em alemão, que é um dos idiomas instalados.

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR, via dispositivos conhecidos e via chaves de segurança de hardware.

Ao criar a passkey, recebemos o seguinte erro (ainda assim, uma passkey foi criada):

erro: TypeError: 'toJSON' chamado num objeto que não implementa a interface PublicKeyCredential.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

De forma bastante confusa, o código QR também é exibido aqui, mesmo que apenas permitamos credenciais internas. Não conseguimos encontrar uma razão válida para este comportamento.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

Por alguma razão, partes do modal aparecem em alemão, que é um dos idiomas instalados.

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR, via dispositivos conhecidos e via chaves de segurança de hardware.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador). Além disso, pode selecionar diretamente um dos dispositivos conhecidos para usar uma passkey a partir daí.

O modal é bastante diferente do seu equivalente no Windows no Chrome 119.

Este é um comportamento esperado, pois apenas permitimos o uso de passkeys internas, mas não conseguimos encontrar uma credencial interna no dispositivo (não temos permissão para usar passkeys híbridas). A autenticação da passkey falha neste passo e, em implementações reais, seria necessário fornecer um método de autenticação de recurso.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador de plataforma cruzada / autenticador itinerante. Além disso, pode selecionar diretamente um dos dispositivos conhecidos para usar uma passkey a partir daí.

O modal é bastante diferente do seu equivalente no Windows no Chrome 119.

Como esperado, todas as formas de autenticação por passkey são permitidas: via Touch ID, via código QR, via dispositivos conhecidos e via chaves de segurança de hardware.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

De forma bastante confusa, o código QR também é exibido aqui, mesmo que apenas permitamos credenciais internas. Não conseguimos encontrar uma razão válida para este comportamento.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

Como esperado, a maioria das formas de autenticação por passkey são permitidas: via Touch ID, via código QR e via chaves de segurança de hardware. Por alguma razão, os dispositivos conhecidos não são exibidos.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

De forma bastante confusa, o código QR também é exibido aqui, mesmo que apenas permitamos credenciais internas. Não conseguimos encontrar uma razão válida para este comportamento.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

Como esperado, a maioria das formas de autenticação por passkey são permitidas: via Face ID, via código QR e via chaves de segurança de hardware. Por alguma razão, os dispositivos conhecidos não são exibidos.

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

De forma bastante confusa, o código QR também é exibido aqui, mesmo que apenas permitamos credenciais internas. Não conseguimos encontrar uma razão válida para este comportamento.

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

Como esperado, a maioria das formas de autenticação por passkey são permitidas: via Face ID, via código QR e via chaves de segurança de hardware. Por alguma razão, os dispositivos conhecidos não são exibidos.

Em seguida, para dispositivos com Windows 10, decidimos ir um nível mais além e analisar como o comportamento se parece se o Bluetooth estiver desativado ou não disponível numa máquina com Windows 10 em geral. Especialmente para dispositivos de desktop mais antigos, este ainda é um cenário muito comum, pois esses dispositivos muitas vezes não têm um módulo Bluetooth, tornando impossível a autenticação multiplataforma via código QR e Bluetooth.

8.8.1.1 transports: [internal, hybrid]

Como esperado, nenhuma passkey local corresponde, por isso é sugerido usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador - primeira captura de ecrã) ou escolher ler o código QR (segunda captura de ecrã).

8.8.1.2 transports: [internal]

De forma bastante confusa, é-lhe solicitado que insira o seu código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.8.1.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.8.1.4 allowCredentials vazio

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR, via dispositivos conhecidos e via chaves de segurança de hardware.

8.8.2.1 transports: [internal, hybrid]

Esta é uma mensagem realmente confusa para os utilizadores, pois não é explicitamente declarado o que devem fazer e como podem autenticar-se. A única opção que têm é clicar em "Cancelar", tornando este cenário um beco sem saída.

8.8.2.2 transports: [internal]

Este comportamento é o mesmo do caso em que o Bluetooth está ativado. É muito confuso que o utilizador seja solicitado a inserir o código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.8.2.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso a única opção que tem é usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.8.2.4 allowCredentials vazio

A autenticação por passkey só é possível via Windows Hello e chaves de segurança de hardware.

8.9.1.1 transports: [internal, hybrid]

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

8.9.1.2 transports: [internal]

De forma bastante confusa, é-lhe solicitado que insira o seu código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.9.1.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.9.1.4 allowCredentials vazio

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR e via chaves de segurança de hardware. Por alguma razão, os dispositivos conhecidos não são exibidos.

8.9.2.1 transports: [internal, hybrid]

Esta é uma mensagem realmente confusa para os utilizadores, pois não é explicitamente declarado o que devem fazer e como podem autenticar-se. A única opção que têm é clicar em "Cancelar", tornando este cenário um beco sem saída.

8.9.2.2 transports: [internal]

Este comportamento é o mesmo do caso em que o Bluetooth está ativado. É muito confuso que o utilizador seja solicitado a inserir o código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.9.2.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso a única opção que tem é usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.9.2.4 allowCredentials vazio

A autenticação por passkey só é possível via Windows Hello e chaves de segurança de hardware.

8.10.1.1 transports: [internal, hybrid]

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

8.10.1.2 transports: [internal]

De forma bastante confusa, é-lhe solicitado que insira o seu código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.10.1.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.10.1.4 allowCredentials vazio

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR e via chaves de segurança de hardware. Por alguma razão, os dispositivos conhecidos não são exibidos.

8.10.2.1 transports: [internal, hybrid]

Esta é uma mensagem realmente confusa para os utilizadores, pois não é explicitamente declarado o que devem fazer e como podem autenticar-se. A única opção que têm é clicar em "Cancelar", tornando este cenário um beco sem saída. Por alguma razão, partes do modal de Segurança do Windows também são exibidas em alemão (um segundo idioma instalado neste dispositivo).

8.10.2.2 transports: [internal]

Este comportamento é o mesmo do caso em que o Bluetooth está ativado. É muito confuso que o utilizador seja solicitado a inserir o código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.10.2.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso a única opção que tem é usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.10.2.4 allowCredentials vazio

A autenticação por passkey só é possível via Windows Hello e chaves de segurança de hardware.

8.11.1.1 transports: [internal, hybrid]

Como esperado, nenhuma passkey local corresponde, por isso é sugerido ler o código QR e usar a passkey noutro dispositivo (pois o sistema sabe que existe uma passkey para este utilizador).

8.11.1.2 transports: [internal]

De forma bastante confusa, é-lhe solicitado que insira o seu código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.11.1.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso é sugerido ler o código QR ou usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.11.1.4 allowCredentials vazio

Como esperado, todas as formas de autenticação por passkey são permitidas: via Windows Hello, via código QR e via chaves de segurança de hardware. Por alguma razão, os dispositivos conhecidos não são exibidos.

8.11.2.1 transports: [internal, hybrid]

Esta é uma mensagem realmente confusa para os utilizadores, pois não é explicitamente declarado o que devem fazer e como podem autenticar-se. A única opção que têm é clicar em "Cancelar", tornando este cenário um beco sem saída.

8.11.2.2 transports: [internal]

Este comportamento é o mesmo do caso em que o Bluetooth está ativado. É muito confuso que o utilizador seja solicitado a inserir o código PIN do Windows Hello (ou impressão digital / leitura facial, se configurado no dispositivo), mesmo que tenhamos alterado o ID da credencial (portanto, não deveria encontrar a credencial, pois não está especificada na propriedade allowCredentials). No entanto, após submeter o código PIN do Windows Hello, é lançado um erro: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Do ponto de vista do utilizador, este é um comportamento bastante confuso, mas faz sentido, pois poderia fornecer informações sobre as passkeys do utilizador sem o seu consentimento.

8.11.2.3 Nenhuma propriedade transports definida

Nenhuma passkey local corresponde, por isso a única opção que tem é usar uma chave de segurança de hardware (por exemplo, YubiKey) / autenticador multiplataforma / autenticador itinerante.

8.11.2.4 allowCredentials vazio

A autenticação por passkey só é possível via Windows Hello e chaves de segurança de hardware.

• Use bibliotecas e frameworks que abstraem algumas das complexidades da API WebAuthn pura.
• Considere cenários de autenticação multiplataforma desde o início para garantir que uma base ampla de utilizadores possa beneficiar da sua implementação de passkeys. Dependendo das suas escolhas de design, também pode oferecer métodos de início de sessão alternativos nestes cenários.
• Desenvolva mecanismos de recurso para cenários onde a autenticação multiplataforma de passkey (transporte híbrido) possa não ser possível devido a limitações do dispositivo.
• A maior decisão de design é decidir se quer promover a autenticação de passkey multiplataforma via código QR / Bluetooth (transporte híbrido) e torná-la um método proeminente para autenticação de passkey ou usar dicas para não a promover ativamente. Neste último caso, tenta-se sempre usar imediatamente as passkeys armazenadas internamente e só se nenhuma passkey interna for encontrada, um código QR para autenticação multiplataforma (transporte híbrido) é exibido. Isto precisa de ser definido nas opções do seu servidor WebAuthn nas propriedades excludeCredentials e allowCredentials. Na propriedade excludeCredentials do seu servidor WebAuthn, pode ver informações de transporte sobre credenciais já criadas. Na propriedade allowCredentials, pode especificar o comportamento no processo de início de sessão (ver testes acima).
• Além disso, não pode impedir completamente a autenticação de passkey multiplataforma (transporte híbrido) (ver os testes acima com transports: [internal]), por isso precisa de estar preparado para que os seus utilizadores encontrem este método e tenham perguntas. A ocorrência desta autenticação multiplataforma (transporte híbrido) ocorrerá em particular se os utilizadores começarem a eliminar passkeys localmente.

• Crie guias e tutoriais abrangentes que orientem os utilizadores através do processo de autenticação de passkey multiplataforma (transporte híbrido).
• Use dicas de ferramentas na aplicação e secções de ajuda contextual para guiar os utilizadores durante a sua primeira experiência de autenticação de passkey multiplataforma (transporte híbrido).
• Forneça FAQs e secções de resolução de problemas no seu site ou dentro da aplicação.

• Implemente sessões com limite de tempo para inícios de sessão com passkey via código QR ou Bluetooth para garantir que o acesso é apenas temporário e seguro.
• Garanta que a autenticação de passkey multiplataforma (transporte híbrido) não compromete quaisquer protocolos de segurança existentes, mantendo a integridade dos dados do utilizador.
• Considere as implicações de privacidade e garanta que qualquer acesso temporário concedido via autenticação de passkey multiplataforma (transporte híbrido) seja registado e monitorizado de acordo com as melhores práticas de segurança.

A autenticação de passkey multiplataforma via código QR / Bluetooth (transporte híbrido) oferece um equilíbrio entre segurança e UX. No entanto, é um processo inteiramente novo para a maioria dos utilizadores e pode causar muitas situações confusas, pelo que é necessário pensar cuidadosamente se o quer promover.

Esperamos ter conseguido lançar alguma luz sobre o tema da autenticação de passkey multiplataforma (transporte híbrido) via código QR / Bluetooth, explicar como configurar as coisas e como o comportamento se parece em diferentes combinações de dispositivo / navegador. Se tiver alguma questão, sinta-se à vontade para nos contactar através da nossa comunidade de passkeys ou subscrever o nosso Substack de passkeys. Vamos tornar a Internet um lugar mais seguro, divulgando as passkeys.