WebAuthn na vida real

Em setembro de 2019, a equipe do Mail.ru Mail deu suporte à tecnologia WebAuthn. Nós nos tornamos o primeiro serviço de e-mail do mundo que implementava a capacidade de fazer login na sua conta usando chaves eletrônicas em vez de senhas. Agora, esta oportunidade está disponível para todos os nossos usuários. Você pode vincular a chave eletrônica à sua conta nas configurações e depois usá-la livremente para entrar.



Nós já escreveu notícias sobre este evento aqui, no Habré. Neste artigo, quero falar mais sobre os motivos da implementação do WebAuthn em nossos serviços e sobre os aspectos técnicos do trabalho com essa tecnologia.

O que é o WebAuthn e por que é necessário


No mundo moderno, a maioria dos serviços de Internet usa senhas para autenticar usuários. A vantagem das senhas é a sua simplicidade: para acessar o recurso necessário, basta conhecer a senha e inseri-la corretamente.

No entanto, as desvantagens das senhas geralmente superam suas vantagens:

  • se a senha é simples - você pode buscá-la;
  • se a mesma senha é usada em vários serviços, ao quebrar um deles, o invasor obtém acesso a todos os outros;
  • senhas são vulneráveis ​​a ataques de phishing;
  • senhas fortes e exclusivas são difíceis de lembrar, portanto o usuário é forçado a anotar a senha no adesivo e colá-la no monitor, onde pode ser facilmente espionada, roubada ou perdida.

Para se livrar das deficiências das senhas e tornar o processo de autenticação mais seguro, são exibidas várias maneiras de substituir as senhas - esse é o uso de códigos únicos enviados ao usuário via SMS ou através de notificações PUSH, ou o uso de aplicativos geradores de código TOTP especiais nos quais o usuário pode efetuar login conta sem inserir sua senha.

Empresas como Microsoft , Yahoo e Amazon pensam em usar métodos de autenticação sem senha e abandonam completamente o uso de senhas em seus serviços. Mail.ru mail não é excepção, há muito tempo que suportamos o login usando códigos únicos, o que permite que os usuários não se lembrem de senhas complexas e fortes e obtenham acesso rápido a suas contas.

Outra alternativa às senhas é a autenticação usando chaves eletrônicas (chaves de segurança, outro nome - autenticadores eletrônicos). O princípio de sua operação é baseado no uso de criptografia assimétrica e é descrito na família de protocolos FIDO2, desenvolvida pela aliança FIDO (Fast IDentity Online).

Em março de 2019, o W3C lançou a primeira versão do padrão., que descreve uma API JS baseada em navegador que permite interagir com chaves eletrônicas. O padrão recebeu o status de recomendação e o nome Autenticação da Web: API para acessar credenciais usando uma chave pública: nível um (Autenticação da Web: uma API para acessar credenciais de chave pública Nível 1) - abreviado, WebAuthn.

Como o WebAuthn funciona


Os seguintes principais atores no processo de autenticação usando o WebAuthn são identificados:

  • Cliente (WebAuthn Client) - um navegador que suporta a API WebAuthn;
  • Aplicativo da Web - um aplicativo em execução no cliente usando a API WebAuthn para interagir com credenciais;
  • credenciais (credencial de chave pública) - um par de chaves criptográficas públicas e privadas associadas a uma conta de usuário;
  • O autenticador - um dispositivo ou programa - cria credenciais do usuário e assina solicitações da terceira parte confiável com essas credenciais (outro nome é uma chave eletrônica);
  • a terceira parte confiável (WebAuthn Relying Party) - o servidor da Web - armazena a chave pública associada à conta do usuário, verifica a validade da assinatura de suas solicitações com a chave privada armazenada no autenticador.

A API WebAuthn permite executar apenas duas operações. Permite criar novas credenciais e assinar solicitações do servidor com credenciais já criadas.

Criação de credenciais ( MakeCredential )



Esquema do estágio com a criação de credenciais, retirado do w3.org .

