1º Módulo
Soluções multifatoriais
Soluções multifatoriais, em que a credencial que protege a conta de um usuário não é apenas uma senha, tornaram-se a resposta a ataques destinados a comprometer senhas. Ao combinar uma senha com outro fator, como soluções de autenticação suportadas por hardware, os invasores não conseguem extrair tudo o que é necessário para comprometer uma conta.
Nem toda autenticação multifator é igual
Ter um usuário utilizando qualquer forma de autenticação multifator é melhor do que usar uma senha de fator único, mas a tecnologia multifator de primeira geração que usa segredos compartilhados, como um código de uso único enviado para um telefone celular ou um aplicativo push um telefone celular que exige que o usuário confirme o acesso também é vulnerável a ataques de engenharia social. Com o tempo, os invasores infelizmente desenvolveram métodos fáceis de criar para explorar essas fraquezas, enganando as vítimas e não apenas entregando suas senhas, mas também evitando essas proteções adicionais. É aqui que os desenvolvedores e usuários veem o valor da WebAuthn.
A WebAuthn representa a próxima etapa na evolução constante da autenticação forte, com foco em fornecer segurança superior às soluções de autenticação existentes, enquanto permanece fácil para os serviços se levantarem e os usuários aproveitarem. O design do WebAuthn é baseado na segurança comprovada oferecida por uma estrutura de credenciais de infraestrutura de chave pública (PKI). A PKI é comumente usada para proteger uma série de casos de uso em que a segurança é essencial, incluindo autenticação máquina a máquina e cartões inteligentes emitidos pelo governo.
Atende ao mesmo nível de segurança
Uma das dificuldades significativas no uso de uma estrutura de credenciais PKI é configurar a infraestrutura para emitir credenciais e autenticar com elas. Em uma implantação de PKI tradicional, cada emissão de credencial ou autenticação requer uma cadeia de autenticação de volta para uma autoridade central que atesta a autenticidade de cada etapa envolvida. Esses requisitos tornam a implantação de PKI tradicional inadequada para soluções voltadas ao público e desajeitada para serviços da web. WebAuthn resolve esses problemas descentralizando a estrutura tradicional de PKI.
Com WebAuthn, um serviço da web, conhecido como Relying Party (Parte confiante), se comunica com o Authenticator (Autenticador) de um usuário por meio de um navegador da web, que atua como o Client (Cliente) WebAuthn . Esses termos e interações serão discutidos com mais detalhes nas próximas seções. Nesse caso, o navegador, como o cliente WebAuthn, fornece a infraestrutura que conecta o autenticador do usuário à parte confiável e facilita a comunicação confiável entre eles. A maioria dos navegadores da web populares oferece suporte ao WebAuthn, removendo a responsabilidade do usuário e de qualquer serviço de manter esse recurso. Tudo o que o usuário precisa é um dispositivo autenticador WebAuthn, enquanto o serviço só precisa se preocupar em ter um serviço WebAuthn ou serviço para oferecer suporte.
As credenciais WebAuthn, ao contrário de senhas, códigos de uso único ou outras soluções mais antigas, são construídas em torno de chaves criptográficas assimétricas, onde um par de chaves públicas e privadas matematicamente associadas constituem a base para a verificação do usuário. Essas credenciais são criadas no autenticador do usuário e a chave privada nunca é exportada; apenas a chave pública deixa o dispositivo. As chaves públicas são inúteis para um invasor que deseja roubar uma credencial, protegendo contra ataques que visam serviços e também tentando enganar o usuário para que exponha sua credencial.
Além disso, o cliente WebAuthn garante que a comunicação entre o autenticador e a parte confiável permaneça segura, verificando se a comunicação não é interceptada ou redirecionada em trânsito, evitando a captura de uma interação válida da WebAuthn para uso em um ataque. Os serviços também podem exigir que os usuários verifiquem sua propriedade de um autenticador para interações WebAuthn, exigindo que o usuário forneça algo conhecido, como um PIN, ou algo intrínseco a eles, como uma impressão digital biométrica, para seu autenticador antes de prosseguir. A WebAuthn evita que as credenciais sejam fracas e reutilizáveis, resolvendo os problemas subjacentes às senhas, bem como à geração anterior de autenticação multifator.
A WebAuthn possui vários recursos exclusivos que atendem aos desafios atuais de autenticação. Exploraremos alguns desses desafios com mais detalhes posteriormente no curso. Mas primeiro vamos fazer um inventário rápido.
WebAuthn makes use of asymmetric cryptography (WebAuthn usa criptografia assimétrica), que permite o uso de chaves criptográficas separadas para assinar e verificar informações.
WebAuthn is scoped (WebAuthn tem escopo definido), cada serviço ou site usando WebAuthn é registrado diretamente no autenticador de um usuário, sem informações sobre outros serviços registrados compartilhados entre eles.
WebAuthn is user privacy focused (WebAuthn tem como foco a privacidade do usuário), que é um dos principais benefícios de um protocolo de autenticação com escopo definido. As informações sobre os serviços nos quais um usuário se registrou não são compartilhadas com terceiros não relacionados.
WebAuthn is attested (WebAuthn é atestado). O atestado permite que o provedor do autenticador verifique se seus usuários têm autenticadores WebAuthn seguros e processos de registro adequados.
WebAuthn allows services to require user consent (WebAuthn permite que os serviços exijam o consentimento do usuário). O protocolo pode permitir interações que exijam que o usuário execute uma ação física para permitir o registro ou autenticação usando um dispositivo WebAuthn, evitando ataques remotos que contornem um usuário.
WebAuthn flips the authentication paradigm (WebAuthn inverte o paradigma de autenticação). Ao contrário da autenticação baseada em senha, os usuários autenticam localmente e as partes confiáveis validam localmente. Nenhuma infraestrutura de chave pública é necessária, e o protocolo lida com muito do trabalho manual que um desenvolvedor poderia ter.
Até agora, aprendemos que a WebAuthn é um método inovador e seguro para autenticação forte com resistência a phishing e outros recursos integrados ao protocolo.
Mas o que o torna único em comparação com seus pares de autenticação multifator e como ele difere de sua autenticação de senha padrão?
Fluxo bidirecional exclusivo
O processo geral de autenticação da WebAuthn usa um fluxo bidirecional exclusivo que é completamente diferente dos modos de autenticação anteriores.
Seu fluxo de autenticação baseado em senha típico é assim:
Se o usuário deseja efetuar login, ele fornece sua senha, e talvez sua senha de uso único, para a página da web em que está atualmente. Essas credenciais acabam indo... para algum lugar. Para o bem do usuário, a preferência é que ele tenha inserido essas credenciais no site real que o usuário estava tentando acessar, mas se ele estiver sendo fisicamente ativo, esse pode não ser o caso. É aí que reside o problema da autenticação tradicional baseada em senha.
Agora, vamos dar uma olhada em um fluxo de autenticação WebAuthn:
Ao contrário do fluxo de senha anterior, a interação da WebAuthn é um ciclo bidirecional entre a parte confiável WebAuthn do serviço da Web através do cliente WebAuthn do navegador para os usuários WebAuthn Authenticator e vice-versa.
Vamos fazer uma pausa aqui para um pouco de vocabulário. WebAuthn é composto por esses três componentes fundamentais.
WebAuthn Authenticator (Autenticador WebAuthn) é o dispositivo do usuário que contém as chaves privadas registradas pelo usuário, usadas para autenticação. O Autenticador WebAuthn pode ser integrado à plataforma de um usuário ou dispositivo móvel, como Windows Hello ou TouchID e FaceID, ou pode ser um autenticador "móvel", como uma chave de segurança. Autenticadores de roaming são dispositivos externos que podem ser conectados ou se comunicar sem fio com um dispositivo host.
O WebAuthn Client (Cliente WebAuthn) é a "máquina no meio" que atua como uma ponte entre a Parte Confiante e o autenticador WebAuthn do usuário. Pode ser um navegador da web, um cliente embutido em um aplicativo ou até mesmo um sistema operacional como Windows, Android ou iOS.
A Relying Party (Parte Confiável) é outro nome para o serviço ou site que hospeda seu próprio servidor WebAuthn. O usuário se registra e autentica com a parte confiável e é a parte confiável que realiza várias verificações para garantir que o registro ou autenticação é válido de acordo com as regras que definiu.
Embora pareça complicado, a experiência do usuário é tranquila, sem comprometer a segurança. Veremos a interação entre esses três componentes principais posteriormente neste módulo.
Por enquanto, vamos continuar e explorar os fluxos de Registro e Autenticação com mais detalhes.
Fluxo de registro do WebAuthn
Lembre-se de que isso é principalmente para sua compreensão do que está acontecendo entre os três componentes fundamentais. Muito disso já será feito para você como um desenvolvedor da Web se você usar uma biblioteca ou framework WebAuthn.
Um fluxo de registro WebAuthn é a interação para criar e associar uma nova credencial WebAuthn a uma parte confiável; em essência, registrar um autenticador WebAuthn com uma conta em um serviço de suporte WebAuthn.
Da perspectiva da experiência do usuário, neste ponto, o usuário pode ter clicado em um link para iniciar o processo de registro. Por exemplo, o link pode dizer “Adicionar chave de segurança”. Esse link aciona nosso Javascript WebAuthn do lado do cliente para iniciar seu processo e acionar uma série de outros eventos. Voltemos ao nosso diagrama da seção anterior. Aqui, mais uma vez temos nossos três componentes fundamentais esperando algo para fazer.
Primeiro no fluxo de registro, nossa Relying Party (Parte Confiável) criará um identificador exclusivo para si mesma e um sobre o usuário e o passará para a WebAuthn Client (Cliente WebAuthn).
Agora, estamos na WebAuthn Client. O cliente anotará o nome de domínio que fez a solicitação de registro e o comparará com as informações que a Relying Party enviou para sua segurança.
Se tudo correr bem, a WebAuthn Client pedirá ao usuário que prove que deseja registrar um dispositivo. Isso é conhecido como Proof of Presence (Prova de Presença) e é outra verificação de segurança que ajuda garantir que haja um ser humano nos bastidores fazendo essa tentativa. Normalmente, provar que você deseja registrar um dispositivo envolve nada mais do que tocar em um botão, inserir um PIN ou verificar um atributo biométrico no Autenticador WebAuthn.
Agora, aqui estamos no Autenticador WebAuthn, onde um par de chaves exclusivo será feito para esta parte / sessão confiável, e uma chave pública será enviada ao WebAuthn Client (Cliente WebAuthn), que a encaminhará para a Relying Party (Parte Confiável) para proteção.
Agora que temos um dispositivo WebAuthn registrado, vamos revisar o fluxo de autenticação.
Autenticar um dispositivo WebAuthn não é muito diferente do fluxo de registro. Vamos trazer nossos diagramas mais uma vez, mas desta vez para autenticação.
Uma interação de autenticação WebAuthn ocorre quando um autenticador WebAuthn registrado é verificado; essencialmente, quando um autenticador WebAuthn é usado para autenticar uma conta na qual ele foi registrado anteriormente.
A Relying Party (Parte Confiável) dá o pontapé inicial. Ele gera alguns dados aleatórios e os combina com algumas informações sobre si mesmo. Chamamos isso de Challenge (Desafio)
A Parte Confiável encaminhará isso ao Cliente WebAuthn.
Agora, aqui no cliente WebAuthn, o desafio é verificado para ver se a URL que alega ter se originado (chamado de origem) corresponde ao URL do site ao qual o usuário está conectado no momento, evitando ataques que tentem enganar os usuários para que usem páginas fraudulentas . Se tudo estiver alinhado, o desafio é enviado ao Autenticador WebAuthn.
O Autenticador WebAuthn precisa que o usuário prove que há um humano do outro lado, da mesma forma que fez quando o usuário registrou o dispositivo. Feito isso, o desafio é assinado e enviado de volta na cadeia até a Parte Confiante.
Assim que a Parte Confiável receber de volta o material assinado, ela terá tudo de que precisa para confirmar se o usuário está sendo phishing ou não.
A confirmação depende de informações como "qual site solicitou a autenticação?" e "este é o autenticador WebAuthn certo para este usuário?". Os dados de origem fornecidos pelo Cliente WebAuthn são uma parte crucial do motivo pelo qual o protocolo é tão poderoso.
Por design, a WebAuthn evita uma série de ataques que prejudicam os esforços para proteger senhas e outros esquemas de credenciais obsoletos. Essas proteções são exclusivas da WebAuthn e representam um salto em frente para a autenticação. As características de prevenção de ataques da WebAuthn incluem a gravação da URL de um serviço ou site da Web - e a captura dos dados de "origem" dentro do autenticador, um processo que revisamos na última seção, conforme vimos como o protocolo funciona. Nesta seção, exploraremos como esses recursos garantem segurança e privacidade.
Ataques comuns
Vamos abordar alguns dos ataques mais comuns contra a autenticação tradicional:
Man-in-the-Middle: ele se concentra em capturar a comunicação entre um usuário e o serviço para o qual ele está tentando se autenticar, capturando as credenciais passadas do usuário e permitindo que o invasor use disse credenciais diretamente. Esses tipos de ataque podem comprometer as senhas de uso único (OTPs) de uso único, bem como as senhas.
Phishing: um ataque de phishing ocorre quando um invasor direciona um usuário a uma página que parece uma página de login legítima, mas na verdade direciona as credenciais do usuário para o invasor. As páginas de phishing usam vários truques para fazer com que o conteúdo da página e o endereço pareçam corretos, geralmente enganando os usuários.
Engenharia social: os ataques de engenharia social se concentram no uso de informações públicas sobre um usuário para induzi-lo a permitir que um invasor acesse suas credenciais. Esses ataques incluem um amplo espectro, variando de e-mails solicitando informações de senha a ataques mais complexos que tentam convencer os usuários a usar soluções de autenticação como um aplicativo push, que é então usado para aprovar as tentativas de login do invasor.
Last updated
