Chave Residente WebAuthn: Credenciais Detectáveis como Passkeys

As Passkeys e o protocolo subjacente WebAuthn estão a revolucionar o panorama da autenticação. No entanto, configurar um servidor WebAuthn da forma correta pode ser uma tarefa complicada. Configurações incorretas podem não só introduzir vulnerabilidades, mas também quebrar passkeys existentes se precisar de as alterar mais tarde. O seguinte artigo de blog deve ajudá-lo a entender melhor as especificações muitas vezes complexas do WebAuthn e dar-lhe conselhos sobre quais as configurações mais adequadas para o seu caso de uso.

O WebAuthn opera com três entidades principais:

• Relying Party (RP): Este é o seu serviço web que deseja autenticar um utilizador. Envia desafios ao cliente, verifica respostas e gere a chave pública de uma passkey.
• Autenticadores: São dispositivos que podem provar a posse de uma credencial. Exemplos incluem smartphones, portáteis ou chaves de segurança (por exemplo, YubiKeys). Os Autenticadores podem ser específicos da plataforma (como o Windows Hello ou o Touch ID / Face ID da Apple) ou multiplataforma (como chaves de segurança, por exemplo, YubiKeys).
• Clientes: Normalmente, são navegadores web ou aplicações nativas que atuam como intermediários entre a RP e o autenticador. Facilitam a comunicação, garantindo que os dados fluem de forma correta e segura.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Em seguida, descreve-se o fluxo de dados de alto nível durante um processo de autenticação (seja login ou registo).

1. Iniciação do Cliente: O processo começa do lado do cliente, geralmente quando um utilizador tenta fazer login ou registar-se. Por exemplo, pode clicar num botão "Login com WebAuthn" e o cliente envia um pedido de desafio para a RP.
2. Pedido da RP: A RP envia então um desafio de volta para o cliente. Este desafio é um valor gerado aleatoriamente que garante a autenticidade da resposta subsequente.
3. Cliente para Autenticador: Durante o registo, o cliente solicita ao autenticador que crie uma nova passkey, criando o par de chaves pública-privada correspondente. Durante o login, o cliente solicita ao autenticador que assine o desafio. Isto é feito usando a chave privada no autenticador, que corresponde a uma chave pública previamente registada e armazenada na RP.
4. Resposta do Autenticador: Durante o registo, o autenticador envia de volta a chave pública para o cliente. Durante o login, o autenticador assina o desafio e envia esta asserção assinada de volta para o cliente.
5. Cliente para RP: O cliente encaminha esta nova chave pública / a asserção assinada para a RP.
6. Verificação da RP: A RP armazena a chave pública / verifica a asserção assinada usando a chave pública armazenada. Se for válida, a autenticação é bem-sucedida.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Mais de 10.000 desenvolvedores confiam na Corbado e tornam a Internet mais segura com passkeys. Tem perguntas? Já escrevemos mais de 150 posts no blog sobre passkeys.

Junte-se à Comunidade Passkeys

O fluxo de processo de alto nível descrito acima descreve os processos de registo e login do WebAuthn. As Passkeys são construídas sobre o WebAuthn. Originalmente, o termo passkeys era usado como um termo mais memorável e não técnico do que WebAuthn para descrever a mesma coisa. Além disso, as passkeys oferecem mais funcionalidades em comparação com o WebAuthn padrão, como a possibilidade de sincronizar passkeys através de contas na nuvem ou gestores de palavras-passe.

Para entender melhor as secções seguintes, definimos alguns termos importantes no protocolo WebAuthn para termos um entendimento comum.