Nesta fase, a chave eletrônica é registrada na conta do usuário. Dentro do autenticador, um novo par de chaves públicas e privadas é gerado e a chave pública é enviada e armazenada na conta de usuário no servidor.

const credential = await navigator.credentials.create({
    publicKey: publicKeyMakeCredentialOptions
});

Assinando uma solicitação com credenciais já criadas ( GetAssertion )



Esquema do estágio com verificação de credenciais, retirado de w3.org .

Nesta etapa, é verificado se o usuário possui um autenticador cuja chave pública está armazenada na conta do usuário. Um token aleatório é assinado com a chave privada dentro do autenticador e enviado ao servidor, onde o servidor verifica se a assinatura está correta. Portanto, se a assinatura estiver correta, concluímos que o usuário realmente possui esse autenticador.

const assertion = await navigator.credentials.get({
    publicKey: publicKeyGetAssertionOptions
});

Você pode ver uma demonstração do processo de entrada no Mail.ru Mail usando o WebAuthn neste vídeo .

Você pode aprender mais sobre a própria API WebAuthn na especificação WebAuthn e, por exemplo, neste artigo Médio .

Portanto, o trabalho do WebAuthn é baseado no uso de chaves eletrônicas. O que é isso?

Chaves eletrônicas


As chaves eletrônicas (às vezes as chamarei também de "chaves WebAuthn", chave de segurança e segurança) são dispositivos ou programas que implementam protocolos de interação FIDO2.

Na especificação WebAuthn e no nível doméstico, todas as chaves eletrônicas são classificadas em uma de duas categorias:

  • chaves independentes de plataforma (autenticadores em roaming);
  • Autenticadores de plataforma

Chaves independentes de plataforma são dispositivos físicos externos, como Yubikey da Yubico ou Titan Security Key do Google. Normalmente, esses autenticadores são conectados ao computador ou smartphone do usuário via USB, NFC ou BLE. A comunicação com esses dispositivos ocorre usando o protocolo CTAP especial (Protocolo Client to Authenticator).

Para começar a trabalhar com chaves eletrônicas físicas, o usuário precisa vinculá-lo uma vez à sua conta. Depois disso, o usuário tem a oportunidade de usar essa chave eletrônica para entrar em qualquer outro dispositivo e em qualquer navegador.


Exemplos de várias chaves independentes de plataforma, extraídas de theverge.com .

Se o mecanismo de operação do primeiro tipo de chave é mais ou menos claro, quero me aprofundar na segunda categoria.

No segundo caso, chaves criptográficas públicas e privadas são geradas e armazenadas não dentro de um dispositivo físico externo, mas com algum módulo de software dentro de um computador ou smartphone. Este módulo de software pode ser implementado no nível de aplicativo específico ou no nível do sistema operacional. Por exemplo, em um chip seguro dentro de um computador, ao qual seu sistema operacional só dará acesso se você estiver conectado e tiver provado que você é realmente você.

Nas implementações mais modernas em diferentes navegadores, o sistema operacional exige que o usuário se confirme com uma impressão digital ou digitando a senha da conta do usuário. É importante esclarecer que, embora o usuário precise colocar o dedo no scanner de impressão digital para usar essas teclas, a impressão digital em si não é armazenada em nenhum lugar e não é transmitida em nenhum lugar. É exatamente dessa maneira que o sistema operacional ou o navegador valida o usuário.


Uso de autenticadores específicos da plataforma.

Somente as informações da chave pública codificada ou um token aleatório assinado são retornadas ao serviço da Web a partir da API WebAuthn, que é então armazenada e verificada no servidor.

Portanto, no caso do autenticador interno, será possível usá-lo apenas no navegador e no dispositivo em que foi anexado à conta. Em outras palavras, as chaves dependentes da plataforma precisarão ser registradas separadamente em cada dispositivo / navegador no qual você pretende fazer login na sua conta.

No futuro, são esperadas mais maneiras que permitirão ao usuário ativar o uso de autenticadores específicos da plataforma, por exemplo, usando uma varredura de rosto ou inserindo um código PIN do dispositivo.

