Autenticação multifator (MFA) – NIST

Abreviatura (s) e Sinônimo (s):

2FA – (NIST SP 1800-27C)

MFA – (NIST SP 800-160 Vol. 2 , NIST SP 800-63-3 , NISTIR 8333)

 

Definição(ões):

 Autenticação usando dois ou mais fatores para obter autenticação. Os fatores incluem:

  • algo que você sabe (por exemplo, senha / número de identificação pessoal (PIN));
  • (ii) algo que você possui (por exemplo, dispositivo de identificação criptográfica, token); ou
  • (iii) algo que você é (por exemplo, biométrico).

Fonte(s): CNSSI 4009-2015 sob autenticação multifator do NIST SP 800-53 Rev. 4

Folha de referências de autenticação multifator da OWASP

Introdução

A autenticação multifator (MFA) ou autenticação de dois fatores (2FA) é quando um usuário deve apresentar mais de um tipo de evidência para se autenticar em um sistema. Existem quatro tipos diferentes de evidências (ou fatores) que podem ser usados, listados na tabela abaixo:

Fator

Exemplos

Algo que você sabe

Senhas, PINs e perguntas de segurança.

Algo que você tem

Tokens de hardware ou software, certificados, e-mail, SMS e chamadas telefônicas.

Algo que você é

Impressões digitais, reconhecimento facial, varreduras da íris e varreduras das impressões das mãos.

Localização

Intervalos de IP de origem e geolocalização

Deve-se enfatizar que, embora exija vários exemplos de um único fator (como a necessidade de uma senha e um PIN) , não constitui MFA , embora possa fornecer alguns benefícios de segurança em relação a uma senha simples.

Além disso, embora as seções a seguir discutam as desvantagens e os pontos fracos de vários tipos diferentes de MFA, em muitos casos eles são relevantes apenas contra ataques direcionados. Qualquer MFA é melhor do que nenhum MFA .

Vantagens

A maneira mais comum de as contas de usuário serem comprometidas em aplicativos é por meio de senhas fracas, reutilizadas ou roubadas. Apesar de quaisquer controles técnicos de segurança implementados no aplicativo, os usuários são responsáveis ​​por escolher senhas fracas ou usar a mesma senha em aplicativos diferentes. Como desenvolvedores ou administradores de sistema, deve-se presumir que as senhas dos usuários serão comprometidas em algum ponto, e o sistema deve ser projetado para se proteger contra isso.

A autenticação multifator (MFA) é de longe a melhor defesa contra a maioria dos ataques relacionados a senhas, incluindo força bruta, preenchimento de credenciais e pulverização de senhas, com análises da Microsoft sugerindo que teria interrompido 99,9% dos comprometimentos de contas .

Desvantagens

A maior desvantagem do MFA é o aumento da complexidade de gerenciamento para administradores e usuários finais. Muitos usuários menos técnicos podem achar difícil configurar e usar o MFA. Além disso, existem vários outros problemas comuns encontrados:

  • Os tipos de MFA que exigem que os usuários tenham hardware específico podem gerar custos e despesas administrativas significativas.
  • Os usuários podem ter suas contas bloqueadas se perderem ou não puderem usar seus outros fatores.
  • O MFA introduz complexidade adicional no aplicativo.
  • Muitas soluções de MFA adicionam dependências externas aos sistemas, o que pode introduzir vulnerabilidades de segurança ou pontos únicos de falha.
  • Os processos implementados para permitir que os usuários ignorem ou redefinam o MFA podem ser explorados por invasores.
  • A exigência de MFA pode impedir que alguns usuários acessem o aplicativo.

Recomendações rápidas

Exatamente quando e como o MFA é implementado em um aplicativo irá variar em vários fatores diferentes, incluindo o modelo de ameaça do aplicativo, o nível técnico dos usuários e o nível de controle administrativo sobre os usuários. Isso deve ser considerado por aplicativo.

No entanto, as recomendações a seguir são geralmente apropriadas para a maioria dos aplicativos e fornecem um ponto de partida inicial a ser considerado.

  • Fornece a opção para os usuários habilitarem o MFA em suas contas usando TOTP .
  • Exigir MFA para usuários administrativos ou outros usuários com privilégios elevados.
  • Considere permitir intervalos de IP corporativos para que o MFA não seja exigido deles.
  • Permitir que o usuário se lembre do uso de MFA em seu navegador, para que não seja solicitado sempre que fizer login.
  • Implemente um processo seguro para permitir que os usuários redefinam sua MFA.

Implementando MFA

Quando requerer MFA

