Gerenciamento de identidades: Use a autenticação de dois fatores para minimizar a ocorrência de fraudes

Você pode — e deve — use autenticação de dois fatores com dispositivos móveis e desktop.

Dan Griffin e Tom Jones

No âmago de todas as transações baseadas na Web é o processo de gerenciamento de fraude. É essencial para equilibrar a inconveniência de autenticação do usuário com o risco de ser falsificado. Para colocá-lo de outra maneira, quando há conhecimento suficiente da identidade do usuário para permitir que a transação de proceder?

Autenticar a identidade do usuário já é um problema difícil em face de ataques a evoluir continuamente. Estamos agora no meio de uma grande mudança de paradigma. Dispositivos móveis, computadores de mesa não, será a plataforma para a maioria das transações.

Dispositivos móveis criam novos obstáculos à obtenção de serviços de Internet. Teclados inconsistentes e desajeitados torná-lo inconveniente para digitar senhas complexas, então a maioria dos dispositivos oferecem recursos para "lembrar" as senhas. Dispositivos móveis também são muito mais facilmente perdida ou roubada do que ferragem desktop. Além disso, aplicativos móveis — incluindo aqueles que podem ter acesso a senhas salvas — provaram ser difíceis para a veterinária. Esses fatores expõem as identidades dos usuários de risco adicional.

Não há outra maneira de ver a proliferação de dispositivos móveis. Não é necessariamente um problema, mas uma solução para métodos de autenticação anteriores preso em uma batalha perdida com os desenvolvedores de malware e ladrões.

O caminho de comunicação separada — ou seja, a rede de celular — para maior mobilidade permite que dispositivos, você fortalecer as barreiras enfrentadas por qualquer malware. Você pode usar esse caminho separado para vincular o usuário para um número de telefone específico. Depois disso, a ligação de usuário-para-dígitos (ou apenas ter um chip SIM específico) pode ser reconfirmado como necessário durante transações on-line. Isso resulta em um aumento exponencial do número de tentativas que um invasor precisaria montar para obter o mesmo nível de sucesso.

Número de telefone como prova

Usando números de telefone para reduzir fraudes on-line não é novo. Bancos têm sido empregando esta técnica há anos. O que é novo é a capacidade de qualquer serviço on-line, pequena ou grande, facilmente incorporar esse recurso.

Recentemente, a Microsoft adquiriu PhoneFactor, uma solução de autenticação de multifatores baseada em telefone celular. Agora está disponível para clientes como ativo a autenticação do Windows Azure. Com PhoneFactor, quando um serviço on-line requer autenticação de dois fatores, o telefone pode fornecer o segundo fator em uma variedade de maneiras:

  • O servidor faz uma chamada automatizada volta ao telefone com uma mensagem de voz, incluindo um código secreto one-time. Em seguida, o usuário digita o código em um formulário Web para concluir a transação on-line desejada.
  • Ele também pode enviar uma mensagem SMS, em vez de uma mensagem de voz, para transmitir o código one-time e a prova da posse do usuário do dispositivo.
  • Uma variação do processo anterior é configurar o sistema para permitir que o usuário responder diretamente para o SMS (ou uma árvore de telefone durante uma chamada de voz). Isso evita ter que se lembrar do código ao mudar de uma tela ou janela para outro e nos fazer digitação adicional. Em vez disso, o serviço da Web on-line é notificado de forma assíncrona da resposta SMS válida do usuário, e a transação solicitada, que estava pendente, é autorizada.
  • Um app móvel PhoneFactor-aware pode receber e responder corretamente a um autenticador do serviço de nuvem. Ao contrário as variações anteriores, essa abordagem requer explicitamente um smartphone app instalado no dispositivo móvel.
  • Você pode encaminhar um token suave (como OAuth) enviado para o PC ou telefone para o serviço consumindo a alegação. O servidor PhoneFactor não está envolvido no encaminhamento o token e nem precisa saber de onde ele é enviado.

Dada a hipótese de que a maioria dos usuários já têm seu telefone na maioria das vezes, o benefício é a autenticação de vários fatores, sem o custo de hardware incremental usual (token). Esta abordagem pode ter um impacto dramático na sua curva de risco/recompensa de fraude.

Agora imagine que você é um escritor de malware tentando atacar um Web site que requer este tipo de autenticação. Foco de ataques típicos no aparelho ou o caminho de comunicação para o dispositivo. Um ataque a conexão HTTP (TLS) é insuficiente para obter acesso ao serviço Web porque o código de autorização é enviado via celular. Para ser bem sucedido, um ataque deve comprometer ambos os canais.

Ameaças emergentes

É bom entender as ameaças mitigadas pela nova tecnologia, e como e quando são introduzidas novas ameaças. Felizmente, rootkits não ainda tornaram um fator de segurança do telefone. PhoneFactor funciona na camada de aplicativo e, portanto, não oferece nenhuma mitigação das ameaças de rootkit.

O app a nível, adicionando um segundo fator com nenhum caminho de comunicações em comum com outros fatores é significativa. É importante garantir que não há nenhum código compartilhado entre os caminhos. Isso significa que o usuário deve estar envolvido em algum nível, ou copiando um número pin de um processo para outro, ou aceitando um desafio ao telefone que é então encaminhado usando um dos mecanismos descritos aqui.