Ao criar credenciais ou calcular a assinatura, você pode especificar o tipo preferido de autenticador em um parâmetro especial que aceita dois valores - cross-platforme platform. Nesse caso, o usuário será solicitado a usar apenas um dos tipos de chaves eletrônicas.

const credential = await navigator.credentials.create({
    publicKey: {
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform',
        },
        ...,
    },
});

Benefícios do WebAuthn


Quais são os benefícios da tecnologia WebAuthn para usuários e desenvolvedores?

  • O usuário não precisa se lembrar e inserir nenhuma senha, e o servidor não armazena senhas de usuário, respectivamente, todas as deficiências que as senhas tinham desaparecido. Roubar um autenticador físico de um usuário é muito mais difícil do que interceptar uma senha transmitida eletronicamente por uma conexão insegura, e um vazamento de chaves públicas no site não abrirá a chave privada oculta no dispositivo.
  • origin , . origin . , (thesslstore.com, yubico.com) .
  • WebAuthn - . - web- , .
  • O próprio WebAuthn como uma API fornece aos desenvolvedores uma abstração sobre a implementação de autenticadores e permite escrever um código uma vez, que funcionará com todos os tipos e tipos de chaves eletrônicas. Assim, o WebAuthn é uma solução escalável para autenticação do usuário.

Ainda mais sobre por que o WebAuthn é mais seguro que uma senha - WebAuthn para desenvolvedores: 5 etapas para uma melhor autenticação , Introdução às chaves de segurança .

Suporte WebAuthn


Se a autenticação dongle funciona ou não no seu dispositivo depende de vários fatores diferentes. Começando se o seu navegador suporta a API WebAuthn e terminando com quais conectores estão no seu computador e quais métodos de comunicação o seu autenticador suporta. O desempenho do WebAuthn também depende muito de qual dispositivo e SO você usa.

No momento da redação deste artigo, de acordo com caniuse.com, a API WebAuthn é suportada por 80,5% dos usuários. Segundo as estatísticas dos usuários do Mail.ru, esse número tem a mesma ordem - 79,8%. No entanto, para usar o WebAuthn em todos esses navegadores, você definitivamente precisará de uma chave eletrônica externa.

Nem todos os navegadores que suportam a API WebAuthn podem trabalhar com chaves dependentes da plataforma (por conveniência, vou me referir a essas chaves como "Impressões digitais" posteriormente). Além disso, para trabalhar com essas chaves, não é suficiente instalar um navegador que possa funcionar com elas. Também é necessário que seu dispositivo e sistema operacional tenham um módulo / sensor apropriado e possam interagir com ele. De todos os usuários do Mail.ru, apenas 9,0% têm a capacidade de adicionar chaves específicas da plataforma.

Vou falar brevemente sobre o suporte do WebAuthn por diferentes sistemas operacionais e navegadores.

janelas


O suporte WebAuthn no Windows é muito bom. O subsistema de autenticação do Windows Hello pode funcionar com chaves eletrônicas. Portanto, todas as versões mais recentes do navegador para este sistema operacional - Microsoft Edge, Google Chrome, Opera e Mozilla Firefox - suportam o trabalho com chaves estrangeiras e impressões digitais. O WebAuthn da API do Internet Explorer não oferece suporte.


Linux


Os autenticadores externos geralmente são suportados por quaisquer distribuições modernas de Linux, bem como navegadores como Google Chrome, Chromium e Mozilla Firefox. No entanto, em alguns sistemas, configurações adicionais podem ser necessárias para trabalhar com chaves estrangeiras .

Android


O suporte WebAuthn no Android também é bom. Google Chrome, Opera e Mozilla Firefox - suporte para trabalhar com chaves estrangeiras e impressões digitais. Mas o Microsoft Edge para Android não suporta a API WebAuthn. Há também um erro no Firefox - especificar o tipo preferido de autenticador usando a opção não funciona para ele authenticatorAttachment.