• ID da Credencial: O ID da Credencial é um identificador único atribuído a uma credencial de chave pública específica gerada por um autenticador. Permite que as Relying Parties (RPs) identifiquem e selecionem a PublicKeyCredential correta para os processos de autenticação.
• PublicKeyCredential: Esta é a principal estrutura de dados retornada da API WebAuthn do navegador ou de aplicações nativas. Abrange tanto os dados de Atestado durante o registo quanto os dados de Asserção durante o login. Essencialmente, contém os dados que a RP precisa para verificar o processo.
• Atestado (Attestation): O Atestado no contexto do WebAuthn serve como prova da origem e integridade do autenticador. Durante o registo, é uma forma de o autenticador dizer: "Registei a credencial do utilizador com segurança, e aqui está uma declaração que pode usar para verificar isso". A Relying Party pode então verificar se a assinatura provém de um autenticador específico permitido (por exemplo, Yubikey). Nem todos os autenticadores de passkey respondem com tal atestado, alguns simplesmente não enviam dados úteis (veja aqui a lista de autenticadores de passkeys). Mais AAGUIDs (Authenticator Attestation GUIDs) que identificam mais autenticadores (principalmente chaves de segurança, por exemplo, YubiKeys) podem ser encontrados no FIDO Alliance Metadata Service.
• Asserção (Assertion): Após o processo de registo, quando um utilizador tenta fazer login, o autenticador produz uma asserção. A asserção é basicamente a PublicKeyCredential + o desafio assinado. Esta asserção prova que o utilizador possui a chave privada ligada à chave pública registada, sem revelar a chave privada real. É a forma de o autenticador dizer: "Este é o utilizador genuíno, e eu posso garantir por ele."

Subscribe to our Passkeys Substack for the latest news.

Subscribe

As chaves residentes (RKs) e as chaves não residentes (NRKs) são dois tipos de chaves criptográficas usadas no protocolo WebAuthn, e diferem principalmente no seu local de armazenamento e mecanismo de recuperação.

Definição:

As chaves residentes são armazenadas diretamente no próprio autenticador. Pode ser uma chave de segurança (por exemplo, YubiKey), um enclave seguro da plataforma (por exemplo, o Secure Enclave do iPhone), ou um módulo de plataforma confiável (TPM) num portátil. A IU Condicional (preenchimento automático de passkey) só funciona para chaves residentes e o grupo de trabalho do WebAuthn atualmente exige que as chaves residentes sejam consideradas como uma passkey.

Na captura de ecrã seguinte, vê-se uma lista de todas as chaves residentes (ID da credencial, rpID, nome de utilizador, nome de exibição) que estão armazenadas numa YubiKey. As chaves não residentes não estão na lista, pois não são armazenadas no autenticador:

Fluxo de login:

Fonte: William Brown

Durante o processo de login, a Relying Party envia um pedido sem especificar credenciais ao cliente (navegador) que começa a consultar o autenticador (aqui no gráfico: chave de segurança). O autenticador descobre todas as chaves residentes para a Relying Party correspondente e o cliente (navegador) seleciona a chave residente desejada. Esta chave residente é usada para assinar o desafio. A assinatura é enviada do autenticador através do cliente para a Relying Party.

Vantagens:

1. Experiência do Utilizador Simplificada: Uma das vantagens mais significativas das chaves residentes é que o autenticador armazena o identificador de utilizador (por exemplo, e-mail, número de telefone, nome de utilizador) e, assim, pode pré-preencher o identificador de utilizador (por exemplo, e-mail, número de telefone, nome de utilizador) para o login. Os utilizadores não precisam de se lembrar ou inserir identificadores de utilizador, simplificando o processo de login, especialmente em dispositivos com capacidades biométricas. Isto também pode acontecer automaticamente com a IU Condicional.
2. Autenticação Específica do Dispositivo: As chaves residentes podem fornecer uma camada adicional de segurança ao vincular a autenticação a um dispositivo específico. Isto pode ser particularmente útil para serviços que querem garantir que os utilizadores estão a fazer login a partir de dispositivos confiáveis.
3. IU Condicional (Preenchimento Automático de Passkey): A IU Condicional só funciona com chaves residentes, proporcionando a experiência de login mais fluida (veja abaixo para detalhes).

Desvantagens:

1. Limitação de Armazenamento: Alguns autenticadores têm uma capacidade de armazenamento finita. Especialmente para chaves de segurança (por exemplo, YubiKeys), há muitas vezes um limite para o número de chaves residentes que podem armazenar (a maioria tem um limite que varia de 8 a ~100 chaves residentes). Uma vez atingido este limite, as chaves mais antigas podem precisar de ser eliminadas para dar espaço a novas, ou o utilizador pode precisar de usar outro autenticador.
2. Perda do Autenticador: Se o autenticador, por exemplo, uma chave de segurança (por exemplo, YubiKey) ou smartphone, for perdido ou danificado, todas as chaves residentes nesse dispositivo são perdidas. Isto pode bloquear os utilizadores de vários serviços até que se registem novamente ou recuperem as suas contas. A sincronização de chaves através de uma conta na nuvem (por exemplo, iCloud Keychain, Google Password Manager) ou um gestor de palavras-passe moderno (por exemplo, 1Password ou Dashlane) previne esta perda.
3. Preocupações de Segurança: Se um autenticador com chaves residentes for roubado, um atacante pode tentar extrair as chaves. Embora os autenticadores modernos tenham mecanismos de segurança robustos para prevenir a extração, por exemplo, o utilizador protege o dispositivo com um PIN, código de acesso ou gesto forte, o risco, embora mínimo, ainda existe.

Casos de Uso: Ideal para dispositivos onde o utilizador se autentica frequentemente, como smartphones ou portáteis pessoais.

Want to find out how many people use passkeys?

View Adoption Data

Definição:

As chaves não residentes, em contraste, não são armazenadas no autenticador. Em vez disso, o autenticador gera um novo par de chaves (baseado na sua chave mestra protegida internamente) e envia a chave pública deste novo par para o servidor (Relying Party) juntamente com o ID da credencial (que contém uma semente) durante o registo. O servidor então associa esta chave pública à conta do utilizador. Para autenticações subsequentes, o autenticador re-deriva a chave privada ao receber o ID da credencial, extraindo a semente e combinando-a com a chave mestra. Como a chave está apenas temporariamente disponível na memória protegida do autenticador, é por vezes chamada de chave efémera em linguagem criptográfica.

Fluxo de login:

Fonte: William Brown

Durante o processo de login, a Relying Party deve primeiro identificar qual o utilizador que está a solicitar a autenticação (por exemplo, pedindo um identificador de utilizador, como e-mail, número de telefone ou nome de utilizador) e depois envia os IDs de credencial que conhece para o utilizador solicitante ao cliente (navegador). O cliente encaminha-os para o autenticador (aqui: chave de segurança). O autenticador usa o ID da credencial juntamente com a chave mestra do autenticador para derivar a chave privada temporária, assina o desafio com a chave gerada e devolve-o ao cliente (aqui: navegador), que o encaminha para a Relying Party. As chaves não residentes foram originalmente usadas como segundo fator antes da introdução das passkeys. Portanto, identificar o utilizador primeiro fazia parte do processo de login regular.

Vantagens:

1. Escalabilidade: Como as chaves não residentes não residem no autenticador, os utilizadores podem ter um número quase ilimitado de chaves não residentes associadas a vários serviços. Isto é particularmente benéfico para utilizadores que têm contas em inúmeras plataformas.
2. Capacidade de Roaming: As chaves não residentes são ideais para autenticadores de roaming como chaves de segurança (por exemplo, YubiKey). Um utilizador pode usar a mesma chave de segurança (por exemplo, YubiKey) para se autenticar em múltiplos dispositivos e plataformas, proporcionando uma experiência consistente.
3. Dependência Reduzida do Armazenamento do Autenticador: Para configurações de servidor WebAuthn adequadas, não há necessidade de se preocupar com as limitações de armazenamento do autenticador. Isto pode ser particularmente vantajoso para autenticadores de baixo armazenamento, como chaves de segurança (por exemplo, YubiKeys).

Desvantagens:

1. Menos UX, pois o Identificador de Utilizador é Necessário: A maior desvantagem das chaves não residentes é que o identificador de utilizador (por exemplo, e-mail, número de telefone, nome de utilizador) precisa de ser fornecido pelo utilizador, o que torna impossível o preenchimento automático do nome de utilizador através da IU Condicional. Este identificador de utilizador precisa de estar ligado ao ID da credencial, que é necessário para calcular a chave embrulhada em chave efémera.
2. Potencial para Má Gestão: As RPs precisam de gerir e proteger as associações entre contas de utilizador e chaves públicas. Uma má gestão ou vulnerabilidades podem levar a problemas de segurança.

Casos de Uso: Ideal para autenticadores de roaming como chaves de segurança (por exemplo, YubiKeys) que são usadas em múltiplos serviços ou plataformas.

Imagine que tem uma chave de segurança (por exemplo, YubiKey) e a regista em dois serviços online: Serviço A e Serviço B. Para o Serviço A, usa uma chave residente. Para o Serviço B, uma chave não residente. Quando se autentica no Serviço A, basta tocar na sua chave de segurança (por exemplo, YubiKey) e está dentro - não precisa de especificar um nome de utilizador. Para o Serviço B, primeiro forneceria o seu nome de utilizador no navegador / aplicação nativa. O serviço envia então o ID da credencial associado para a sua chave de segurança (por exemplo, YubiKey), que então re-gera a chave privada efémera para autenticação.

Em essência, enquanto ambas as chaves residentes e não residentes aumentam a segurança ao alavancar a autenticação criptográfica, as suas experiências de utilizador e mecanismos de armazenamento diferem, atendendo a casos de uso variados.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

A IU Condicional é uma funcionalidade marcante das passkeys / WebAuthn. Alivia ainda mais o fardo do utilizador, pois este não só não precisa de se lembrar de uma palavra-passe, mas também não precisa de se lembrar do identificador de utilizador (por exemplo, e-mail, número de telefone, nome de utilizador) com o qual se registou numa Relying Party. Especialmente em casos onde os serviços das Relying Parties são usados apenas ocasionalmente, este é um passo enorme.

Isto funciona porque, assim que a página de login é aberta, o servidor da Relying Party envia um desafio em segundo plano para o cliente (lembre-se que não é necessário enviar um ID de credencial nesta chamada). O cliente pega neste desafio e verifica quais as passkeys que correspondem ao ID da Relying Party neste autenticador e oferece a seleção através do menu de preenchimento automático, onde o utilizador pode selecionar a passkey apropriada.

Além disso, também poupa ao utilizador um clique extra no botão de login, porque assim que a passkey é selecionada no menu de preenchimento automático, o processo de login começa.

O CTAP é um protocolo fundamental no padrão FIDO2, preenchendo a lacuna de comunicação entre clientes (como navegadores) e autenticadores (como chaves de segurança, por exemplo, YubiKeys, ou smartphones). Para entender melhor o CTAP, vamos dar uma primeira breve olhada nas diferentes versões do protocolo antes de analisar o impacto nas chaves residentes e não residentes.

A versão anterior, muitas vezes referida como Universal 2nd Factor (U2F), foi principalmente desenhada para autenticação de segundo fator. No U2F, o servidor fornece um desafio, e o autenticador fornece uma resposta, provando a posse da chave privada. No entanto, o U2F não suporta chaves residentes, o que significa que requer sempre uma pesquisa do lado do servidor para identificar qual a chave a usar para um utilizador, pois isto fazia parte do processo ao pedir um segundo fator.

O sucessor do U2F, o CTAP2, introduziu suporte para chaves residentes, permitindo autenticação sem palavra-passe e sem nome de utilizador. Com chaves residentes, o autenticador armazena o nome de utilizador e o ID da credencial do utilizador (juntamente com o ID da Relying Party), eliminando a necessidade de o servidor da Relying Party o fornecer durante a autenticação. Este é um salto significativo para uma UX mais fluida.