Qualquer interação que não envolva um ser humano no processo é aberta para ataque eletrônico. Por outro lado, novas ameaças a um dos caminhos de autenticação não apresenta uma ameaça maior do que o que já é representado pelo senhas estáticas.

Porque o código de autorização é diferente em cada acesso por cada usuário, um ataque bem-sucedido de nível de aplicativo não permite acesso irrestrito ao serviço da Web pelo invasor. Assim, o valor do ataque é reduzido.

Os atacantes estão interessados no retorno maior para o menor custo, portanto usando a autenticação de multifatores encoraja-os a procurar outro lugar para colheitas mais fácil. Autenticação de vários fatores, tornando relativamente barato de implementar, serviços como PhoneFactor reduzem a chance de que um ataque será bem-sucedida.

Fantasia brinquedos freqüentemente vêm com um aviso imprimido no exterior da caixa: "Alguma montagem necessária." É o mesmo com PhoneFactor. Para ajudar a estrutura de tópicos, os requisitos de integração típica, o resto deste artigo descreve soluções usando PhoneFactor em dois cenários de usuário diferente.

Login da Web

Para interoperáveis de logon da Web, o objetivo é usar o PhoneFactor para autenticação forte. Em seguida, você pode representar a identidade do usuário com um formato de token de Web padrão. Você pode usar PhoneFactor em baseada em navegador Web cenários de autenticação por pendente o pedido enquanto o back-end entra em contato com o telefone do usuário. Uma vez que o usuário se autentica, atualiza a página da Web e o usuário é livre para prosseguir com as transações sensíveis.

Para este trabalho, o aplicativo da Web deve confiar no serviço de PhoneFactor para autenticar o usuário. Terá que retornar alguma representação da identidade do usuário ou outros atributos de usuário. Sempre que possível, aplicativos da Web devem ser projetados para usar formatos token baseado em padrões, como SAML Security Assertion Markup Language () ou JSON Web Token (JWT). Isso ajuda a torná-los interoperáveis.

PhoneFactor com o Active Directory

PhoneFactor não é apenas para autenticação da Web, embora. Ele também pode ajudar a fazer a autenticação de usuário mais seguro sem muito inconveniente para logon de área de trabalho do Windows. Microsoft tem reconhecido a necessidade de apoiar métodos de autenticação alternativo no Windows.

A API de provedor de credencial oferece essa extensibilidade. Para iniciar o processo, o usuário baixa uma credencial provedor (CP) para o dispositivo. Quando o usuário tenta fazer logon, o CP envia uma mensagem para o serviço de autenticação backend, solicitando um desafio de PhoneFactor. A CP fornece uma caixa de edição para que o usuário digite o código recebido em seu telefone.

Uma vez que o código é verificado, o sistema de autenticação backend leva a etapa adicional de emissão de um certificado de curta duração infra-estrutura de chave pública (PKI) para o usuário. O CP usa o certificado para executar um logon de Kerberos. Como uma camada adicional de proteção, você pode ter a chave privada do certificado vinculado ao chip de segurança modelo de parâmetro de tipo (TPM) no dispositivo cliente. Ele também pode ser ligado a um pino aleatório gerado pelo CP. Isso resulta em uma credencial não exportável, de vários fatores que é interoperável com o hardware e os aplicativos existentes.

Esta abordagem tem a vantagem de bridging the gap entre PhoneFactor como o novo modo de autenticação e a infra-estrutura existente do Active Directory. Há vários componentes envolvidos na autenticação desktop de Windows de dois fatores:

  • O usuário fizer logon com a senha de domínio existente, além de um código secreto fornecido por PhoneFactor. Este modelo usa um serviço Web confiável para gerenciar a interação entre o cliente e o PhoneFactor back-end.
  • A CP adquire um certificado de autoridade de certificação (CA) e faz logon no Windows Active Directory. O serviço da Web confiável usa o token SAML dos serviços de Federação do Active Directory (AD FS) para adquirir o certificado de logon Kerberos/PKINIT.

Enquanto este cenário tem o usuário inserindo o PIN no computador associado ao domínio, você também pode instalar um aplicativo de telefone que permite que o usuário aceitar o pedido no telefone com um único clique.

Os benefícios da autenticação de dois fatores são bem conhecidos, mas tem sido difícil de conseguir na prática por causa da despesa em obter o segundo fator para as mãos dos usuários. Estas são algumas maneiras para estender a nova tecnologia Microsoft PhoneFactor para os reinos de autenticação de logon interativo da intranet, bem como baseada em padrões logon da Web.

Tom Jones

Tom Jones foi a cadeira fundador da American National Standards Subcomissão ASC X9A10 pagamentos electrónicos. Já trabalhou na Comunidade de serviços financeiros com várias organizações incluindo Electronic Data Interchange (EDI X 12) e Accredited Standards Committee X9 Inc. pagamentos electrónicos, bem como com a primeira Data Corp, Intel Corp. e a Microsoft.

 

Dan Griffin

**Dan Griffin**é o fundador do JW Secure Inc. e uma segurança da empresa de Microsoft MVP. Ele é o autor dos livros "Segurança de nuvem e controle" (CreateSpace independente plataforma de publicação, 2012) e "os quatro pilares do Endpoint Security: Salvaguardar a sua rede na era da Cloud Computing e o trazer-seu-próprio-dispositivo tendência "(CreateSpace independente publicação plataforma, 2013). Ele também é palestrante freqüente conferência e blogueiro no jwsecure.com/dan.

Conteúdo relacionado