Security WatchSenhas e cartões de crédito, Parte 2

Jesper M. Johansson

Sumário

Processo do pseudologon multifator
O problema dos suplementos do navegador
O autenticador nunca deve mudar
Fazendo downgrade para senhas menos seguras
Ignorando o pseudologon multifator
Problemas com senhas comprometidas
Algumas vantagens
Enganando os usuários com colírio para os olhos
Abrir ou não abrir
Fornecendo comunicação segura
É sobre privacidade

Bem-vindo à segunda parte da série de três sobre como o setor de TI confunde os consumidores em vez de ajudá-los quando se trata de problemas de segurança. Na edição de julho de 2008 da TechNet Magazine, falei sobre o aviso de segurança inacionável e incorreto, e sobre fluxos de trabalho de logon confusos. (Se você ainda não leu a Parte 1, poderá encontrá-la

em technet.microsoft.com/magazine/cc626076.) Discuti como o aviso de segurança, que é extremamente comum e, no entanto, ineficiente, e os fluxos de trabalho de logon inválidos confundem os consumidores e acabam com seus esforços para proteger as informações pessoais.

Nesta edição, continuarei essa discussão com mais exemplos reais tirados do mundo da segurança do consumidor. A última parte desta série, que incluirá um "alerta" aos profissionais de segurança do mundo, aparecerá na próxima edição da TechNet Magazine.

Processo do pseudologon multifator

Em outubro de 2005, o FFIEC (Comitê de Investigação de Instituições Financeiras Federais) publicou as diretrizes para "Autenticação em um ambiente bancário na Internet" (consulte www.ffiec.gov/press/pr101205.htm). O cronograma de implementação era de apenas 14 meses e as instituições financeiras dos Estados Unidos começaram a ter dificuldade em encontrar um meio de cumprir essas novas diretrizes.

A maioria delas não conseguiu cumprir o cronograma. Muitas que finalmente conseguiram cumprir as diretrizes fizeram-no com medidas que não servem a nenhuma outra finalidade a não ser essa. Em outras palavras, as instituições tomaram medidas que não oferecem mais segurança aos clientes (são apenas práticas no "espetáculo da segurança"). Alguns dos exemplos mais interessantes de soluções inúteis são aqueles que tentam criar uma autenticação multifator que, na verdade, não é multifator.

Por exemplo, considere a tecnologia que mede a cadência da digitação quando um usuário digita uma palavra. Usada em um site, essa solução apresenta uma caixa de diálogo de logon com a aparência exata da antiga caixa de diálogo de logon. No entanto, essa nova caixa é um objeto Adobe Flash.

O objeto Flash registra a cadência da digitação do usuário, incluindo características como em quanto tempo as teclas são pressionadas e qual o tempo decorrido entre os pressionamentos de teclas. Esses dados são enviados ao site junto com a senha, onde são comparados com os valores armazenados. Contanto que os dados da cadência da digitação estejam de acordo com algumas variações dos dados armazenados e a senha seja igual, o logon é aceito. A idéia geral é que isso permite ao site usar um método de autenticação pseudobiométrico, sem ter de instalar hardware de terceiros no cliente.

Chamarei isso de pseudo-autenticação multifator. Não é uma verdadeira autenticação multifator, que mede dois ou mais dos seguintes fatores canônicos:

• Algo que o usuário possui (como um cartão inteligente)
• Algo que o usuário conhece (como uma senha)
• Algo que faz parte do usuário (como uma impressão digital)

Em vez de realmente incluir vários fatores no processo de autenticação, a pseudo-autenticação multifator lê vários parâmetros a partir de um único fator: a senha. Então, ela usa esses parâmetros adicionais para fazer inferências sobre algo que faz parte do usuário.

A tecnologia usada na pseudo-autenticação multifator apresenta várias falhas. Juntas, elas podem fornecer uma tecnologia extremamente ineficiente para resolver os problemas de segurança que se propõe a resolver.

O problema dos suplementos do navegador

Os sistemas de pseudo-autenticação multifator contam com suplementos do navegador para fornecer o processamento sofisticado do lado do cliente de que precisam. Todo software, é claro, possui bugs, e alguns desses bugs causam vulnerabilidades. Essas vulnerabilidades se tornam um grande problema quando o software é difícil de atualizar e o usuário não tem certeza de que uma atualização foi instalada.