No entanto, o CTAP2 traz desafios. Um problema notável é a gestão de chaves residentes. Por exemplo, apagar uma chave residente específica num dispositivo CTAP2.0 muitas vezes requer um reset completo do dispositivo (o que significa que a sua chave mestra também é reiniciada, e todas as suas chaves não residentes deixarão de funcionar), o que não é amigável para o utilizador e pode ser problemático em cenários onde várias chaves residentes são armazenadas num único dispositivo. Isto torna as chaves residentes num dispositivo CTAP2.0 um compromisso sério. Não vai querer encher acidentalmente o espaço limitado que muitas vezes tem, especialmente em chaves de segurança (por exemplo, YubiKeys).

O CTAP2.1 é uma versão subsequente do CTAP2, trazendo funcionalidades e melhorias adicionais ao protocolo. Alguns pontos chave sobre o CTAP 2.1 incluem:

• Melhor Gestão de Chaves Residentes: O CTAP 2.1 permite gerir, atualizar e apagar individualmente chaves residentes específicas do seu dispositivo.
• Atestado Empresarial: Esta funcionalidade permite que as empresas tenham mais controlo sobre as chaves usadas pelos seus funcionários. Fornece uma forma para as empresas verificarem se as chaves a serem usadas são emitidas pela empresa.
• Reconhecimento de Múltiplos Utilizadores: Alguns autenticadores podem reconhecer múltiplos utilizadores. O CTAP 2.1 fornece uma forma para estes autenticadores indicarem qual o utilizador que foi reconhecido.
• Compatibilidade Retroativa: O CTAP 2.1 é desenhado para ser retrocompatível com o CTAP2, garantindo que dispositivos e plataformas que suportam a versão mais antiga ainda possam funcionar com a nova.

Depois de termos analisado as chaves residentes, as chaves não residentes e as diferentes versões do CTAP, analisamos agora o lado da Relying Party e, portanto, o lado do servidor WebAuthn com mais profundidade.

A flexibilidade (mas também a complexidade) do WebAuthn é largamente atribuída às suas configurações de servidor, particularmente dentro do objeto authenticatorSelection. Este objeto guia o cliente na seleção do autenticador certo para a tarefa.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Esta opção do servidor especifica como o autenticador está anexado ao dispositivo do cliente. Fornece informações sobre como o autenticador comunica com o cliente:

Valores Possíveis

• Platform: Indica que o autenticador está anexado à plataforma do cliente e, portanto, não é removível.
• Cross-platform: Indica que o autenticador não está vinculado à plataforma do cliente e pode ser usado em múltiplos dispositivos.

Casos de Uso e Exemplos

• Platform: Exemplos incluem um leitor de impressão digital que está integrado num portátil ou um sistema de reconhecimento facial num telemóvel, por exemplo, Face ID, Touch ID ou Windows Hello.
• Cross-platform: Exemplos incluem chaves de segurança USB (por exemplo, YubiKeys), dispositivos Bluetooth ou cartões NFC.

Na especificação WebAuthn Nível 1, esta opção do servidor chamava-se requireResidentKey e podia conter os valores Booleanos true (o autenticador deve criar uma chave residente) ou false (o autenticador deve criar uma chave não residente). O WebAuthn Nível 2 substituiu esta opção do servidor pela nova opção residentKey:

Valores Possíveis

• Required: O autenticador deve criar uma chave residente (se não for possível, a operação deve falhar).
• Preferred: O autenticador deve tentar criar uma chave residente (se não for possível, deve criar uma chave não residente).
• Discouraged: O autenticador deve criar uma chave não residente (se não for possível, a operação deve falhar).

Casos de Uso e Exemplos