iOS


Entre todos os navegadores do sistema operacional iOS, o WebAuthn suporta apenas a versão móvel Safari 13.3. Além disso, ele só pode trabalhar com chaves eletrônicas externas. Outros navegadores para iOS ainda não oferecem suporte ao WebAuthn.

Mac OS


O Microsoft Edge, Google Chrome, Opera e Mozilla Firefox suportam o trabalho com chaves estrangeiras no macOS. O Google Chrome também suporta impressões digitais, permitindo que você use o WebAuthn com o Touch ID.


Se no Edge, Opera e Chrome a interface para interagir com o WebAuthn é a mesma, o Firefox se destacou aqui. Em vez de um pop-up bonito no Firefox, ao usar o WebAuthn, uma pequena notificação aparece no canto da tela. Se você clicar acidentalmente em uma página, ela simplesmente entra em colapso, deixando o usuário sem saber o que está acontecendo agora.



No entanto, o Safari ainda não oferece suporte ao WebAuthn. O suporte do WebAuthn foi anunciado no Safari 13, que estará disponível no macOS 10.15 Catalina. No entanto, no momento em que escrevi, minhas verificações mostraram que a API WebAuthn no Safari, embora presente, é extremamente instável e não funciona com todos os autenticadores. Como sua versão móvel, o Safari não funciona com chaves eletrônicas integradas. Além disso, ele ainda não suporta nenhuma das chaves eletrônicas estrangeiras.

Portanto, percebemos que, além de suportar problemas, o WebAuthn tem diferenças ainda maiores na interface do usuário. Essas diferenças levam ao fato de que você precisa explicar mais detalhadamente ao usuário o que é necessário dele para usar a entrada por meio de chaves eletrônicas. Além disso, a cada nova versão do navegador, esses pop-ups podem mudar, e o processo de uso do WebAuthn hoje pode ser muito diferente do que era ontem.

Está claro por que isso está acontecendo. A tecnologia WebAuthn ainda é bastante jovem e os desenvolvedores de navegadores ainda estão experimentando diferentes tipos de implementação. Só podemos esperar que, com o tempo, o suporte ao WebAuthn nos navegadores se estabilize e que possamos usá-lo sem restrições.

Registro do autenticador


Se dermos ao usuário a oportunidade de registrar diferentes chaves eletrônicas em sua conta, ele deverá ter a oportunidade de visualizar sua lista e remover outras obsoletas ou desnecessárias. Isso pode ser útil, por exemplo, no caso de comprometimento de uma das chaves.

A API WebAuthn foi projetada para que, ao criar e usar credenciais, o cliente não esteja disponível com informações sobre o tipo, tipo e nome dos autenticadores usados. Consequentemente, não temos dados pelos quais possamos distinguir uma chave da outra. Todas as chaves na lista serão apresentadas igualmente, sem características distintivas. Pergunta: o que fazer?


Você pode obter algumas informações sobre o autenticador usado se solicitar as chamadas credenciais ao criar credenciais. certificação. A certificação é uma maneira de um autenticador provar sua autenticidade em um servidor. Em alguns casos, informações sobre o fabricante principal podem ser obtidas na certificação. Mas, no caso geral, os dados utilizados ainda não são suficientes para distinguir claramente uma chave eletrônica associada a uma conta de outra.

const credential = await navigator.credentials.create({
    publicKey: {
        attestation: 'direct',
         ...,
    },
});

Portanto, depois de conectar a chave à conta no Mail, oferecemos ao usuário a oportunidade de atribuir um nome ao registro recém-criado. E ainda mais, o usuário pode distinguir uma chave da outra por esse nome.

O fato de as informações disponíveis para o cliente e o servidor não conterem dados sobre o tipo de autenticador leva a outro recurso desagradável do WebAuthn.