Os suplementos do navegador apresentam essas duas características: eles são difíceis de atualizar e não fornecem ao usuário informações amplas sobre se a versão instalada está atualizada. Conseqüentemente, o usuário deve expor uma parte do software à Internet que, de outra forma, não seria necessário.

Em alguns casos, manter o suplemento atual significa fazer visitas regulares ao site do suplemento para obter as atualizações. Não é preciso dizer que muitos usuários não farão isso. Qualquer sistema que exija que um usuário final exponha um software adicional, não relacionado, à Internet simplesmente para fornecer a funcionalidade de segurança deve ser seriamente reavaliado.

O autenticador nunca deve mudar

O fator "algo que faz parte de você" apresenta uma característica, ou talvez até uma falha, que não afeta os outros dois fatores. Embora você possa alterar as senhas (algo que você conhece) e criar novos tokens de segurança (algo que você possui), o número de autenticadores biométricos que você pode usar é extremamente limitado. Com as impressões digitais, por exemplo, normalmente você tem dez a vida inteira. E, se perder um dedo em um acidente, dificilmente poderá substituí-lo.

Agora considere a maneira como isso se aplica ao exemplo do pseudologon multifator. A métrica coletada como parte de outro fator não pode ser facilmente substituída ou modificada. Sem dúvida, quando a senha é alterada, a forma como o usuário a digita é alterada, mas não a maneira como ele em geral pressiona as teclas no teclado. Essa técnica conta exatamente com isso. Se essa métrica ficar comprometida, será possível sintetizá-la. No mínimo, um invasor conseguirá capturá-la e reproduzi-la.

Fazendo downgrade para senhas menos seguras

É uma boa idéia usar senhas longas e alterá-las com freqüência. E, conforme discuti na Parte 1 desta série, também é recomendável (ao contrário do que dizem) registrar suas senhas, de maneira segura, é claro. Entretanto, essas práticas não são condizentes com a digitação da senha à mão. Uma senha longa é mais difícil de digitar, e uma senha registrada é muito mais útil quando você pode copiá-la e colá-la. Uma das melhores maneiras de manter o controle de cem ou mais senhas é usar um utilitário de software como o Password Safe (em sourceforge.net/projects/passwordsafe). Com esse tipo de ferramenta, você pode gerar senhas totalmente aleatórias, armazená-las de forma criptografada e colá-las direto nas caixas de diálogo de logon. Na verdade, com esse tipo de ferramenta, você nem precisa saber qual é a sua senha.

Mas tem um problema: não é possível medir a cadência da digitação a menos que o usuário digite uma senha. E se você não tiver de digitar a senha em um objeto que mede a cadência da digitação, essa técnica de gerenciar senhas começará a falhar. Digitar uma senha de 15 caracteres totalmente aleatória de maneira correta não é uma tarefa simples. E por isso os usuários geralmente optam por simplificar as senhas diante desse tipo de sistema. No entanto, por si só, uma senha de 15 caracteres totalmente aleatória é muito mais segura do que uma senha mais curta com um sistema de pseudo-autenticação multifator.

Realmente, a pseudo-autenticação multifator, implementada exclusivamente, força os usuários a usar senhas menos seguras. Infelizmente, como você verá em breve, acomodar usuários que usam técnicas de gerenciamento de senhas apropriadas praticamente anula qualquer vantagem oferecida pelos sistemas de pseudo-autenticação multifator.

Ignorando o pseudologon multifator

Mesmo que um site implemente a pseudo-autenticação multifator, ele ainda deve oferecer suporte a uma forma de ignorar o pseudo-sistema multifator. Primeiro, alguns sites podem exigir que todos os usuários instalem uma tecnologia de uma "quarta parte" para poder acessar o site. Parte dos usuários (alguns autores da TechNet Magazine, por exemplo) sempre se recusará a usar esse tipo de software.