• Required: Ideal para cenários onde se pretende um login sem nome de utilizador ou onde os utilizadores só devem autenticar-se a partir de dispositivos previamente registados (adicionando uma camada extra de segurança ao vincular a credencial do utilizador a um dispositivo específico).
• Preferred: Adequado para cenários onde o serviço web quer fornecer a melhor experiência de login possível (através de chaves residentes), mas ainda quer suportar chaves não residentes se as chaves residentes não forem possíveis.
• Discouraged: Um serviço quer oferecer autenticação com passkey e também quer garantir que os utilizadores podem usar qualquer autenticador, mesmo aqueles sem capacidades de armazenamento, sem vincular a credencial a um dispositivo específico.

A verificação do utilizador refere-se ao processo que garante que a pessoa a interagir com o autenticador é o proprietário legítimo, tipicamente exigindo um gesto de autenticação específico como inserir um PIN, fornecer uma impressão digital ou usar reconhecimento facial.

Por vezes, a presença do utilizador (UP) também é mencionada ou usada de forma semelhante à verificação do utilizador, mas existem algumas diferenças. A presença do utilizador apenas confirma que alguém - qualquer pessoa - está fisicamente presente e a interagir com o dispositivo. Não verifica a identidade dessa pessoa. Um simples toque numa chave de segurança, sem quaisquer outras verificações de identidade, pode ser suficiente para a presença do utilizador. Para passkeys / WebAuthn, o utilizador precisa sempre de estar presente.

Valores Possíveis

• Required: A operação deve ter verificação do utilizador.
• Preferred: A operação deve ter verificação do utilizador se possível, mas pode prosseguir sem ela.
• Discouraged: A operação não deve ter verificação do utilizador.

Casos de Uso e Exemplos

• Required: Ideal para aplicações de alta segurança como banca ou cuidados de saúde, onde verificar a identidade do utilizador (por exemplo, através de uma impressão digital ou PIN) é crucial.
• Preferred: Útil para aplicações gerais onde a segurança adicional é um bónus, mas não estritamente necessária.
• Discouraged: Adequado para operações de baixo risco ou cenários onde a verificação do utilizador pode ser um inconveniente.

Padrão

• Anexação do autenticador: platform
• Chave residente: required
• Verificação do utilizador: required

Exemplo: Uma aplicação corporativa quer que os funcionários façam login sem palavras-passe nos seus portáteis da empresa usando os leitores de impressão digital integrados. A credencial é armazenada no dispositivo e o utilizador deve verificar-se com uma impressão digital a cada vez.

Padrão

• Anexação do autenticador: cross-platform
• Chave residente: required
• Verificação do utilizador: required

Exemplo: Um utilizador regista uma chave de segurança (por exemplo, YubiKey) para a sua banca online. Pode usar esta chave para se autenticar em qualquer dispositivo, fornecendo a chave de segurança (por exemplo, YubiKey), sem precisar de inserir um nome de utilizador.

Muitas chaves de segurança baseadas em hardware (por exemplo, YubiKeys) têm restrições de armazenamento inerentes. Esta limitação deve-se à memória física disponível no dispositivo e às considerações de design do fabricante.

Exemplo: Uma YubiKey pode ter capacidade para armazenar apenas 20 chaves residentes. Uma vez atingido este limite, não podem ser adicionadas mais chaves residentes sem apagar as existentes.

Solução:

• Uso Seletivo de Chaves Residentes: Em vez de usar chaves residentes para todos os utilizadores, considere-as para funções ou cenários específicos. Por exemplo, priorize chaves residentes para funções de administrador ou utilizadores com privilégios elevados que requerem segurança reforçada.
• Educação do Utilizador: Informe os utilizadores sobre as limitações das suas chaves de segurança (por exemplo, YubiKeys). Incentive-os a mudar para dispositivos que podem usar chaves residentes ilimitadas, como portáteis ou smartphones.

Diferentes autenticadores podem lidar com pedidos de chaves residentes de forma diferente. Alguns podem assumir por defeito a criação de uma chave residente mesmo que não seja explicitamente solicitada, enquanto outros podem exigir instrução explícita.