O lugar mais importante para exigir o MFA em um aplicativo é quando o usuário efetua login. No entanto, dependendo da funcionalidade disponível, também pode ser apropriado exigir o MFA para executar ações confidenciais, como:

  • Alterando senhas ou perguntas de segurança.
  • Alterar o endereço de e-mail associado à conta.
  • Desativando MFA.
  • Elevar uma sessão de usuário a uma sessão administrativa.

Se o aplicativo fornece várias maneiras para um usuário autenticar, todas elas devem exigir MFA ou ter outras proteções implementadas. Uma área comum que é perdida é se o aplicativo fornece uma API separada que pode ser usada para fazer login ou tem um aplicativo móvel associado.

Melhorando a usabilidade

Ter que fazer login frequentemente com o MFA cria uma carga adicional para os usuários e pode fazer com que eles desabilitem o MFA no aplicativo. Vários mecanismos podem ser usados ​​para tentar reduzir o nível de incômodo que o MFA causa. No entanto, esses tipos de medidas diminuem a segurança fornecida pelo MFA, portanto, precisam ser avaliados quanto aos riscos para encontrar um equilíbrio razoável entre segurança e usabilidade para o aplicativo.

  • Lembrando o navegador do usuário para que ele não precise usar o MFA todas as vezes.
    • Isso pode ser permanente ou por um período de alguns dias.
    • Isso precisa ser feito com mais do que apenas um cookie, que pode ser roubado por um invasor.
      • Por exemplo, um cookie correspondente ao endereço IP anterior para o qual o cookie foi emitido.
  • Permita intervalos de IP corporativos (ou, mais estritamente, usando a localização como um segundo fator).
    • Isso não protege contra usuários internos mal-intencionados ou o comprometimento da estação de trabalho de um usuário.
  • Exigindo MFA apenas para ações confidenciais, não para o login inicial.
    • Isso dependerá muito da funcionalidade do aplicativo.

Tentativas de login com falha

Quando um usuário insere sua senha, mas não consegue se autenticar usando um segundo fator, isso pode significar uma das duas coisas:

  • O usuário perdeu o segundo fator ou não o tem disponível (por exemplo, não tem celular ou não tem sinal).
  • A senha do usuário foi comprometida.

Existem várias etapas que devem ser executadas quando isso ocorre:

  • Solicita ao usuário que experimente outra forma de MFA
    • Por exemplo, um código SMS em vez de usar seu token OTP de hardware.
  • Permitir que o usuário tente redefinir seu MFA .
  • Notifique o usuário sobre a falha na tentativa de login e incentive-o a alterar a senha caso não a reconheça.
    • A notificação deve incluir a hora, o navegador e a localização geográfica da tentativa de login.
    • Isso deve ser exibido na próxima vez que eles fizerem login e, opcionalmente, também enviado por e-mail.

Reiniciando MFA

Um dos maiores desafios da implementação de MFA é lidar com usuários que esquecem ou perdem seus segundos fatores. Isso pode acontecer de várias maneiras, como:

  • Reinstalar uma estação de trabalho sem fazer backup de certificados digitais.
  • Limpar ou perder um telefone sem fazer backup dos códigos OTP.
  • Alterando números de celular.

Para evitar que os usuários sejam bloqueados no aplicativo, deve haver um mecanismo para que eles recuperem o acesso à sua conta se não puderem usar o MFA existente; no entanto, também é crucial que isso não forneça a um invasor uma maneira de contornar o MFA e sequestrar sua conta.

Não existe uma “melhor maneira” definitiva de fazer isso, e o que é apropriado varia enormemente com base na segurança do aplicativo e também no nível de controle sobre os usuários. Soluções que funcionam para um aplicativo corporativo em que todos os funcionários se conhecem provavelmente não são viáveis ​​para um aplicativo disponível publicamente com milhares de usuários em todo o mundo. Cada método de recuperação tem suas próprias vantagens e desvantagens, e elas precisam ser avaliadas no contexto da aplicação.

Algumas sugestões de métodos possíveis incluem:

  • Fornecer ao usuário uma série de códigos de recuperação de uso único quando ele configurar o MFA pela primeira vez.
  • Exigir que o usuário configure vários tipos de MFA (como um certificado digital, núcleo OTP e número de telefone para SMS), de modo que é improvável que perca o acesso a todos eles de uma vez.
  • Publicar um código de recuperação de uso único (ou novo token de hardware) para o usuário.
  • Exigir que o usuário entre em contato com a equipe de suporte e que tenha um processo rigoroso para verificar sua identidade.
  • Exigir que outro usuário confiável ateste por eles.

Algo que você sabe