Imagine um usuário que adicionou apenas uma impressão digital à sua conta, por exemplo, em seu smartphone. Quando queremos fazer login usando a API WebAuthn, passamos uma chamada de funçãonavigator.credentials.getlista de todas as chaves associadas a uma conta. Mas o navegador não pode determinar nessa lista quais autenticadores estão presentes no dispositivo e quais não estão. Portanto, ele é forçado a sempre oferecer ao usuário o uso do WebAuthn.

Portanto, mesmo ao tentar fazer login em uma conta em um computador que não oferece suporte à autenticação por impressões digitais, o usuário ainda poderá usar o WebAuthn.

Para implementar o comportamento correto nessas situações, é necessário refinar o próprio padrão WebAuthn. Por exemplo, para codificar informações sobre se uma chave ou impressão digital de plataforma cruzada foi usada para criá-la e não oferecer ao usuário WebAuthn nos casos em que se sabe com antecedência que ele não poderá usá-la.

Existem maneiras de contornar esse comportamento em algumas situações. Por exemplo, permita ao usuário registrar impressões digitais e chaves físicas apenas individualmente. E ao usar as chaves, filtre as impressões digitais em dispositivos que obviamente não são compatíveis. Mas esse método não resolve o problema completamente. E não há uma maneira confiável de resolver esse problema.

Nossos usuários ainda não receberam reclamações sobre esse comportamento. Por isso, estamos investigando esse recurso e decidindo o que fazer no futuro.

O WebAuthn trabalha em diferentes subdomínios


Como eu disse anteriormente, o WebAuthn fornece proteção imediata contra phishing. Ao registrar chaves eletrônicas, as informações são armazenadas originnas quais essa chave foi registrada. O WebAuthn não permite o uso dessa chave eletrônica em recursos, com outra origin.

Grandes serviços web, como o Mail.ru, costumam usar vários domínios diferentes para o seu trabalho. Por exemplo, temos um domínio e.mail.rupara o Mail e cloud.mail.rupara a nuvem. E em cada um deles temos uma forma comum de autorização. Nesse caso, as configurações padrão do WebAuthn não são suficientes. Para que possamos usar originchaves registradas na outra em um origin, é necessário que esses dois domínios tenham um sufixo comum (um subdomínio comum com mais do que o primeiro nível).

Por exemplo, em domíniose.mail.rue o cloud.mail.rusufixo comum é mail.ru.

Nesse caso, ao registrar e usar chaves eletrônicas, podemos especificar um parâmetro rpIdigual nas opções de solicitação mail.rue, em seguida, podemos usar a mesma chave na própria subchave https://mail.rue em qualquer um de seus subdomínios.

const credential = await navigator.credentials.create({
    publicKey: {
        rp: {
            name: 'Mail.ru Group',
            id: 'mail.ru',
        },
        ...,
    },
});

O WebAuthn funciona em iframe


Por motivos de segurança, as chamadas para métodos WebAuthn são proibidas a partir de iframes de origem cruzada. Nossos projetos usam um único formulário de autorização, localizado em https://account.mail.ru/login e, quando queremos mostrar o formulário de autorização em qualquer outro projeto, por exemplo, no Mail ou na nuvem, se o iframe é realmente adicionado à página dentro do qual esse URL é aberto. Essa solução nos permite atualizar simultaneamente o próprio formulário em todos os projetos que o utilizam e simplifica a coleta de estatísticas e também melhora a experiência do usuário, permitindo que ele permaneça no mesmo serviço em que estava originalmente.



No nosso caso, a restrição de chamadas para métodos WebAuthn a partir do iframe nos fez procurar maneiras de contorná-lo, porque queríamos permitir o logon via WebAuthn em qualquer lugar onde mostrássemos o formulário de autorização.

O que nos fizemos. Para abrir o formulário de autorização em todos os serviços, usamos uma pequena biblioteca, que basicamente apenas cria um iframe na página com o URL correto e, após carregar seu conteúdo, mostra o iframe na página. Essa biblioteca oferece suporte à comunicação com iframes por meio de postMessagee usa-a, por exemplo, para redimensionar iframes ao redimensionar seu conteúdo.

