Esta página foi traduzida automaticamente. Leia a versão original em inglês aqui.

Relatório de Passkeys para bancos. Guias práticos, padrões de implementação e KPIs para programas de passkeys.
No nosso post anterior sobre chaves de acesso e PSD2, discutimos como as chaves de acesso já estão sendo usadas por fintechs como Revolut e Finom e como elas melhoram a segurança digital no setor bancário.
As chaves de acesso vêm em dois formatos principais: chaves de acesso sincronizadas e chaves de acesso vinculadas ao dispositivo. Enquanto as chaves de acesso sincronizadas permitem que os usuários se autentiquem de forma contínua em vários dispositivos, as chaves de acesso vinculadas ao dispositivo estão estritamente ligadas a um dispositivo de chave de acesso, como uma chave de segurança de hardware ou um autenticador local.
Com esta série de quatro artigos, queremos analisar detalhadamente como os diferentes tipos de chaves de acesso (vinculadas ao dispositivo vs. sincronizadas) cumprem os requisitos de SCA e PSD2.
Esta primeira parte da série visa entender a diferença entre chaves de acesso vinculadas ao dispositivo e sincronizadas.
A segunda parte explica o que significa a PSD2 e a Autenticação Forte de Clientes (SCA) de forma compreensível, expondo também o seu desenvolvimento histórico.
A terceira parte da série mostra como os diferentes tipos de chaves de acesso cumprem a SCA e o que isso significa para bancos, fintechs e instituições financeiras que pensam em adotar chaves de acesso.
A quarta e última parte da série conclui o que a PSD3 / PSR significará para a SCA e as chaves de acesso no futuro.
Artigos recentes
♟️
Chaves de acesso vinculadas ao dispositivo vs. sincronizadas (SCA e chaves de acesso I)
🔑
Fricção no login mata a conversão: 5 sintomas e soluções
♟️
Fallback e recuperação de chaves de acesso: Abordagem identifier-first
👤
Como habilitar chaves de acesso no macOS
♟️
Testando Implementações de Chaves de Acesso (Guia Empresarial 5)
Após a publicação do nosso último post, recebemos muitas perguntas de acompanhamento sobre a nossa posição em relação às chaves de acesso, especificamente em relação à SCA no âmbito da estrutura da PSD2. Existe um interesse claro em entender não apenas a aplicação das chaves de acesso, mas também como elas se alinham com as Normas Técnicas Regulamentares (RTS). Além disso, as partes interessadas estão curiosas sobre as possíveis interpretações e orientações de reguladores, incluindo a Autoridade Bancária Europeia (EBA), sobre o uso de chaves de acesso.
Reconhecendo isso, pretendemos aprofundar como as chaves de acesso podem ser integradas na diretiva PSD2, nas RTS sobre a SCA, e fornecer clareza sobre nossa posição em relação ao uso dessa tecnologia. Também exploraremos as perguntas e respostas existentes da EBA para esclarecer como os reguladores e a EBA podem perceber as chaves de acesso. Esta análise não apenas abordará as distinções entre chaves de acesso sincronizadas e vinculadas ao dispositivo, mas também suas aplicações práticas na melhoria da segurança e da experiência do usuário.
Igor Gjorgjioski
Head of Digital Channels & Platform Enablement, VicRoads
We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.
See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.
Read the case studyAo compreender as nuances, as partes interessadas podem tomar decisões informadas que não só cumprem os rigorosos requisitos da PSD2, mas também aproveitam a mais recente tecnologia de autenticação para proteger as transações digitais. A nossa discussão visa iluminar ainda mais o caminho para a integração de chaves de acesso nos processos de autenticação, garantindo que as medidas de segurança acompanhem o cenário digital em evolução.
Obviamente, toda entidade regulamentada que se enquadra na PSD2 precisa tomar suas próprias decisões sobre como cumprir as metas regulatórias, já que cada implementação tem suas próprias complexidades. Esta abordagem individual reconhece que, embora o quadro regulamentar forneça um padrão uniforme, a aplicação prática destas normas variará significativamente entre diferentes organizações devido aos seus ambientes operacionais, capacidades tecnológicas e bases de usuários únicos.
Assim, embora os nossos insights tenham como objetivo orientar e informar, não são prescritivos. Cada entidade deve considerar as suas circunstâncias e desafios específicos ao integrar chaves de acesso nos seus protocolos de segurança e autenticação.
Para entender a diferenciação entre chaves de acesso vinculadas ao dispositivo e sincronizadas, exploraremos brevemente como o ecossistema se desenvolveu.
Começamos olhando para a história e a evolução das chaves de acesso vinculadas ao dispositivo antes de examinar mais a fundo seus detalhes técnicos.
Historicamente, os mecanismos de autenticação do WebAuthn (o padrão subjacente às chaves de acesso) estavam fortemente acoplados a dispositivos físicos: chaves de segurança (por exemplo, YubiKeys). Antes da ampla adoção das chaves de acesso, as credenciais FIDO2 vinculadas a um único autenticador representavam o padrão-ouro em segurança. Estas credenciais estão ligadas ao dispositivo em que residem. A implicação desta vinculação foi significativa: a credencial não podia ser transferida ou utilizada fora do seu hardware original.
Esta abordagem, embora aumentasse a segurança ao localizar o processo de autenticação num único dispositivo, inevitavelmente encontrou limitações práticas que afetaram a sua ampla adoção, especialmente entre os consumidores gerais não técnicos. Os usuários eram forçados a ter o seu dispositivo de autenticação disponível para cada tentativa de login, o que não só limitava a mobilidade do usuário, como também levantava preocupações em cenários onde o dispositivo era perdido, danificado ou não estava imediatamente acessível.
Além disso, também havia relutância dos consumidores em investir em hardware adicional. Historicamente, a propriedade e a utilização de chaves de segurança dedicadas têm sido muito baixas entre os consumidores gerais. A perspectiva de comprar hardware especializado para fins de autenticação, apesar dos seus benefícios de segurança aprimorados, não teve boa aceitação pela maioria dos usuários B2C, que ao mesmo tempo são geralmente os alvos de amplas campanhas de phishing ou ataques de preenchimento de credenciais (credential stuffing).
Assine nosso Substack de passkeys para receber as últimas novidades.
As chaves de acesso vinculadas ao dispositivo caracterizam-se pela sua categorização específica em credenciais detectáveis e não detectáveis, uma distinção que define principalmente a sua capacidade de detecção. Mas o fator chave que distingue as chaves vinculadas ao dispositivo está encapsulado nas propriedades da credencial WebAuthn, particularmente através dos sinalizadores isBackupEligible e isBackupSynchronized. Para chaves de acesso vinculadas ao dispositivo, ambos os campos são definidos como zero, indicando que as credenciais não são elegíveis para backup ou sincronização entre dispositivos. Estas características sublinham a sua ligação intrínseca ao dispositivo físico onde foram criadas, garantindo que a credencial permanece ligada a esse hardware específico e utilizável apenas nele.
Um exemplo notável de credenciais vinculadas ao dispositivo na prática é observado no ecossistema Windows. As credenciais do Windows Hello no Windows 10 e Windows 11 permanecem vinculadas ao dispositivo — o próprio Windows Hello ainda não sincroniza as chaves de acesso entre dispositivos. No entanto, a Microsoft deu um primeiro passo significativo ao introduzir a funcionalidade de salvar e sincronizar chaves de acesso no Microsoft Edge (a partir do Edge 142). Essa sincronização no nível do navegador por meio do Microsoft Password Manager permite que as chaves de acesso sejam sincronizadas entre dispositivos Windows ao usar o Edge, de forma semelhante a como o Google Password Manager permite a sincronização de chaves de acesso no navegador Chrome no Windows. Isto representa um avanço importante nos recursos de chaves de acesso do Windows, embora seja específico para o navegador Edge, em vez do autenticador de plataforma Windows Hello. As chaves de acesso do Windows Hello permanecem vinculadas ao dispositivo, mas esta integração do Edge fornece um caminho prático em direção a chaves de acesso sincronizadas no Windows, enquanto o próprio autenticador da plataforma pode evoluir para oferecer suporte à sincronização no futuro.
Por outro lado, o Google articulou uma postura clara em relação a chaves de acesso não detectáveis, indicando que as chaves de acesso não detectáveis existentes poderão permanecer não sincronizadas em implementações futuras. Essa decisão alinha-se com o princípio mais amplo de que credenciais não detectáveis desempenham um papel crucial em determinados contextos de segurança, permanecendo estritamente vinculadas ao dispositivo e, por não serem detectáveis, não podem ser usadas como chaves de acesso.
Em contraste, a abordagem adotada pela Apple com o macOS e iOS difere significativamente. Ao contrário da estratégia fixa e vinculada ao dispositivo observada com o Windows e as chaves não detectáveis do Google, o ecossistema da Apple tem uma tendência muito mais forte de permitir apenas chaves de acesso sincronizadas, especialmente no iOS, tornando assim impossível criar uma chave de acesso vinculada ao dispositivo via WebAuthn.
Esta segmentação de estratégias nas principais plataformas ilustra as diversas abordagens à gestão de credenciais WebAuthn, especialmente ao considerar o equilíbrio entre segurança, conveniência e acessibilidade do usuário. Embora as chaves de acesso vinculadas ao dispositivo ofereçam um elevado nível de segurança ao garantir que as credenciais não possam ser movidas ou mal utilizadas fora do seu dispositivo pretendido, a indústria continua a evoluir, buscando soluções que mantenham os padrões de segurança sem comprometer a experiência e a mobilidade do usuário.
Aqui também, damos uma olhada no desenvolvimento histórico das chaves de acesso sincronizadas antes de analisar os detalhes técnicos. Às vezes, as chaves de acesso sincronizadas também são chamadas de chaves de acesso sincronizáveis.
Após a publicação das especificações WebAuthn Level 2 e CTAP 2.1 em meados do final de 2021, o grupo de trabalho WebAuthn lançou uma iniciativa significativa na indústria visando superar os principais obstáculos que impediam a capacidade do padrão WebAuthn de substituir senhas e aumentar a adoção. Esta iniciativa concentrou-se em duas áreas críticas: eliminar o requisito de dispositivos de segurança de hardware adicionais e mitigar o risco associado à perda do autenticador, mantendo ao mesmo tempo total compatibilidade com os padrões existentes.
O primeiro desafio — erradicar a necessidade de novo hardware — foi resolvido através da utilização de autenticadores de plataforma integrados encontrados em dispositivos de consumo modernos (por exemplo, Touch ID, Face ID, Windows Hello).
Os dispositivos modernos estão cada vez mais equipados com módulos de segurança especializados, como o Trusted Execution Environment (TEE) no Android, o Secure Enclave no iOS e macOS, e o Trusted Platform Module (TPM) nos dispositivos Windows. Estes repositórios de chaves de segurança essenciais servem como uma base sólida para as chaves de acesso, funcionando efetivamente como "chaves de segurança" integradas. Essa abordagem permite a adoção generalizada de criptografia de chave pública, um nível de segurança anteriormente alcançável apenas através de chaves de segurança de hardware externas (por exemplo, YubiKeys), e amplamente restrito a indivíduos com conhecimentos técnicos ou organizações de setores altamente regulamentados.
Ao aproveitar as capacidades do TEE, Secure Enclave ou TPM, os protocolos WebAuthn são capacitados para fornecer mecanismos de autenticação de usuários fortes e criptográficos. Agora, métodos sofisticados de autenticação tornam-se fáceis de usar e acessíveis ao público em geral, sem a necessidade de hardware especializado adicional.
Esta evolução é uma melhoria muito forte na abordagem à segurança digital, enfatizando o papel crítico que as soluções de segurança centradas no usuário desempenham na promoção de uma adoção generalizada. Organizações que combinam chaves de acesso sincronizadas com fluxos otimizados de criação e login de chaves de acesso observam as taxas de adoção mais altas. Ao usar recursos de segurança de dispositivos contemporâneos, o esforço da indústria resolveu com sucesso o obstáculo inicial de remover a necessidade de hardware externo.
Este desenvolvimento foi um passo crucial em uma nova era do ecossistema de autenticação digital, onde a ampla aplicação da criptografia de chave pública torna-se diretamente aplicável a uma ampla gama de casos de uso e, ao mesmo tempo, simplifica a autenticação para os usuários.
A fim de enfrentar o risco associado à perda do celular e, por extensão, das chaves de acesso nele armazenadas, a iniciativa do setor concentrou-se em permitir a sincronização de credenciais detectáveis na nuvem. Esta abordagem efetivamente transformou as credenciais, que deixaram de ser estritamente vinculadas ao dispositivo para se tornarem utilizáveis em vários dispositivos e, mais precisamente, vinculadas à conta do usuário no seu provedor de nuvem, como o iCloud para dispositivos Apple ou o Google para dispositivos Android.
Essa solução prática significou que mesmo que o telefone do usuário fosse perdido ou substituído, as credenciais estabelecidas anteriormente não seriam permanentemente perdidas. Em vez disso, essas credenciais poderiam ser recuperadas da conta de nuvem do usuário e sincronizadas com um novo dispositivo. Essa mudança reduziu significativamente os inconvenientes e os riscos de segurança anteriormente associados à perda de um autenticador físico.
Ao aproveitar a sincronização em nuvem, as chaves de acesso podem agora transitar de forma contínua entre os dispositivos de um usuário, mantendo a sua integridade e segurança independentemente do dispositivo específico em uso. Por exemplo, quando um usuário faz login em um site a partir de um novo dispositivo, as credenciais disponíveis em sua conta de nuvem podem ser sugeridas automaticamente para autenticação. Se necessário, essas credenciais podem ser transmitidas para o novo dispositivo, mantendo uma experiência de autenticação consistente e segura em diferentes plataformas e dispositivos.
Esta transição para credenciais vinculadas a contas e sincronizadas na nuvem representa uma abordagem pragmática da segurança digital. Ela reconhece a realidade do uso de dispositivos modernos e a ocorrência comum de trocas de dispositivos, seja por perda, dano ou atualização. Ao vincular credenciais à conta de nuvem do usuário – seja no iCloud da Apple ou nos serviços de nuvem do Google – a solução não apenas mitiga o risco associado à perda de um dispositivo, mas também melhora a capacidade do usuário de gerenciar e recuperar a sua identidade digital em vários dispositivos.
Este desenvolvimento amplia efetivamente a aplicabilidade dos mecanismos de autenticação forte e criptográfica do WebAuthn, tornando-os mais adaptáveis a cenários reais dos usuários. Também garante que uma autenticação forte seja acessível e gerenciável não apenas para aqueles com formação técnica ou para os que estão em setores altamente regulamentados, mas para o usuário comum navegando no mundo digital com vários dispositivos.
Por que as chaves de acesso são importantes?
Senhas e phishing colocam as empresas em risco. As chaves de acesso oferecem a única solução MFA que equilibra segurança e UX. Nosso whitepaper aborda a implementação e o impacto nos negócios.