Em segundo lugar, a cadência da digitação pode ser alterada por vários motivos e, portanto, os sites devem se acomodar a isso. Por exemplo, digamos que um usuário torça o pulso e sua cadência de digitação seja temporariamente alterada. Como ele fará para acessar o site se este, ao analisar sua cadência, achar que uma pessoa diferente está tentando fazer logon com as credenciais desse usuário? Se a lesão for permanente, o usuário poderá redefinir o valor de cadência armazenado. Entretanto, no caso de uma lesão temporária, provavelmente ele não desejará redefinir esse valor, supondo que sua cadência de digitação logo voltará a ser como antes.

Finalmente, nem todos os usuários são capazes de usar sistemas de pseudo-autenticação multifator. Por exemplo, um usuário portador de deficiência física que interage com o computador por meio de uma interface de reconhecimento da fala talvez não consiga preencher a caixa de diálogo se ela impedir a entrada programática. Nesse caso, um sistema alternativo que acomode usuários portadores de deficiência provavelmente será exigido por lei.

A maneira mais simples e direta de acomodar todos esses cenários é também oferecer suporte à autenticação padrão baseada em senha.

Problemas com senhas comprometidas

Os sistemas de pseudo-autenticação multifator têm o propósito de resolver vários problemas associados à autenticação baseada em senha. Entretanto, eles não conseguem impedir completamente todas as maneiras significativas pelas quais as senhas podem ficar comprometidas. Os sistemas que dependem da autenticação baseada em senha podem ficar comprometidos de cinco maneiras básicas, sendo que "comprometido" significa sofrer um ataque de um invasor que obteve e usou a senha de outro usuário:

• Adivinhação de senha
• Agentes coletores de pressionamentos de teclas
• Ataques de phishing
• Pedir ao usuário
• Invadir qualquer sistema que armazene a senha ou um pedaço dela

A adivinhação de senha não é mais um método de ataque muito comum dos criminosos e foi quase que totalmente suplantado por agentes coletores de pressionamentos de teclas e pelo phishing. A adivinhação de senha também é apenas parcialmente minimizada pela pseudo-autenticação multifator. Uma abordagem de adivinhação de senha convencional provavelmente não funcionará contra um sistema de pseudo-autenticação multifator já que o invasor deve adivinhar a senha, bem como a cadência da digitação. Embora, em teoria, seja possível sintetizar a métrica da digitação, raramente é necessário, porque os dados reais em geral podem ser capturados por um ataque de phishing ou um agente coletor de pressionamentos de teclas. Além disso, se o sistema também fornecer uma interface padrão de logon somente de senha, o invasor poderá simplesmente usar esse sistema para a adivinhação de senha.

Também, os ataques de adivinhação de senha são muito bem protegidos por senhas fortes. Se pudermos ensinar os usuários a usar senhas mais fortes, provavelmente com a ajuda de ferramentas, a pseudo-autenticação multifator não será necessária. Por outro lado, as senhas mais simples que em geral são usadas com os sistemas de pseudo-autenticação multifator, na verdade, tornam a adivinhação de senha uma abordagem viável. Assim, qualquer vantagem que seja oferecida aqui para minimizar a adivinhação de senha só será realmente válida se a implementação não oferecer suporte a logons somente de senha. E, como ressaltei, isso raramente é possível. Em outras palavras, se os usuários utilizarem senhas mais fracas na presença de sistemas de pseudo-autenticação multifator, a adivinhação de senha novamente se tornará um método de ataque viável; a pseudo-autenticação multifator reduz a segurança em vez de aumentá-la. Essa questão requer uma pesquisa mais profunda.

A pseudo-autenticação multifator também não consegue resolver o problema dos agentes coletores de pressionamentos de tecla. Embora não conheça nenhum agente coletor de pressionamentos de teclas de uso comum atualmente que capture a cadência da digitação, isso não significa que ele não venha a existir. Um agente coletor de pressionamentos de teclas é um hardware que fica entre o teclado e o computador ou um software que captura pressionamentos de teclas. Seja como for, agente coletor tem acesso total a todos os dados usados pela solução da pseudo-autenticação multifator.

Na verdade, ele pode acessar até mais dados já que uma solução de autenticação é executada no modo de usuário enquanto que o agente coletor de pressionamentos de teclas está muito além disso. Sem um caminho confiável entre o teclado e o objeto baseado na Web usado para capturar a senha, não é possível evitar esse tipo de comprometimento. Se as soluções de pseudo-autenticação multifator se tornarem bastante comuns, pode ter certeza de que alguém criará um agente coletor de pressionamentos de teclas desse tipo.