Criamos e implementamos o seguinte mecanismo:

  1. no aplicativo de autorização ao usar o WebAuthn, determinamos se estamos abertos dentro do iframe ou não;
  2. se estivermos abertos dentro do iframe, em vez de chamar a API WebAuthn do navegador, serializamos os parâmetros de chamada e os enviamos pela postMessagejanela pai;
  3. na janela pai, desserializamos esses parâmetros e chamamos os métodos WebAuthn;
  4. quando recebemos uma resposta, a serializamos da mesma maneira e a enviamos pelo postMessageinterior de um iframe, onde aceitamos essa resposta e executamos processamento adicional.

Assim, contornamos essa proibição e percebemos a possibilidade de usar a mesma chave durante a autorização em todos os serviços da empresa.

Automação de Teste WebAuthn


Em nossa equipe, para todos os novos projetos e recursos, sempre escrevemos autotestes de interface do usuário de integração usando soluções semelhantes ao selênio e o protocolo WebDriver. Portanto, durante o desenvolvimento do WebAuthn, surgiu a questão de como escrever a interface do usuário de autoteste.

A dificuldade em escrever esses autotestes é que o protocolo WebDriver ainda não possui métodos para automatizar a interação com o WebAuthn. E no próprio padrão ainda não há suporte para a API WebAuthn de automação de teste (mas há um problema neste tópico). As primeiras idéias sobre como essa automação pode ser organizada estão descritas em um rascunho de Autenticação da Web: Uma API para acessar credenciais de chave pública nível 2 e ainda não foram publicadas, sem mencionar o suporte em outros lugares. Portanto, eu tive que propor soluções alternativas.

Porque como não podemos trabalhar com a implementação nativa das funções WebAuthn nos autotestes (não há métodos para controlar o navegador), tivemos que fazer o seguinte.

Em algum lugar do autoteste, antes de tentar usar o WebAuthn, corrigimos os objetos de host globais do navegador e substituímos as funções nativas por nossas implementações. Aqui, salvamos os argumentos com os quais as funções nativas foram chamadas em uma variável e retornamos a promessa.

//    WebAuthn   
navigator.credentials.create = (options) => {
    window.credentialsCreateArgs = options;

    return new Promise((resolve, reject) => {
        window.credentialsCreateSuccess = resolve;
        window.credentialsCreateFail = reject;
    });
};

Em seguida, precisamos obter de alguma forma o resultado da função para retorná-la para emular o trabalho do WebAuthn nos testes. Sempre podemos retornar algum tipo de resposta constante codificada.

// -    
const credentialsCreateResponse = { /* constant object */ };

window.credentialsCreateSuccess(credentialsCreateResponse);

Nesse caso, teremos que ensinar nosso servidor a aceitar esta resposta e não validá-la, mas considere-a automaticamente correta.

Quais são as desvantagens de tais testes? Nesse caso, não seremos capazes de:

  • verifique se o cliente forma e rola corretamente os parâmetros nas funções WebAuthn;
  • verifique a correção das alterações de back-end ao rolar as versões de back-end.

Portanto, esses testes não serão confiáveis ​​o suficiente e isso não nos convém.

Decidimos seguir o caminho mais difícil e, como resultado, escrevemos nossa própria implementação de protocolos e algoritmos FIDO2 no Node.js, com a ajuda da qual conseguimos bloquear essas funções o mais próximo possível das implementações nativas.

Ou seja, escrevemos uma função que, com base nos parâmetros de solicitação, calcula a resposta para as funções WebAuthn bloqueadas, para que o servidor considere que ela está completamente correta.

// -    
const credentialsCreateResponse =
    calcCredentialsCreateResponse(window.credentialsCreateArgs);
 
window.credentialsCreateSuccess(credentialsCreateResponse);