O tipo mais comum de autenticação é baseado em algo que os usuários sabem – normalmente uma senha. A maior vantagem deste fator é que ele possui requisitos muito baixos tanto para o desenvolvedor quanto para o usuário final, pois não requer nenhum hardware especial, nem integração com outros serviços.

Senhas e PINs

As senhas e os PINs são a forma mais comum de autenticação devido à simplicidade de implementação. A Folha de Referência de Autenticação contém orientações sobre como implementar uma política de senha forte e a Folha de Referência de Armazenamento de Senha fornece orientações sobre como armazenar senhas com segurança.

A maioria dos sistemas de autenticação multifator faz uso de uma senha, bem como de pelo menos um outro fator.

Deve-se observar que os PINs, “palavras secretas” e outros tipos semelhantes de informações são todos efetivamente iguais às senhas. O uso de dois tipos diferentes de senhas não constitui MFA .

Prós

  • Simples e bem compreendido.
  • Suporte nativo em cada estrutura de autenticação.
  • Fácil de implementar.

Contras

  • Os usuários estão propensos a escolher senhas fracas.
  • As senhas são comumente reutilizadas entre sistemas.
  • Susceptível a phishing.

Questões de segurança

As perguntas de segurança exigem que o usuário escolha (ou crie) uma série de perguntas para as quais somente ele saberá a resposta. Elas são efetivamente iguais às senhas, embora sejam geralmente consideradas mais fracas. A folha de dicas sobre como escolher e usar perguntas de segurança contém mais orientações sobre como implementá-las com segurança.

Prós

  • Simples e bem compreendido.

Contras

  • As perguntas costumam ter respostas fáceis de adivinhar.
  • As respostas às perguntas geralmente podem ser obtidas nas redes sociais ou em outras fontes.
  • As perguntas devem ser escolhidas com cuidado para que os usuários se lembrem das respostas anos depois.
  • Susceptível a phishing.

Algo que você tem

O segundo fator é algo que o usuário possui. Pode ser um item físico (como um token de hardware), um item digital (como um certificado ou chave privada) ou com base na propriedade de um telefone celular, número de telefone ou endereço de e-mail (como SMS ou software token instalado no telefone ou um e-mail com um código de verificação de uso único).

Se implementado corretamente, isso pode ser significativamente mais difícil para um invasor remoto comprometer; no entanto, também cria uma carga administrativa adicional para o usuário, uma vez que ele deve manter o fator de autenticação com ele sempre que desejar usá-lo.

A exigência de um segundo fator também pode limitar a capacidade de certos tipos de usuários de acessar um serviço. Por exemplo, se um usuário não tiver acesso a um telefone celular, muitos tipos de MFA não estarão disponíveis para ele.

Tokens OTP de hardware

Podem ser usados ​​tokens OTP de hardware físico que geram códigos numéricos em constante mudança, que devem ser enviados durante a autenticação no aplicativo. O mais conhecido deles é o RSA SecureID , que gera um número de seis dígitos que muda a cada 60 segundos.

Prós

  • Como os tokens são dispositivos físicos separados, é quase impossível para um invasor comprometer remotamente.
  • Os tokens podem ser usados ​​sem exigir que o usuário tenha um telefone celular ou outro dispositivo.

Contras

  • A implantação de tokens físicos para os usuários é cara e complicada.
  • Se um usuário perder seu token, pode levar um tempo significativo para comprar e enviar um novo.
  • Algumas implementações requerem um servidor de back-end, que pode apresentar novas vulnerabilidades, bem como um único ponto de falha.
  • Os tokens roubados podem ser usados ​​sem um PIN ou código de desbloqueio do dispositivo.
  • Susceptível a phishing (embora de curta duração).

Tokens TOTP de software

Uma alternativa mais barata e mais fácil aos tokens de hardware é usar software para gerar códigos de senha única baseada em tempo (TOTP). Isso normalmente envolveria o usuário instalar um aplicativo TOTP em seu telefone celular e, em seguida, digitalizar um código QR fornecido pelo aplicativo da web que fornece a semente inicial. O aplicativo autenticador então gera um número de seis dígitos a cada 60 segundos, da mesma forma que um token de hardware.

A maioria dos sites usa tokens TOTP padronizados, permitindo ao usuário instalar qualquer aplicativo autenticador que suporte TOTP. No entanto, um pequeno número de aplicativos usa suas próprias variantes (como Symantec), o que requer que os usuários instalem um aplicativo específico para usar o serviço. Isso deve ser evitado em favor de uma abordagem baseada em padrões.