Da mesma forma, os ataques de phishing não são impedidos pela pseudo-autenticação multifator. Em vez de usar apenas uma tela de logon falsa, o invasor pode usar um objeto Flash para capturar a senha, bem como a cadência da digitação.

Sem dúvida, a pseudo-autenticação multifator pode ajudar em alguns cenários em que a técnica do invasor forneça apenas a senha do usuário. Por exemplo, a maneira mais fácil de obter uma senha de um usuário é pedir para ele. Por incrível que pareça, essa é comprovadamente uma técnica eficiente, seja pedindo pessoalmente, por telefone ou por mensagens de phishing.

É claro que pedir a um usuário para fornecer a sua cadência de digitação não será tão eficiente. Da mesma forma, se um banco de dados de senha corporativo for comprometido, o invasor provavelmente ganhará acesso apenas às senhas. Mas, novamente, esses ataques só serão minimizados se o sistema não fornecer nenhuma autenticação padrão somente de senha.

Também devo ressaltar que, se o banco de dados de senha em si ficar realmente comprometido, é bem provável que o invasor comprometa o sistema de uma forma muito mais profunda do que seria possível com uma única senha ou mesmo várias senhas de conta de usuário comuns. Portanto, não é muito válido tentar minimizar o que um invasor em posse de um banco de dados de senha é capaz de fazer.

Algumas vantagens

Certamente, há alguns problemas que a pseudo-autenticação multifator pode ajudar a resolver (supondo que o sistema não forneça nenhuma opção de logon padrão somente de senha). Por exemplo, ela pode ser usada para evitar o compartilhamento de senha. Contudo, isso pode ser uma desvantagem para sistemas em que seja legítimo a vários usuários compartilhar contas, como em contas de banco conjuntas.

Além disso, uma caixa de diálogo de logon interativa (e não um logon de site) construída de maneira adequada pode forçar um usuário a executar etapas de autenticação adicionais se a cadência da digitação não for a mesma. Essa pode ser uma medida de segurança adicional para uma conta comprometida em um ambiente altamente confidencial.

Enganando os usuários com colírio para os olhos

Uma das melhores maneiras de confundir os usuários é dar indicações de segurança imprecisas. A mais comum provavelmente é a imagem do cadeado exibida em uma página da Web, como mostra a Figura 1. Essa página ainda exibe a palavra "Seguro" pelo cadeado.

Figura 1 Um exemplo de uso indevido do ícone de cadeado, uma tendência preocupante (clique na imagem para ampliá-la)

Como você deve saber, simplesmente colocar uma imagem de cadeado e a palavra "Seguro" em uma página não a torna segura. No entanto, infelizmente essa prática é comum, mesmo entre os sites mais respeitáveis e visitados. O resultado é que muitos usuários são treinados para procurar essas pistas visuais de segurança no corpo da página em vez de olhar para onde realmente importa: na barra de endereços. (A W3C Web Security Context Wiki tem uma entrada sobre esse problema, disponível em w3.org/2006/WSC/wiki/PadlockIconMisuse.)

É uma pena que ainda haja tantos exemplos de uso indevido. Pesquisas mostram que os usuários são incapazes de identificar sites mal-intencionados mesmo quando os certificados são muito óbvios (consulte www.usablesecurity.org/papers/jackson.pdf). Trata-se da capacidade de distinguir facilmente o falso do verdadeiro, mesmo quando não se tem o verdadeiro para comparar. Isso requer habilidade; um colírio para os olhos de segurança enganador em páginas da Web compromete o desenvolvimento dessa habilidade já que os usuários são atraídos pelas informações erradas.

Uma variação especialmente perturbadora desse problema é mostrada na Figura 2. Nesse caso, a página que exibe as informações, na verdade, não é segura. Se você olhar para a barra de endereços, verá o "http" indicando o protocolo. Esse site usa uma técnica de otimização bastante comum: em vez de criptografar a página que contém o formulário de logon, somente o envio do formulário é criptografado. O logon é seguro, exatamente como a página declara, contanto que você entenda que "seguro" é igual a "criptografado". Entretanto (e isso é extremamente importante), o usuário não tem como verificar se as credenciais estão sendo enviadas antes de serem enviadas de fato! O site não mostra um certificado autenticando o site para o usuário antes que o formulário seja enviado. É uma questão de confiança, como cair de costas supondo que a pessoa atrás de você irá ampará-lo. No momento em que o formulário é enviado, o dano já ocorreu.