Como resultado, o esquema de operação de autoteste é o seguinte:

  1. obtenha os argumentos com os quais os métodos WebAuthn foram chamados;
  2. executamos esses argumentos através de uma função que implementa os mesmos algoritmos que os autenticadores reais;
  3. obtemos o resultado e o devolvemos de nossas funções substituídas;
  4. todo o restante do código em nosso serviço processa essas respostas no modo usual e, como resultado, todo o comportamento do serviço não difere de seu comportamento para usuários reais.

As fontes desse autoteste e a implementação do autenticador mais secreto estão no repositório do github . Você pode iniciar e investigar o trabalho deles posteriormente. Ao escrever o autenticador, fomos guiados apenas pela especificação w3.org e pela documentação do Node.js.

O presente e o futuro da WebAuthn


Então, o que temos no momento.

Lançamos uma entrada de chave eletrônica totalmente funcional no final de setembro de 2019. Agora, não anunciamos esse tipo de entrada, e ele não é usado muito ativamente - menos de cem usuários únicos por dia. Mas estamos confiantes de que, com o tempo, seu número só aumentará e, mais cedo ou mais tarde, o registro eletrônico de chaves se tornará um dos principais tipos de login em sua conta.

O que nos impede de promover ativamente essa entrada é que o próprio WebAuthn ainda não é suficientemente confiável e estável nos navegadores, e há muitas nuances em relação ao seu suporte e operação.

Por que o WebAuthn agora é um recurso que não é para um público amplo?

O fator mais básico aqui é que ele exige que o usuário tenha um dispositivo especial - uma chave eletrônica. Agora, a necessidade não é tão sentida pelos usuários. Muitos usuários não estão cientes de sua existência. Porém, com o tempo, quando mais e mais serviços começarem a oferecer suporte a essa maneira de efetuar login, o número de usuários com essas chaves também começará a crescer.

Um salto significativo na popularidade do WebAuthn pode ocorrer quando os engenheiros do Google concluem o desenvolvimento e o teste da possibilidade de usar smartphones no Android e iOS como chaves eletrônicas físicas externas para o WebAuthn e abrem essa oportunidade para todos os serviços da Internet. Nesse caso, cada proprietário de um smartphone moderno terá essencialmente a oportunidade de usá-lo como uma chave WebAuthn e o número de usuários do WebAuthn aumentará drasticamente. Agora, esse recurso está disponível apenas para usuários do serviço de e-mail do Google.



De que outra forma você pode usar o WebAuthn?


O Mail.ru agora usa o WebAuthn como uma alternativa às senhas para inserir a conta. Mas essencialmente o WebAuthn pode ser usado como qualquer um dos fatores de autorização. Ele pode ser usado como substituto do primeiro fator na autenticação de um fator. Então, em vez do segundo - como uma proteção de senha adicional com dois fatores. Além disso, a confirmação por meio de uma chave eletrônica pode ser usada, por exemplo, ao restaurar o acesso a uma conta se o usuário perdeu ou esqueceu sua senha.

O WebAuthn pode ser usado como uma medida de segurança adicional ao editar configurações críticas da sua conta. Imagine como é conveniente - você acessa as configurações do perfil no seu serviço favorito e não precisa se lembrar e inserir uma senha para alterá-las! Basta colocar o dedo no scanner de impressão digital e você será repassado.

Você pode encontrar cenários ainda mais diferentes para usar o WebAuthn neste artigo Médio .

Perguntas e respostas populares


Onde posso comprar uma chave eletrônica?


Até o momento, não há muitos lugares na Rússia onde você pode comprar chaves eletrônicas compatíveis com os protocolos FIDO2. A maioria dos fornecedores os vende somente a granel, em lotes de 10 ou mais. Você pode comprar chaves eletrônicas peça por peça nas seguintes lojas:


Além disso, essas chaves podem ser solicitadas em lojas on-line amigáveis, por exemplo, na Amazon . Em deste artigo, existem características comparativas de interruptores electrónicos 10 modelos com links para lojas onde podem ser comprados.

E se eu perder minha chave eletrônica?