Prós

  • A ausência de tokens físicos reduz muito o custo e a sobrecarga administrativa de implementação do sistema.
  • Quando os usuários perdem o acesso ao seu aplicativo TOTP, um novo pode ser configurado sem a necessidade de enviar um token físico para eles.
  • O TOTP é amplamente utilizado e muitos usuários já terão pelo menos um aplicativo TOTP instalado.
  • Enquanto o usuário tiver um bloqueio de tela em seu telefone, um invasor não conseguirá usar o código se roubar o telefone.

Contras

  • Os aplicativos TOTP geralmente são instalados em dispositivos móveis, que são vulneráveis ​​a comprometimento.
  • O aplicativo TOTP pode ser instalado no mesmo dispositivo móvel (ou estação de trabalho) usado para autenticação.
  • Os usuários podem armazenar as sementes de backup de maneira insegura.
  • Nem todos os usuários possuem dispositivos móveis para usar com TOTP.
  • Se o dispositivo móvel do usuário for perdido, roubado ou sem bateria, eles não poderão se autenticar.
  • Susceptível a phishing (embora de curta duração).

Tokens U2F de hardware

Os tokens U2F de hardware comunicam-se com a estação de trabalho do usuário por USB ou NFC e implementam autenticação baseada em desafio-resposta, em vez de exigir que o usuário insira o código manualmente. Normalmente, isso seria feito pelo usuário pressionando um botão no token ou tocando-o no leitor de NFC.

Prós

  • Códigos mais longos podem ser usados, o que pode fornecer um nível mais alto de segurança.
  • Os usuários podem simplesmente pressionar um botão em vez de digitar um código.
  • Resistente a phishing.

Contras

  • Assim como acontece com os tokens OTP de hardware, o uso de tokens físicos apresenta custos e sobrecargas administrativas significativas.
  • Os tokens roubados podem ser usados ​​sem um PIN ou código de desbloqueio do dispositivo.
  • Como os tokens são geralmente conectados à estação de trabalho via USB, é mais provável que os usuários os esqueçam.

Certificados

Os certificados digitais são arquivos armazenados no dispositivo do usuário, fornecidos automaticamente junto com a senha do usuário durante a autenticação. O tipo mais comum são os certificados X.509 (discutidos na Folha de Dicas de Proteção da Camada de Transporte ), mais comumente conhecidos como certificados de cliente.

Os certificados são suportados por todos os principais navegadores da web e, uma vez instalados, não exigem mais interação do usuário. Os certificados devem ser vinculados a uma conta de usuário individual para evitar que os usuários tentem se autenticar em outras contas.

Prós

  • Não há necessidade de comprar e gerenciar tokens de hardware.
  • Depois de instalados, os certificados são muito simples para os usuários.
  • Os certificados podem ser gerenciados e revogados centralmente.
  • Resistente a phishing.

Contras

  • O uso de certificados digitais requer um sistema PKI de back-end.
  • A instalação de certificados pode ser difícil para os usuários, principalmente em um ambiente altamente restrito.
  • Os servidores proxy corporativos que executam a descriptografia SSL impedirão o uso de certificados.
  • Os certificados são armazenados na estação de trabalho do usuário e, como tal, podem ser roubados se o sistema for comprometido.

Cartões inteligentes

Os cartões inteligentes são cartões do tamanho de um cartão de crédito com um chip contendo um certificado digital para o usuário, que é desbloqueado com um PIN. Eles são comumente usados ​​para autenticação do sistema operacional, mas raramente são usados ​​em aplicativos da web.

Prós

  • Smartcards roubados não podem ser usados ​​sem o PIN.
  • Os cartões inteligentes podem ser usados ​​em vários aplicativos e sistemas.
  • Resistente a phishing.

Contras

  • Gerenciar e distribuir cartões inteligentes tem os mesmos custos e despesas gerais que os tokens de hardware.
  • Os cartões inteligentes não são suportados nativamente por navegadores modernos, portanto, requerem software de terceiros.
  • Embora a maioria dos laptops de classe empresarial tenha leitores de smartcard integrados, os sistemas domésticos geralmente não têm.
  • O uso de cartões inteligentes requer sistemas PKI de back-end em funcionamento.

Mensagens SMS e chamadas telefônicas

Mensagens SMS ou chamadas telefônicas podem ser usadas para fornecer aos usuários um código de uso único que eles devem enviar como um segundo fator.

Prós

  • Relativamente simples de implementar.
  • Requer que o usuário vincule sua conta a um número de celular.

