Entrevista com o engenheiro sênior de certificação da FIDO Alliance em autenticação sem senha
Nossos usuários nos pediram para implementar a autenticação de dois fatores por meio do aplicativo do Google. E recentemente, demos a eles essa oportunidade. Na mesma época, o consórcio FIDO Alliance publicou padrões para autenticação sem senha em sites, aplicativos móveis e serviços da Web - WebAuthn e CTAP.
Ficamos interessados neste tópico e
preparamos material sobre Habré , no qual falamos sobre os métodos subjacentes aos novos protocolos.
Então, para esclarecer alguns pontos sobre os meandros do padrão, conversamos com Yuri Akkermann (
herrjemand ), engenheiro de certificação sênior da FIDO Alliance. Ele respondeu várias de nossas perguntas sobre a autenticação passada, presente e futura da FIDO. Apresentamos a sua atenção o texto da entrevista.
/ Flickr / zhrefch / PDConte-nos sobre sua experiência e experiência no campo de TI como um todo. Como você começou seu trabalho na indústria?
Faço programação desde os quinze anos. Depois da escola, fui para a universidade, onde estudei ciência da computação e matemática. No segundo ano, fiquei interessado em criptografia, questões de segurança da informação e "tropecei" na FIDO. Gostei muito dos protocolos e, no final, escrevi uma biblioteca U2F para o Python Flask e fiz uma apresentação.
Meu trabalho foi apreciado pela FIDO. Além disso, eles estavam apenas procurando um engenheiro de certificação. No final, eu me tornei responsável pela certificação técnica.
Há quanto tempo você lida com tópicos relacionados à autenticação com a FIDO? Que tarefas você resolveu no processo de desenvolvimento de um novo padrão?
Trabalho com protocolos da FIDO há três anos - dois deles na Aliança da FIDO. Meu principal papel é a certificação técnica e ferramentas automatizadas para testar implementações de acordo com as especificações. Minhas responsabilidades incluem o desenvolvimento e o suporte das próprias ferramentas, bem como a elaboração de planos de teste - listas de teste para verificação de servidores, clientes e autenticadores. Eu acho que escrever um plano de teste é o processo que consome mais tempo, pois requer uma compreensão de todos os meandros dos protocolos e dos padrões usados neles.
Também aconselho os grupos de trabalho sobre possíveis melhorias nas especificações, faço apresentações e escrevo artigos de tempos em tempos.
Como nasceu a idéia de criar um novo padrão para autenticação? Por que você decidiu que o mundo e a comunidade precisam de uma nova solução nessa área? Quais são as desvantagens dos formatos existentes que o WebAuthn pretende fechar?
A FIDO Alliance foi fundada em 2013 por Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal e Validity, que desenvolveram o UAF. Um pouco mais tarde, eles se juntaram ao Google, Yubico e NXP - eles trabalharam no antecessor do U2F e acharam que seria rentável unir forças, já que suas idéias coincidiam com as da Aliança. Eles procuraram proteger os usuários da Internet contra phishing, resolver os problemas de usabilidade das senhas e também desenvolver a acessibilidade e segurança das tecnologias biométricas.
Foram realizados estudos preliminares que fortaleceram a intenção de criar um padrão ou estimularam sua criação? Em caso afirmativo, que tipo de dados você analisou?
Membros da Aliança, como Google, Microsoft, Samsung, Yubico e outros, estão trabalhando ativamente para criar e promover padrões. Eles estão explorando mercados, tentando entender como a FIDO pode "se encaixar" em vários ecossistemas. O Google, por exemplo,
conduziu um estudo sobre a migração do segundo fator de senhas únicas para U2F.
Como nasceu o protocolo CTAP? Como está associado o WebAuthn?
O FIDO consiste em três partes: servidor, cliente (navegador) e autenticador. O servidor envia uma chamada para o cliente, o cliente passa a chamada para o autenticador, que a assina e a devolve ao cliente, e essa já foi enviada ao servidor.
Para que o servidor use a autenticação FIDO, os clientes têm uma API JS WebAuthn. O cliente se comunica com os autenticadores usando o protocolo de baixo nível CTAP2 (Protocolo de Cliente para Autenticador 2). O CTAP2 descreve estruturas e transportes de consulta CBOR, como USB, NFC e BLE, para comunicação com um autenticador. A combinação desses dois padrões é chamada FIDO2.
Um dos objetivos da criação do formato é proteger contra phishing. Quais são algumas das vantagens em comparação com outras soluções?
Se falamos sobre soluções existentes, a única coisa com a qual o FIDO pode ser comparado é certificados de cliente ou TLS CCA (Autenticação de Certificado de Cliente). O FIDO e o CCA são protocolos de resposta a chamadas com segurança contra phishing em chaves públicas. Mas eles têm diferenças significativas.
O CCA não está protegido contra um ataque de repetição. Eles reutilizam um único certificado em vários sites, o que pode levar à descriptografia do usuário. Na FIDO, geramos um novo par de chaves exclusivo para cada registro, a fim de manter a privacidade.
O CCA também tem um problema com o armazenamento de chaves, pois na maioria dos casos, a chave privada é criptografada no PKCS12 ou simplesmente fica livre. Assim, mesmo um aplicativo sem privilégios pode roubá-lo sem problemas. No FIDO, todas as chaves são mantidas seguras, por exemplo, no armazenamento unidirecional do SecureEnclave. Recuperar chaves desse tipo de armazenamento é muito difícil.
O CCA tem dificuldades com a implementação adequada no lado do servidor, pois o suporte completo ao CCA deixa muito a desejar. E devido às complexidades de trabalhar com TLS, os desenvolvedores cometem muitos erros. A FIDO só precisa de suporte para a criptografia básica em si. O CCA pode ser implementado através de HTTP, o que não pode ser feito no WebAuthn. O CCA também tem problemas com portabilidade e facilidade de uso.
Não acredito que a Aliança tenha inventado algo novo. Simplesmente desenvolvemos um bom protocolo que inclui mecanismos de segurança existentes.
/ Flickr / markus spiske / PDO uso do padrão não revelará vetores de ataque adicionais relacionados ao fato de que será necessário armazenar uma grande quantidade de informações biométricas?
Um de nossos princípios fundamentais é a privacidade. As informações biométricas são armazenadas em chips seguros e nunca as deixam. Nossas empresas trabalham com leitores certificados pela FIDO ou FIPS.
Também não usamos informações biométricas para nada além de confirmar a presença do usuário. E temos um programa de certificação biométrica para testar autenticadores.
Você disse uma vez que a autenticação por código SMS é uma opção 2FA ruim. Como você pode comentar sobre isso?
Os códigos SMS ou OTP do SMS são autenticação de dois fatores com senhas únicas entregues via SMS. Portanto, essa solução é vulnerável ao phishing. Se seu usuário for pego em phishing e fornecer seu nome de usuário e senha, o que o impedirá de transmitir um código SMS para criminosos cibernéticos?
Não devemos esquecer os problemas de usar o SMS como transporte. Há três anos, 400 mil contas foram invadidas em um banco alemão devido a uma vulnerabilidade no protocolo SS7, que é usado para rotear informações de telecomunicações entre diferentes operadoras de telecomunicações. Os atacantes que obtiveram acesso não autorizado à rede SS7, na qual não há autenticação, puderam registrar os números das próprias vítimas e obter seus códigos.
Além disso, hoje qualquer pessoa pode comprar uma estação base GSM por US $ 500-600 e interceptar o SMS usando-a usando um ataque MITM. E, finalmente, existem perigos associados à engenharia social. Penso que muitos
familiarizados com a história , quando os atacantes roubaram uma grande soma de dinheiro de contas bancárias através da emissão de um cartão SIM duplicado da vítima. Isso acontece na Rússia e em outros países com regularidade invejável.
E se você precisar entrar no serviço em vários dispositivos ou várias pessoas usarem o mesmo serviço de uma só vez? O padrão suporta este modo de operação?
Ao contrário de uma senha, pode haver muitos autenticadores. O usuário pode registrar seu telefone, laptop, token e usar qualquer um deles para autenticação. Além disso, um token pode ser "vinculado" a várias contas sem perda de privacidade.
Mas e se o token fosse perdido? Será possível retornar o acesso aos serviços?
A autenticação FIDO deve ser considerada como chaves domésticas. Se você perdeu as chaves, sempre pode pegar a reposição de sua esposa, filhos, mãe, avó ou, na pior das hipóteses, pegá-las debaixo do tapete da porta. Portanto, recomendamos que você sempre tenha um identificador sobressalente e armazene-o, por exemplo, em um cofre.
Se falamos em restaurar o acesso aos serviços, esse é realmente um problema difícil. A recuperação não faz parte do padrão, porque diferentes recursos restauram o acesso às contas de maneiras diferentes. As abordagens clássicas são códigos únicos que não são protegidos contra phishing. O Facebook permite recuperar o acesso através de amigos.
A solução mais promissora até o momento é o
Delegated Recovery - um protocolo de recuperação baseado no armazenamento de segredos criptografados em outros serviços. Aliás, foi escrito por um dos criadores do U2F Bratt Hill (Bratt Hill). A recuperação é um problema bastante difícil e interessante, cuja solução ainda precisa ser encontrada.
A chave privada no autenticador deve estar protegida contra cópia. De que forma e onde os identificadores são armazenados? Como eles são trocados?
Em cada registro, o autenticador gera um novo par de chaves exclusivo e atribui a ele um identificador aleatório chamado ID ou credID. As chaves privadas são armazenadas em armazenamento seguro, como SecureEnclave, TPM ou TEE.
A chave privada nunca sai do autenticador, pois isso não é necessário. Se o usuário deseja adicionar outro autenticador, ele simplesmente o registra, gerando um novo par de chaves e identificador e transfere a chave pública com o identificador para o site. Durante a autenticação, o site converte o identificador no autenticador, e o autenticador encontra o par de chaves com ele e assina a chamada.
Como o novo padrão se relaciona com os requisitos das leis de proteção de dados (por exemplo, GDPR)?
Nossos princípios são muito consistentes com o RGPD. Mesmo no modo de dois fatores, tornamos a autenticação de phishing segura. Se falarmos sobre autenticação sem senha, nenhuma senha será transmitida aqui. Além disso, diferentemente dos certificados de cliente, nosso protocolo não pode ser usado como super cookie. Portanto, muitas empresas já estão trabalhando na implementação de nossos protocolos.
E quem já está implementando o padrão?
Google, Facebook, Dropbox, Salesforce, Banco da América, NTT Docomo ... Temos centenas de empresas e meio bilhão de usuários diários. Estamos crescendo todos os dias. Ainda assim, a mudança para a autenticação completa sem senha levará algum tempo.
Com que rapidez o padrão permite a transição de outro método de autenticação?
Mudar de soluções de autenticação de dois fatores existentes (por exemplo, de OTP) para FIDO é bastante simples. Você só precisa conectar a biblioteca e implementar algumas alterações no lado do cliente. No FIDO2, a opção para autenticação sem senha é apenas um sinalizador adicional durante o registro. Transferir todo o ecossistema para autenticação completa sem senha levará algum tempo. Prevemos que em 10 anos essa transição completará 80% de todos os serviços.
Quais são os planos da FIDO para desenvolver o padrão? Que melhorias estão planejadas para serem feitas no futuro próximo? E a longo prazo?
Até agora, nos concentramos na promoção de padrões. Existem milhões de sites no mundo - isso significa que temos um milhão de coisas a fazer. A longo prazo, planejamos trabalhar na implementação de padrões para a Internet para aumentar a segurança dos gadgets de IoT. Os planos também incluem trabalho em sistemas de autenticação de estado, eIDs, passaportes e sistemas de identificação descentralizados.
Como você planeja continuar trabalhando no WebAuthn? Como a comunidade de TI pode ajudá-lo?
Como antes, continuo meu trabalho como embaixador na comunidade de desenvolvedores: publico artigos, trabalho em código aberto, faço apresentações e conduzo treinamentos. Quanto à ajuda da comunidade, só posso dizer: "Precisamos de mais ouro de código aberto".
PS Yuri Akkermann também preparou um artigo sobre Habré, no qual descreveu os principais mecanismos de segurança do FIDO2 e revisou a API JS para trabalhar com ele.