Usando chaves eletrônicas, você deve tratá-las com a mesma atenção que as chaves do apartamento ou carro. Se perdermos as chaves do apartamento, geralmente trocamos a fechadura e obtemos novas chaves. O mesmo ocorre com as chaves eletrônicas: se elas forem perdidas, você deverá removê-las imediatamente de todas as contas em que foram vinculadas e anexar um novo autenticador a todas as contas.

Em caso de perda da chave eletrônica principal, você deve ter vários métodos de autenticação adicionais. Por exemplo, usando o aplicativo para gerar códigos ou usando uma chave reserva que pode ser armazenada em um local especialmente protegido: em um cofre ou em uma célula bancária.

O que devo fazer se outra pessoa obtiver acesso à minha chave eletrônica?


Se a autenticação de dois fatores estiver incluída em sua conta e a chave eletrônica for apenas um dos fatores, nesse caso, sua conta estará protegida contra hackers. A menos que o atacante tenha acesso ao segundo fator.

Se a chave eletrônica for o único fator suficiente para entrar na conta, mesmo neste caso, o invasor deve saber o nome da conta na qual essa chave eletrônica está registrada. Essas informações não são armazenadas dentro da chave eletrônica e, portanto, uma chave eletrônica acidentalmente perdida com um alto grau de probabilidade será completamente inútil para um transeunte que a encontrou.

No entanto, existem esquemas nos quais as chaves eletrônicas podem ser usadas como um substituto não apenas para uma senha, mas também para um login. Nesse cenário, o servidor fornece credenciais apenas ao solicitar credenciais.origin, e as próprias credenciais são totalmente armazenadas no autenticador. Nesse caso, a chave eletrônica perdida já pode ser facilmente usada para entrar na sua conta e, em seguida, você deve ter mais cuidado com o seu autenticador. Para proteção em tais cenários, você pode usar chaves eletrônicas com medidas de segurança adicionais, por exemplo, chaves, para as quais é necessário ativar um código PIN.

De qualquer forma, assim que você notar a perda da sua chave, desative-a imediatamente de todas as contas em todos os serviços, onde poderá usá-la para entrar. É por isso que todos os serviços devem fornecer a capacidade de gerenciar uma lista de autenticadores vinculados. Quanto mais rápido você perceber a perda, menos tempo os invasores terão para obter acesso aos seus dados.

Agora meus dados biométricos serão armazenados nos servidores Mail.ru/Google/Microsoft?


Quando o WebAuthn trabalha com autenticadores internos (por exemplo, usando o Touch ID no Mac OS), apenas o sensor correspondente e o próprio sistema operacional têm acesso aos seus dados biométricos. O serviço da Web não recebe nem processa nenhuma informação biométrica; ele funciona apenas com a chave criptográfica pública e com os dados assinados com a chave privada.

E no próprio servidor, apenas informações sobre a chave pública são armazenadas. Portanto, o WebAuthn não usa seus dados biométricos de forma alguma para trabalhar com autenticadores internos.

Conclusão


Como descobrimos, o WebAuthn tem muitas vantagens importantes sobre as senhas:

  • ao usar o WebAuthn, não é necessário lembrar e inserir senhas;
  • WebAuthn - , ;
  • WebAuthn ;
  • WebAuthn — .

No entanto, as senhas não devem ser descartadas. Uma chave física ainda pode ser roubada ou perdida, como uma senha. Mas as senhas têm uma vantagem importante. Desde que sejam armazenados apenas na cabeça, eles não serão capazes de reconhecê-los sem o conhecimento do proprietário.

Resumindo, quero dizer que a tecnologia WebAuthn é uma tecnologia muito promissora que altera um elemento tão básico e importante do funcionamento de todos os serviços da Web modernos como autenticação. É também uma tecnologia bastante jovem e os usuários ainda não estão acostumados. Mas está ao nosso alcance torná-lo mais popular e conveniente.

Espero que nossa experiência na implementação do WebAuthn no Mail.ru Mail o ajude a apoiá-lo em seus serviços e, juntos, tornaremos a Internet mais segura e moderna!

Materiais adicionais



All Articles