Figura 2 Colírio para os olhos de segurança em uma página não segura (clique na imagem para ampliá-la)

O protocolo SSL que fornece a segurança em HTTPS, serve a duas finalidades importantes. Primeiro, ele autentica o servidor para o usuário. Em segundo lugar, ele fornece um mecanismo fácil para negociar uma chave de criptografia de sessão que pode ser usada entre cliente e servidor.

Quando apenas o envio do formulário é criptografado, o principal objetivo não é alcançado. Os sites que empregam essa otimização usam o SSL apenas para negociar chaves. Ironicamente, eles poderiam fazer isso simplesmente empregando um protocolo de negociação de chaves padrão, evitando assim o custo e a sobrecarga do SSL.

O site mostrado na Figura 2 não é uma raridade. Muitos sites fornecem proteção SSL apenas para o envio do formulário, mas não para o formulário em si. Este site específico, porém, demonstra uma característica muito mais perturbadora. Se você digitar https://www.<site>.com (observe o indicador de https seguro) na barra de endereços do navegador, o site o redirecionará para a versão não-SSL do site! Mesmo que você tente inspecionar um certificado antes de enviar suas credenciais ao site, este se recusará a mostrá-lo.

Nem todos os sites são tão ofensivos, mas há muitos que são. E dois dos maiores emissores de cartão de crédito nos Estados Unidos estão entre os ofensores. Na verdade, das três maiores empresas de cartão de crédito que utilizo, somente a American Express oferece um certificado no formulário de logon. A American Express inclusive redireciona as solicitações HTTP para HTTPS. Parabéns!

Uma consideração final sobre o colírio para os olhos de segurança inútil e a falta de certificados no formulário de logon. Talvez você esteja se perguntando por que um site faria isso. O motivo é simples: por economia. Para apresentar certificados, é necessário criptografar a página, e a criptografia da página cria uma sobrecarga de processamento. Sobrecarga de processamento significa que mais computadores são necessários para atender à mesma carga. E mais computadores significa um custo maior. Infelizmente, quando se trata de escolher entre proteger a privacidade do cliente e aumentar os lucros, muitas organizações optam pelo segundo.

Abrir ou não abrir

Recentemente, recebi uma mensagem de email impressionante de minha empresa de seguro saúde. Qualquer pessoa que use um computador há 10 anos deve saber que nunca se deve abrir anexos de email não solicitado. Então, imagine a minha surpresa quando recebi a mensagem mostrada na Figura 3.

Figura 3 Mensagem de email contendo um "anexo seguro" (clique na imagem para ampliá-la)

Aparentemente, fiz uma pergunta no site da empresa de seguro saúde (e me esqueci disso quando a mensagem suspeita chegou). Foi assim que a empresa me respondeu. A princípio, pensei que era um esquema de phishing inteligente. Quando percebi que era uma mensagem legítima, fiquei de cabelo em pé.

A primeira instrução é para clicar duas vezes no anexo para começar a descriptografar a mensagem. A comunidade de segurança e os administradores de TI em massa passaram os últimos 10 anos tentando ensinar as pessoas a NÃO clicar duas vezes nos anexos. E, então, vem uma empresa (minha empresa de seguro saúde, a propósito, não é a única a usar essa abordagem) e diz que devo clicar no anexo para minha segurança. O que o usuário deve fazer nessa situação? Que comportamento ele aprende ou desaprende?

Em seguida, usei o recurso de visualização no Microsoft® Office Outlook® 2007 para exibi-lo. Como você pode ver na Figura 4, o Outlook achou que essa mensagem era um invasor e me advertiu a não abri-la!

Figura 4 O Outlook 2007 considera o documento de segurança hostil (clique na imagem para ampliá-la)