As chaves de acesso sincronizadas também são conhecidas como credenciais detectáveis ou chaves residentes. Estas distinguem-se das chaves vinculadas ao dispositivo por duas propriedades críticas: isBackupEligible e isBackedUp possuem valores diferentes. Para chaves de acesso sincronizadas, o sinalizador isBackupEligible é definido como 1, indicando que essas credenciais são elegíveis para backup. Após a sincronização bem-sucedida para a nuvem, o sinalizador isBackedUp também é definido como 1, confirmando que a credencial foi devidamente sincronizada. É importante observar que o status da sincronização pode mudar com o tempo, refletindo a natureza dinâmica do uso e da gestão de dispositivos.
Quando as plataformas solicitam chaves residentes, definindo o parâmetro "requireResidentKey" como required ou preferred, as plataformas que suportam serviços de nuvem criam automaticamente chaves de acesso sincronizadas. Este processo garante que os usuários possam confiar que as suas credenciais estarão acessíveis em seus vários dispositivos. No Windows, as chaves de acesso sincronizadas estão agora disponíveis por meio do Microsoft Edge/Microsoft Password Manager (sincronização no nível do navegador), enquanto as credenciais do autenticador da plataforma Windows Hello permanecem vinculadas ao dispositivo. Gerenciadores de senhas de terceiros (por exemplo, Dashlane, KeePassXC, 1Password) com recursos de gestão de chaves de acesso também fornecem sincronização em várias plataformas. Em cenários em que chaves de acesso sincronizadas são usadas, os sinalizadores isBackupEligible e isBackedUp são definidos como 1, indicando elegibilidade para backup e sincronização bem-sucedida.
Além disso, embora atualmente ainda seja possível identificar o autenticador específico onde a chave de acesso foi armazenada, a ausência de atestado para a maioria destas credenciais significa que a sua origem não pode ser verificada criptograficamente. Este aspecto destaca uma possível limitação na garantia da linhagem de segurança de chaves de acesso sincronizadas unicamente por meio dos mecanismos padrão do WebAuthn.
Este desenvolvimento em chaves de acesso sincronizadas amplia essencialmente o escopo de credenciais detectáveis ao integrá-las num framework de sincronização baseada em nuvem. Ao tornar essas chaves elegíveis para backup e garantir a sua sincronização entre os dispositivos de um usuário, o WebAuthn aborda dois dos principais desafios na autenticação digital: o risco de perda de acesso devido à perda de dispositivos e o inconveniente de gerenciar múltiplas credenciais vinculadas ao dispositivo.
A transição de chaves de acesso vinculadas ao dispositivo para sincronizadas iniciou um diálogo crítico no grupo de trabalho WebAuthn, centrado na necessidade de medidas de segurança avançadas, nas questões legais envolvidas e em um compromisso que fosse fácil para o consumidor e seguro.
A adoção de chaves de acesso sincronizadas foi celebrada pela sua promessa de melhorar a conveniência e a segurança do usuário através de recursos como sincronização na nuvem e funcionalidade contínua em vários dispositivos. No entanto, introduziu algum desconforto entre algumas partes dependentes (RPs - Relying Parties), especialmente em relação às implicações para a segurança e conformidade em ambientes com requisitos elevados. A essência do debate foi a exigência de um mecanismo que garantisse que mesmo as chaves de acesso sincronizadas mantivessem uma conexão com dispositivos específicos, um conceito crucial para as partes dependentes que lidam com transações sensíveis ou operam sob padrões regulatórios rigorosos.
Para os RPs incapazes ou não dispostos a adotar chaves de acesso, a ausência de um método confiável para vincular estas credenciais a dispositivos específicos em aplicações críticas representava um desafio significativo. Um mecanismo assim foi considerado muito importante por alguns RPs. A falta dessa capacidade de vinculação ao dispositivo, uma expectativa que talvez não tenha sido declarada explicitamente, mas que certamente era esperada, representou uma surpresa séria e uma quebra de confiança da sua perspectiva.
A discussão concluiu que deveria haver uma harmonização de interesses, mas primeiramente o bem maior de disseminar as chaves de acesso deveria prevalecer. Na discussão, a extensão devicePubKey foi vista como uma forma de resolver essas preocupações, mas depois foi substituída por supplementalPubKeys que adotam uma abordagem muito mais ampla no rascunho atual do WebAuthn Level 3. Infelizmente, esta abordagem também foi descontinuada em agosto de 2024.
Vamos analisar como foi formado o compromisso com a extensão supplementalPubKeys e o que isso significa tecnicamente.
A discussão em torno da transição da extensão devicePubKey para a extensão supplementalPubKeys destaca a natureza dinâmica da especificação WebAuthn. Inicialmente, a devicePubKey serviu para aprimorar a segurança através de chaves públicas vinculadas ao dispositivo, mas mais tarde foi substituída pela sugestão da supplementalPubKeys no rascunho de trabalho do editor do WebAuthn Level 3. Esta extensão mais recente oferece uma solução mais abrangente, permitindo múltiplas chaves para aprimorar os processos de autenticação.
O cerne do debate centrou-se em equilibrar as medidas de segurança aprimoradas com a adoção mais ampla e a utilidade prática das chaves de acesso em diferentes dispositivos e plataformas. A extensão supplementalPubKeys representa uma combinação destas prioridades, permitindo uma autenticação mais rigorosa. Por exemplo, acomoda regulamentações que exigem determinados padrões de autenticação, permitindo "sub-chaves" adicionais com declarações de atestado. Estas chaves podem sinalizar a conformidade com os requisitos de autenticação, potencialmente reduzindo a necessidade de desafios de login adicionais sob certas condições (mesmo com chaves de acesso).
Um exemplo diretamente do rascunho do WebAuthn:
“Digamos que um pedido de login aparece num site com algum sinal de geolocalização que não foi visto antes para a conta deste usuário, e está fora das horas normais de utilização observadas para a conta. O risco pode ser considerado elevado o suficiente para não permitir o pedido, mesmo com uma afirmação por uma credencial multi-dispositivo por si só. Mas se uma assinatura de uma chave suplementar que é vinculada ao dispositivo, e que está bem estabelecida para este usuário também pode ser apresentada, então isso pode inclinar a balança.”
Durante a discussão, foi sublinhado que estas destinavam-se apenas a RPs com requisitos de segurança extremamente altos (por exemplo, no contexto do setor público).
Ao incorporar feedback e resolver casos de uso específicos — incluindo também transações financeiras regulamentadas e a necessidade de sinais vinculados ao dispositivo num ambiente de credenciais para vários dispositivos — a comunidade WebAuthn visava resolver preocupações tanto de segurança como de interoperabilidade. A extensão supplementalPubKeys é, portanto, uma abordagem que procura fornecer recursos robustos de segurança ao mesmo tempo em que oferece suporte a uma experiência de usuário perfeita e ampla compatibilidade essencial para a adoção generalizada das chaves de acesso. Trata-se de uma extensão completamente opcional que não interfere na implementação das chaves de acesso observada nos últimos 2 anos.
Esta evolução em direção a uma estrutura mais inclusiva e flexível sublinha o compromisso da comunidade WebAuthn em melhorar os métodos de autenticação na web mesmo em casos de uso mais rigorosos.
A extensão supplementalPubKeys introduzida no WebAuthn permite a utilização de pares de chaves adicionais ao lado da credencial primária.
Tirado do issue original do GitHub
A imagem mostra o conceito de supplementalPubKey tirado do issue original do GitHub (pk = passkey, pspk=provider supplemental key, dspk = device supplemental key).
Aqui está um resumo de como funciona e do seu uso pretendido:
Propósito e funcionalidade da supplementalPubKey
Casos de uso e exemplos de supplementalPubKey
Aspectos técnicos da supplementalPubKey
É crucial notar que, até abril de 2024, a extensão supplementalPubKeys não havia sido adotada por nenhum navegador importante, e a especificação do WebAuthn Level 3 ainda estava em desenvolvimento e sujeita a alterações. Se este recurso seria incluído na versão final da especificação, e a sua possível implementação e adoção futura, permaneciam incertos, visto que na época encontrava-se apenas no rascunho do editor (Editor’s Draft).
Em agosto de 2024, a extensão supplementalPubKeys foi oficialmente descontinuada. O grupo de trabalho WebAuthn decidiu remover esta funcionalidade devido a suporte insuficiente. A descontinuação desta extensão também destaca uma nova direção. Atualmente, a FIDO Alliance está trabalhando no desenvolvimento de uma abordagem diferente para apoiar Partes Dependentes com altos requisitos de segurança. Espera-se que esta solução futura aborde as lacunas deixadas pela descontinuação de supplementalPubKeys e ofereça novos métodos para fortalecer os processos de autenticação em cenários onde normas rigorosas de segurança são essenciais.
Para mais detalhes sobre a descontinuação, veja a publicação oficial WebAuthn GitHub pull request.
Compreender as diferenças entre as chaves de acesso vinculadas ao dispositivo e sincronizadas é essencial, mas os bancos também precisam de ferramentas para operacionalizar essas diferenças em escala. A plataforma da Corbado fornece inteligência de confiança do dispositivo que classifica automaticamente os tipos de chaves de acesso e aplica o tratamento de SCA adequado a cada um.
O painel de controle (dashboard) de Device Trust da Corbado mostra como as chaves de acesso vinculadas ao dispositivo e as sincronizadas têm desempenhos diferentes na produção. As chaves vinculadas ao dispositivo alcançam taxas de sucesso mais elevadas (99,1%) com zero requisitos de etapa adicional (step-up), enquanto as chaves de acesso sincronizadas com sinais de confiança do dispositivo alcançam 98,4% com uma pequena taxa de verificação adicional para novos dispositivos.
O painel de controle também rastreia a classificação do dispositivo — identificando quais dispositivos são exclusivos a um único usuário (92% em implementações típicas do setor bancário), quais são compartilhados entre dois usuários (7%) e quais são dispositivos compartilhados/quiosque (0,8%). Essa classificação alimenta diretamente as decisões de conformidade de SCA.
Em vez de tratar todas as chaves de acesso da mesma forma, as políticas de confiança da Corbado permitem que os bancos apliquem diferentes regras baseadas no tipo de chave de acesso, status do dispositivo e nível de confiança. Chaves de acesso vinculadas a dispositivos conhecidos obtêm autenticação sem atrito, enquanto chaves de acesso sincronizadas em novos dispositivos acionam verificação adicional — exatamente o tipo de abordagem com nuances que a estrutura de SCA da PSD2 exige.
Isto significa que os bancos podem implementar com confiança chaves de acesso sincronizadas para uma melhor experiência do usuário, mantendo ao mesmo tempo o controle rígido de dispositivos que as chaves de acesso vinculadas ao dispositivo proporcionam para cenários de alta segurança — tudo gerido através da configuração de políticas, em vez de fluxos de autenticação separados.
Posição da Corbado sobre a PSD2/SCA e Chaves de acesso: As chaves de acesso (tanto vinculadas ao dispositivo como sincronizadas) podem ser compatíveis com a SCA. Cada instituição deve ser a dona da sua avaliação de risco de SCA, mas a evidência é clara: as chaves de acesso fornecem inerentemente dois fatores de SCA - posse (chave privada em módulo de segurança de hardware ou chaveiro na nuvem) + inerência (biométrica) ou conhecimento (PIN). O debate sobre a "posse" tem nuances, mas é solúvel - a indústria está caminhando para três abordagens: (1) Chaves de acesso como são (por exemplo, Revolut, Finom) - inerência + posse por meio do dispositivo com a chave privada, (2) Chaves de acesso + vinculação de cookies/sessão (por exemplo, PayPal, Comdirect) - sinal de posse extra para interpretação conservadora, (3) Vinculação criptográfica (DBSC/DPoP) - prova de posse vinculada a hardware, garantia mais forte. Ainda não existe uma única interpretação "correta". Uma abordagem baseada nos resultados em relação à SCA é necessária - concentrando-se na resistência ao phishing demonstrável em vez de na categorização rígida de fatores. A vinculação dinâmica (Dynamic linking) permanece um requisito separado para pagamentos mesmo com chaves de acesso.
Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →
As chaves de acesso vinculadas ao dispositivo são credenciais WebAuthn estritamente ligadas ao dispositivo onde foram criadas. Ao contrário das chaves de acesso sincronizadas, elas permanecem em um único dispositivo, tornando-as inerentemente mais seguras para determinados casos de uso:
A principal desvantagem é a portabilidade limitada. Se o dispositivo for perdido, a chave de acesso não pode ser recuperada a menos que o usuário registre uma nova em outro dispositivo.
As chaves de acesso sincronizadas (chaves de acesso de vários dispositivos) foram introduzidas para resolver os desafios de usabilidade das chaves de acesso vinculadas ao dispositivo, particularmente a falta de portabilidade e o possível bloqueio da conta em caso de perda do dispositivo. Os principais benefícios incluem:
Na primeira parte da nossa série de 4 partes, analisamos quais são as diferenças históricas e técnicas das chaves de acesso vinculadas ao dispositivo e sincronizadas. Compreender essas diferenças nos ajudará a aplicar os requisitos de PSD2 e SCA de acordo. Além disso, analisamos o que o futuro pode nos trazer ao dar uma olhada nas mudanças mais recentes do padrão WebAuthn Level 3 que ainda está em evolução.
Aqui estão os links para as outras partes da nossa série:
Próximo passo: pronto para implementar passkeys no seu banco? Nosso relatório de +90 páginas sobre passkeys para bancos está disponível.
Obter o relatório
Artigos relacionados
Índice