O comportamento inconsistente para diferentes opções de servidor WebAuthn em diferentes plataformas é um grande problema. Por exemplo, o iOS criará sempre uma chave residente independentemente das opções do servidor WebAuthn passadas, enquanto o Android requer um opt-in (por exemplo, com residentKey: preferred ou residentKey: required).

Além do comportamento, é ainda pior que, com base nos dados armazenados do lado do servidor, não se pode dizer com 100% de certeza se uma credencial armazenada é uma chave residente ou não residente. Em vez disso, pode seguir algumas verificações e restringir as opções (veja abaixo), mas ainda precisa de esperar que o comportamento da credencial esteja de acordo com a sua crença.

A razão por trás disto é que existe uma sugestão do WebAuthn para armazenar informações sobre o tipo de credencial (chave residente ou não residente) na extensão de propriedades da credencial (clientExtensionResults.credProps.rk, que é verdadeiro ou falso). No entanto, fornecer esta informação à RP não é garantido, pois todas as extensões do WebAuthn são opcionais, por exemplo, o iOS não a envia (portanto, não sabe se é uma chave residente ou não residente).

Durante a nossa pesquisa, tentámos testar o comportamento em diferentes plataformas e autenticadores (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) com duas páginas de demonstração do WebAuthn que fornecem mais detalhes sobre as credenciais criadas: https://webauthn.io e https://webauthntest.identitystandards.io/. Esta última oferece a possibilidade de trabalhar com a propriedade legada requireResidentKey (WebAuthn Nível 1) e até combiná-la com a propriedade residentKey (WebAuthn Nível 2). No entanto, os resultados não foram fiáveis (por exemplo, indicava chave não residente para o iOS, mas a IU condicional funcionava claramente).

O esquema de verificação mais confiável que encontrámos é o seguinte:

1. Verifique quais são as configurações do seu servidor WebAuthn para o atributo "residentKey"
   1. Se "residentKey: required" e uma credencial for criada com sucesso -> é uma chave residente
   2. Se "residentKey: preferred" ou "residentKey: discouraged", então passe para a próxima verificação
2. A extensão credProps.rk é suportada e armazenada na credencial no servidor?
   1. Se credProps.rk = true, a credencial é uma chave residente
   2. Se credProps.rk = false, a credencial é uma chave não residente
   3. Se credProps estiver vazio, então o tipo de credencial é desconhecido

Como pode ver, isto ajuda a restringir, mas a opção desconhecida permanece e não se pode determinar o tipo de chave com 100% de certeza.

Isto também está em linha com as descobertas de William Brown da SUSE no seu ótimo artigo que descreve como as chaves de segurança (por exemplo, YubiKeys) podem tornar-se inúteis se as chaves residentes forem exigidas pelas Relying Parties (nós expandimos a sua tabela):

Na tabela, vê-se para diferentes opções de chave residente do servidor WebAuthn se uma chave residente foi criada (true), se uma chave não residente foi criada (false) ou se algo mais aconteceu.

Solução:

• Testes Exaustivos: Antes de implementar, teste a sua implementação WebAuthn numa gama de autenticadores populares para entender o seu comportamento.
• Configurações Explícitas do Servidor: Ao configurar o seu servidor WebAuthn, seja explícito nos seus requisitos. Se quiser ter apenas passkeys, defina a opção residentKey para required (nota: isto pode levar a outros desafios com autenticadores com capacidade limitada de chaves residentes, veja acima).

Se um utilizador atingir o limite de armazenamento na sua chave de segurança (por exemplo, YubiKey), pode enfrentar erros ou não conseguir registar novas credenciais. Isto pode levar a confusão e frustração.

Solução:

• Tratamento de Erros Gracioso: Implemente mensagens de erro claras que informem o utilizador quando a sua chave de segurança (por exemplo, YubiKey) estiver cheia e forneça orientação sobre como resolver o problema.
• Fluxos de Trabalho Guiados: Ofereça guias passo a passo ou tutoriais sobre como os utilizadores podem gerir as suas chaves residentes, garantindo que possam resolver problemas de forma independente.