É irônico e ao mesmo tempo trágico ver uma empresa de seguro saúde violar as verificações básicas de segurança usadas nos clientes de email mais conhecidos do mundo. Considerando que ela nem mesmo se preocupou em testar sua nova solução de segurança com o Outlook, fico imaginando o que mais ela está deve estar fazendo com o intuito de proteger minhas informações particulares. Ou, para ser mais direto, que outras soluções estão sendo implementadas pela empresa apenas para não ser acusada de não proteger de maneira adequada a privacidade do cliente? É como o espetáculo da segurança criado pelas instituições financeiras. Nesse caso, acho que evitar uma acusação, em vez de realmente proteger os clientes, é o principal objetivo da solução.

Quis ver o que era aquele anexo. Na verdade, era um objeto de controle ActiveX®. Para ver o anexo, tive de abri-lo no Internet Explorer® e instalar o objeto. Foi exibida a tela de confirmação mostrada na Figura 5. Como você pode ver, os designers trabalharam muito para fazer a mensagem parecer um envelope de correio comum; ele inclusive contém um selo dizendo que o envelope é confiável.

Figura 5 O documento Seguro mostra um envelope com o selo "Confiável" (clique na imagem para ampliá-la)

Esse tipo de tecnologia é preocupante por vários motivos. Primeiro, ele reforça um comportamento nada saudável por parte do usuário: abrir anexos não solicitados. Em segundo lugar, na mensagem em si, ele apresenta uma orientação perigosa de configurar o sistema para sempre abrir anexos sem avisar. Em terceiro lugar, diante de mensagens conflitantes do computador, em que o email diz que é confiável e o Outlook diz que não é, a mensagem parece muito suspeita. Finalmente, o verdadeiro anexo contém um colírio para os olhos de segurança inútil para convencer o usuário de que é realmente confiável. Se o usuário aprender a confiar nesse tipo de mensagem, estará a um passo de confiar em mensagens mal-intencionadas com uma aparência semelhante.

Fornecendo comunicação segura

Sem dúvida, o problema que essa tecnologia se propõe a resolver é muito importante. É difícil comunicar-se com os clientes de maneira confiável. Entretanto, essa solução específica foi mal planejada. Provavelmente, ela causará confusão no cliente e criará exatamente o problema que deveria solucionar: o comprometimento do sistema do cliente.

Sites melhor planejados agora usam um "centro de mensagens". Nesse projeto, quando a empresa precisa se comunicar com o cliente, ela envia uma mensagem de email que diz algo como: "Você possui uma mensagem no centro de mensagens. Visite nosso site, faça logon e clique no link Centro de Mensagens para exibi-la". Uma empresa ganhará pontos se usar S/MIME (Secure Multipurpose Internet Mail Extensions) para assinar todas as mensagens de email do cliente para que o usuário possa autenticar a fonte. Ela ganhará mais pontos se a mensagem não incluir nenhum item "clique neste link" no email. O usuário deve digitar a URL da empresa à mão para garantir que está visitando o site esperado.

Com um centro de mensagens e uma mensagem assinada, uma empresa pode encontrar um meio confiável para se comunicar com o cliente. Tudo o que o cliente vê durante o fluxo de trabalho da mensagem é autenticado, e a empresa não promove práticas de segurança não recomendáveis.

É sobre privacidade

Até agora, na duas primeiras partes desta série, descrevi como os profissionais de segurança estão na verdade prestando um desserviço aos usuários. A nossa tarefa é manter a segurança. Mas muitas das decisões tomadas e soluções implementadas estão confundindo os usuários, ensinando-os a tomar péssimas decisões e dando-lhes uma falsa sensação de segurança. Não deveríamos sobrecarregar os usuários com essas idéias conflitantes.

Conforme mencionei anteriormente, para os usuários em geral, segurança significa apenas proteger senhas e números de cartão de crédito. Eles querem uma tecnologia que funcione e seja confiável. Infelizmente, eles têm de tomar decisões, e cabe a você garantir que o façam bem informados.

Na última parte desta série, discutirei sobre algumas das mais importantes tecnologias disponíveis aos consumidores que não deixam a desejar. Também apresentarei meu alerta. Portanto, não perca a coluna Security Watch de setembro de 2008.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele é Ph.D. em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP (Most Valuable Professional) da Microsoft em segurança corporativa. Seu livro mais recente é o Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem permissão.