Contras

  • Requer que o usuário tenha um dispositivo móvel ou telefone fixo.
  • Requer que o usuário tenha sinal para receber a chamada ou mensagem.
  • O envio de chamadas e mensagens SMS pode custar dinheiro (necessidade de proteção contra invasores que solicitam um grande número de mensagens para esgotar os fundos.
  • Vários ataques contra SMS ou números de celular foram demonstrados e explorados no passado.
  • As mensagens SMS podem ser recebidas no mesmo dispositivo do qual o usuário está se autenticando.
  • Susceptível a phishing.

O email

A verificação de e-mail requer que o usuário insira um código ou clique em um link enviado para seu endereço de e-mail. Há algum debate sobre se o e-mail constitui uma forma de MFA, porque se o usuário não tiver o MFA configurado em sua conta de e-mail, ele simplesmente exigirá o conhecimento da senha de e-mail do usuário (que geralmente é igual à senha do aplicativo). No entanto, ele está incluído aqui para ser completo.

Prós

  • Muito fácil de implementar.
  • Não há requisitos para hardware separado ou dispositivo móvel.

Contras

  • Depende inteiramente da segurança da conta de e-mail, que muitas vezes carece de MFA.
  • As senhas de e-mail geralmente são iguais às senhas de aplicativos.
  • Não oferece proteção se o e-mail do usuário for comprometido primeiro.
  • O e-mail pode ser recebido pelo mesmo dispositivo do qual o usuário está se autenticando.
  • Susceptível a phishing.

Algo que você é

O fator final na visão tradicional do MFA é algo que você é – que é um dos atributos físicos dos usuários (freqüentemente chamado de biometria). A biometria raramente é usada em aplicativos da web devido à exigência de que os usuários tenham hardware específico.

Biometria

Existem vários tipos comuns de biometria usados, incluindo:

  • Digitalização de impressões digitais
  • Reconhecimento facial
  • Iris scans
  • Digitalizações de impressões manuais

Prós

  • Biometria bem implementada é difícil de falsificar e requer um ataque direcionado.

Contras

  • Requer inscrição manual dos atributos físicos do usuário.
  • Hardware customizado (às vezes caro) é freqüentemente necessário para ler dados biométricos.
  • Os navegadores modernos não têm suporte nativo, portanto, é necessário um software personalizado do lado do cliente.
  • Questões de privacidade: Informações físicas confidenciais devem ser armazenadas sobre os usuários.
  • Se comprometidos, os dados biométricos podem ser difíceis de alterar.

Localização

O uso da localização como um quarto fator para o MFA não é totalmente aceito; no entanto, é cada vez mais usado para autenticação. Às vezes, argumenta-se que a localização é usada ao decidir se deve ou não exigir o MFA (como discutido acima ), no entanto, isso é efetivamente o mesmo que considerá-lo um fator por si só. Dois exemplos proeminentes disso são as políticas de acesso condicional disponíveis no Microsoft Azure e a funcionalidade de desbloqueio de rede no BitLocker.

Ao falar sobre localização, o acesso ao aplicativo no qual o usuário está se autenticando geralmente não é considerado (pois esse sempre seria o caso e, como tal, é relativamente sem sentido).

Faixas de IP de origem

O endereço IP de origem a partir do qual o usuário está se conectando pode ser usado como um fator, normalmente em uma abordagem baseada em lista de permissões. Isso pode ser baseado em uma lista estática (como intervalos de escritórios corporativos) ou em uma lista dinâmica (como endereços IP anteriores dos quais o usuário foi autenticado).

Prós

  • Muito fácil para os usuários.
  • Requer configuração e gerenciamento mínimos da equipe administrativa.

Contras

  • Não oferece nenhuma proteção se o sistema do usuário estiver comprometido.
  • Não oferece proteção contra invasores internos.
  • Os endereços IP confiáveis ​​devem ser cuidadosamente restritos (por exemplo, se o Wi-Fi de convidado aberto usa o intervalo principal de IP corporativo).

Geolocalização

Em vez de usar o endereço IP exato do usuário, a localização geográfica na qual o endereço IP está registrado pode ser usada. Isso é menos preciso, mas pode ser mais viável de implementar em ambientes onde os endereços IP não são estáticos. Um uso comum seria exigir fatores de autenticação adicionais quando uma tentativa de autenticação é feita de fora do país normal do usuário.

Prós

  • Muito fácil para os usuários

Contras

  • Não oferece nenhuma proteção se o sistema do usuário estiver comprometido.
  • Não oferece proteção contra invasores internos.
  • Fácil para um invasor contornar obtendo endereços IP no país ou local confiável.

Referências

Multi-Factor Authentication (MFA). Disponível em: <https://csrc.nist.gov/glossary/term/multi_factor_authentication>. Acessado em 30 de agosto de 2021.

Multifactor Authentication Cheat Sheet. Disponível em: <https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html>. Acessado em 30 de agosto de 2021.