9. Melhores Práticas para Desenvolvedores e Gestores de Produto

Como viu acima, as configurações do servidor WebAuthn que escolher podem impactar significativamente a experiência do utilizador e a segurança do seu processo de autenticação. É essencial entender as nuances destas configurações para tomar decisões informadas.

Chaves Residentes vs. Não Residentes: Se a maioria dos seus utilizadores acede principalmente ao seu serviço a partir de dispositivos pessoais como smartphones ou portáteis, as chaves residentes são uma escolha adequada. As chaves residentes são armazenadas no próprio dispositivo e oferecem uma experiência de autenticação fluida para utilizadores que usam frequentemente o mesmo dispositivo. No entanto, para utilizadores que usam chaves de segurança (por exemplo, YubiKeys), as chaves não residentes podem ser mais apropriadas.

Configurações de Verificação do Utilizador (UV): Dependendo do nível de segurança que deseja alcançar, pode decidir quão rigoroso o processo de verificação do utilizador deve ser. Se o seu objetivo é alta segurança, exigir um PIN, impressão digital ou reconhecimento facial (userVerification: preferred ou userVerification: required) é aconselhável.

Atestado e Confiabilidade: O Atestado permite verificar a origem e a integridade do autenticador. Decida se quer confiar em todos os autenticadores ou apenas naqueles de fabricantes específicos. Isto pode ser crucial se estiver a lidar com dados sensíveis e quiser garantir que apenas autenticadores de alta qualidade e confiáveis são usados.

Mecanismos de Fallback: Tenha sempre um mecanismo de fallback. Se um utilizador perder o seu autenticador ou se este avariar, deve ter uma forma alternativa de aceder à sua conta. Isto pode ser através de códigos de backup, verificação por SMS, links mágicos por e-mail ou outros métodos de autenticação multifator.

Educação Contínua: O cenário de passkeys e WebAuthn está em constante evolução. Mantenha-se atualizado com os últimos desenvolvimentos, vulnerabilidades e correções. Incentive a sua equipa de desenvolvimento a participar em workshops, webinars e conferências relacionadas com passkeys e WebAuthn.

Onboarding e Educação do Utilizador: Ao introduzir a autenticação com passkey, garanta que os seus utilizadores entendem os seus benefícios e como funciona. Ofereça instruções claras durante o processo de registo e forneça recursos (como FAQs ou tutoriais em vídeo) para ajudar os utilizadores a configurar e usar passkeys.

Ao aderir a estas melhores práticas, os desenvolvedores e gestores de produto podem garantir que implementam a autenticação com passkey de forma eficaz, equilibrando segurança e experiência do utilizador.

Se quiser implementar passkeys para adoção em massa no seu site ou aplicação e não precisar de suportar chaves de segurança (por exemplo, YubiKeys), pois a maioria dos seus utilizadores usará apenas o seu smartphone ou portátil, recomendamos as seguintes configurações.

• autenticador: platform
• residentKey: required
• userVerification: required

Benefícios:

• Como todas as chaves criadas são chaves residentes, a configuração permite a IU Condicional, tornando o seu login ainda mais fluido para os seus utilizadores, pois não precisam de se lembrar de um nome de utilizador.
• Todos os dispositivos modernos da Apple, Google e Microsoft são suportados e usam passkeys.

As configurações do servidor WebAuthn, apesar de complexas, oferecem uma estrutura robusta e flexível para a autenticação. Dominar estas configurações é crucial, pois não se trata apenas de implementar um novo padrão; trata-se de melhorar fundamentalmente a segurança e a eficiência da autenticação do utilizador.

Em essência, entender as configurações do servidor WebAuthn é um investimento na construção de aplicações mais seguras, eficientes e preparadas para o futuro. À medida que o cenário digital evolui, estar bem versado em tais tecnologias será indispensável. Para se manter atualizado, junte-se à nossa comunidade de passkeys ou subscreva a nossa newsletter abaixo.