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

Jesper M. Johansson

Conteúdo

Aviso de segurança não acionável
Não acionável e incorreto
Aviso incompreensível
As armadilhas da autenticação de site baseada na imagem

Recentemente, fui contatado pela Universidade de Minnesota para ser entrevistado para esta revista. Aparentemente, eles queriam mostrar alguns alunos bem-sucedidos e – como não conseguiram encontrar nenhum – acabaram me escolhendo. A entrevistadora me perguntou no que eu trabalhava, e passei alguns minutos tentando descrever um software para infra-estrutura de segurança

. Daí ela exclamou: "mas isso parece muito complicado! Para mim, segurança quer dizer senhas e cartões de crédito".

Pensei nessa reação por alguns minutos e percebi que ela estava, de certa maneira, muito certa. A segurança está, de fato, relacionada a senhas e cartões de crédito. Pelo menos, é isso o que importa para o usuário final. Nós, que trabalhamos na atividade, achamos que segurança diz respeito a algoritmos criptográficos, se Kerberos é uma opção melhor do que TLS ou NTLMv2, os méritos do WS*, se devem ser usados hashes de senha e todos os demais tópicos esotéricos que adoramos discutir. É claro que temos uma perspectiva muito diferente e aprofundada em relação aos usuários finais, mas, de modo geral, perdemos uma coisa fundamental de vista: segurança, para aqueles a quem devemos servir, está relacionada a senhas e cartões de crédito.

Tudo bem, todo aquele esoterismo que tanto amamos discutir e as novas tecnologias que adoramos inventar são justamente para proteger os dados do usuário. Ainda assim, acho que nos perdemos. Nós, a subcultura de segurança do mundo de TI, existimos para atender a uma determinada necessidade de nossos clientes: a necessidade de manter os dados em segurança. Isso, obviamente, inclui garantir a possibilidade de uso desses ativos de TI com segurança. É isso.

Nas colunas anteriores, comentei que ninguém sai por aí e compra um computador só para poder executar um software antivírus. O usuário compra um computador para usar o banco eletrônico online, executar jogos de computador, escrever emails, fazer o dever de casa ou alguma outra função importante. Da mesma forma, nenhuma empresa financiou um grupo de segurança de TI só para que pudesse implementar NTLMv2. As empresas financiam grupos de segurança de TI para que estes possam proteger os ativos da organização, o que permite a elas usar seus recursos de TI com grande segurança e atingir seus objetivos comerciais.

A nossa existência não é outra senão servir.

Sendo assim, devo perguntar se estamos, de fato, fazendo um bom trabalho "servindo" ultimamente. Ou nós, da subcultura de segurança, estamos, na verdade, mais atrapalhando do que ajudando? E os legisladores e as reguladoras estão contribuindo para que atrapalhemos? Não estou convencido de que toda essa nova tecnologia que estamos colocando em prática realmente ajude os usuários finais. Por isso, gostaria de explorar algumas áreas às quais nós, os provedores de TI do mundo, estamos fazendo mais mal do que bem.

Há dias em que a maior parte dos avisos de segurança e das muitas tecnologias de segurança que impomos a nossos usuários é não acionável, incorreta, incompreensível ou (em muitos casos) uma combinação das três. Nesta série em três partes, observarei algumas das formas com as quais confundimos os usuários ao dar avisos e implantar tecnologias, culpados por uma ou mais dessas três características negativas.

Aviso de segurança não acionável

Uma das melhores formas de confundir as pessoas é dar avisos de segurança não acionáveis. De lambuja, também é possível fazer isso de maneira incorreta. A Figura 1 ilustra um aviso totalmente inútil, teoricamente importante e bastante antigo.

Figura 1 Aviso de segurança não acionável (Clique na imagem para ampliá-la)

Está vendo onde se diz para usar uma senha diferente para cada conta online? Há trinta anos, essa recomendação fazia sentido. O número de pessoas naquilo que acabou se transformando na Internet estava próximo dos milhares e todas elas eram bem espertas para não escolher senhas lá muito boas. Infelizmente, esse aviso se manteve e continua sendo repetido sempre, não havendo esforço aparente para adaptá-lo à forma como os computadores são usados atualmente.

Quantas contas online você tem? Particularmente, tenho 115, considerando algumas que não acompanho. O aviso na Figura 1 não apenas sugere que eu deva ter 115 senhas diferentes, mas também que preciso alterar essas 115 senhas passados entre 30 e 60 dias. Em outras palavras, preciso trocar entre duas e quatro senhas diariamente. (Faça o cálculo: isso também quer dizer que teria entre 690 e 1.380 senhas por ano.)

Embora a equipe de suporte técnico de alguns sites que estejam dando o aviso possa ser capaz de suportar quatro senhas boas por dia e manter 115 senhas atuais na memória a curto prazo, é possível ter a certeza de que 99,99 por cento do público que surfa na Web não conseguirá isso.

Na verdade, o aviso para usar senhas diferentes em todos os lugares está correto e é importante, de um ponto de vista essencialmente teórico, por ser o aviso para alterar todas as senhas passados entre 30 e 60 dias. Mas esse aviso também é não acionável. Com o número de senhas que os usuários têm hoje em dia, eles simplesmente não podem segui-lo sem algum tipo de ajuda como, por exemplo, papel ou software. Vejamos o próximo exemplo.

Não acionável e incorreto

O trecho do aviso mostrado na Figura 2, retirado do site de um dos maiores bancos do mundo, é não acionável e está incorreto. As informações fornecidas sob o título "Read our password advice" ("Leia o nosso aviso quanto a senhas") vão bem até a linha "different passwords everywhere" ("senhas diferentes em todos os lugares"). Ele também recomenda que você "jamais as anote".

Figura 2 Aviso não acionável e incorreto (Clique na imagem para ampliá-la)

Então, agora tenho 115 senhas diferentes, tenho que criar quatro novas diariamente e não posso anotá-las. Por um momento me achei burro porque não conseguia me lembrar de todas as minhas senhas. Depois, descobri que todo mundo faz exatamente a mesma coisa. É simplesmente impossível para seres humanos lembrar 115 senhas. Podemos lembrar e processar aproximadamente sete partes de informações – e é exatamente assim que somos programados. Acompanhando a maioria dos avisos de senha encontrados na Internet, isso não é o suficiente para uma senha sequer (consulte "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information", de George A. Miller, disponível em musanim.com/miller1956).

O aspecto negativo é que, quando o assunto é aviso de senha, o nosso setor, com bastante regularidade, engana os usuários. Se a subcultura da segurança dirá aos usuários que devem usar senhas diferentes em todos os lugares, também precisaremos informá-los como – e isso significa registrar e armazenar essas senhas em algum lugar seguro. Anotá-las em um pedaço de papel, usar um documento protegido ou uma ferramenta especializada como, por exemplo, PasswordSafe (sourceforge.net/projects/passwordsafe). Sejamos sinceros, ou anotamos as nossas senhas, ou usamos as mesmas em todos os lugares. Na verdade, uma pesquisa recente apontou que 88 por cento dos usuários usam a mesma senha em todos os sistemas nos quais se autenticam (consulte msnbc.msn.com/id/24162478).

Certamente, o aviso que recrimina anotar a senha é um fator que contribui para essa tendência. O que precisamos fazer é ensinar os usuários a gerenciar senhas (e outros dados confidenciais) de maneira efetiva, e não ensiná-los a não gerenciar essas informações de modo algum. Dessa forma, a probabilidade de que eles comprometam suas credenciais será muito menor.

Aviso incompreensível

As duas primeiras figuras repetem um aviso antigo que funcionava bem nos idos dos anos 60, 70 e 80, muito antes dos grandes usuários permanecerem online e usarem serviços baseados na Web. Pelo menos por enquanto, ninguém fez grandes reclamações quanto a esse tipo de aviso porque são informações normalmente aceitas.

Esse tipo de aviso confunde os usuários e pode fazer com que eles se sintam culpados por precisar guardar as senhas em algum lugar. Dando esse tipo de aviso, em vez de ajudar os usuários a fazer aquilo que precisam, os profissionais da segurança causam prejuízo. Afinal, não é de responsabilidade do usuário imaginar como gerenciar a segurança. Isso cabe aos profissionais de segurança. Precisamos imaginar formas aceitáveis para que nossos usuários gerenciem suas contas online. Mas, como a maior parte das diretrizes acaba repetindo o mesmo aviso ultrapassado, os usuários recorrem a anotações adesivas e planilhas para acompanhar suas muitas senhas.

Como mecanismo de autenticação, as senhas têm muito a oferecer. Porém, o principal problema é que seres humanos são péssimos quando chega a hora de se lembrar delas. Em vez de tentar resolver um problema da natureza humana, o mundo de TI continua inventando todos os tipos de mecanismo para substituir senhas – ou, pior ainda, aumentá-las. Isso só deixa os usuários ainda mais confusos.

Imagine a minha surpresa na última vez em que acessei um determinado site de serviços financeiros e vi uma tela de logon que apresentava apenas uma caixa de texto do nome de usuário (consulte a Figura 3).

Figura 3 Onde digito a minha senha?

Inicialmente, pensei se tratar de algum site mal-intencionado. Depois, validei rapidamente o site – essa etapa foi simples porque ele apresentou um certificado – e percebi que estava, de fato, no lugar certo. O problema é que as pessoas estão acostumadas a ver dois campos, nome de usuário e senha, apresentados juntos no logon em um site. Isso se deve a anos encontrando o mesmo fluxo de trabalho comum. Assim, quando você chega a um site que, inesperadamente, pede apenas o nome de usuário, as coisas começam a se complicar. Acontece que, nesse caso, o provedor tinha implementado uma tecnologia que usava imagens para identificar o site aos usuários, em uma tentativa de impedir ataques de phishing. Assim, quando você preenche o nome de usuário, o site exibe uma tela pop-up com uma imagem identificável, como mostra a Figura 4.

Figura 4 Alguns sites agora usam imagens para autenticar o site para um usuário(Clique na imagem para ampliá-la)

A teoria é de que você conhece a imagem de cada site. Caso não seja exibida a imagem correta, é possível identificar o site como sendo falso. Isso, por si, é um conceito interessante. Supondo que o usuário saiba a imagem de cada site, essa estratégia tem algum sentido.

É claro que o leitor mais esperto perceberá a barra de endereços verde na Figura 4. Isso significa que o site usa certificados SSL e EV (validação estendida), motivo pelo qual a barra de endereços está verde. Isso também quer dizer que toda a premissa de usar a imagem para identificar o site não agrega valor algum. Na verdade, a imagem não faz muito senão criar confusão pelo menos para alguns usuários finais. O site já se identificou para o usuário – ele apresentou um certificado contendo o nome da empresa, o endereço do site e o nome do emissor confiável. E o fato da barra de endereços estar verde me diz que a empresa chegou a executar a etapa adicional de pagar três vezes mais por um certificado EV.

Assim, é claro que as imagens também podem ser falsificadas. Caso o usuário possa enviar sua própria imagem, há formas pelas quais o invasor pode imaginar que imagem está sendo usada. Como também existe uma boa chance de que o usuário use a mesma imagem em todos os sites, tudo o que o invasor terá que fazer é criar um site com o conteúdo a ser avaliado pelo usuário (deixarei você apresentar exemplos próprios) e pedir a ele uma imagem a ser usada na verificação do site. Se o usuário utilizar a mesma imagem para todos os sites, esse novo site agora terá acesso à imagem utilizada pelo usuário, por exemplo, no site do banco eletrônico.

Embora alguns sites permitam que você escolha sua própria imagem, há outros que usam uma biblioteca de fotos em estoque. O site na Figura 4, por exemplo, conta com 318 fotos em estoque a serem escolhidas. O truque anterior não funciona em sites que não permitam ao usuário enviar suas próprias fotos. No entanto, se o usuário não escolher uma imagem própria, a probabilidade de que ele se lembre de qual site é cada figura será pequena em sites não visitados com freqüência. Honestamente, não tenho idéia de qual imagem uso no site mostrado na Figura 4, embora possa garantir que não se trata da mostrada na captura de tela.

O problema dessa abordagem baseada na imagem é que um invasor pode mostrar qualquer uma das 318 imagens ou apenas escolher uma foto aleatória do Flickr, e muitos usuários acabarão supondo que essa seja a imagem correta. Se a maioria das pessoas conseguisse se lembrar de coisas como a figura de cada site, não teríamos todos os problemas relacionados a phishing e segurança que temos atualmente.

E por que usar uma imagem para autenticar o site para o usuário quando o site já se autenticou usando o certificado? Por que não usar apenas esse certificado e ajudar os usuários a aprender como validá-los? Os certificados já provaram a identidade do site para o usuário.

O processo para obter um certificado certamente é muito mais seguro do que o processo para obter a imagem de autenticação do site de um usuário. Se o certificado for EV e você estiver usando o Internet Explorer® 7 ou o Firefox 3, o navegador chegará a realçar as informações relevantes sobre o certificado na barra de endereços. Infelizmente, o realce só funciona com os certificados EV muito caros.

As armadilhas da autenticação de site baseada na imagem

A tecnologia de autenticação da imagem tem vários problemas. Primeiro, se torna muito fácil coletar nomes de usuário em um site. Na verdade, o site mostrado na Figura 4 apresentará a caixa de diálogo exibida na Figura 5 se você digitar o nome de usuário errado. Depois de digitar um nome de usuário correto para um usuário que escolheu uma imagem secreta, você obtém a imagem secreta da pessoa. Obviamente, esse conhecimento poderia ser muito importante para um invasor que estivesse tentando coletar informações sobre um usuário.

Figura 5 Sites autenticados por imagem possibilitam uma fácil coleta do nome do usuário

O tipo de implementação mostrado aqui praticamente não tem nenhum valor em termos de segurança. O invasor pode simplesmente duplicar o fluxo de trabalho de logon em um site falso. O site falso pede e passa um nome de usuário para o site real. É possível até mesmo usar o AJAX no cliente para atualizar o formulário em tempo real para conseguir uma aparência ainda mais legal. Além disso, caso o site legítimo não tenha atenuado ataques de falsificação entre sites no formulário de logon, o código AJAX pode até mesmo enviar a solicitação para o site real diretamente, a menos que o navegador tenha atenuações para solicitações XML-HTTP entre sites.

Agora, assim que o resultado voltar, o invasor poderá analisar os dados, conseguir a imagem e exibi-la ao usuário final. Em outras palavras, qualquer invasor capaz de apresentar um site com logon falso para o usuário também pode exibir sua imagem secreta. O resultado prático é a inexistência absoluta de valor agregado com o uso da autenticação do site baseada em imagem. A imagem é exibida antes da autenticação do usuário no site e, por isso, ela permanece disponível a um invasor que tem, ou pode ter, o nome do usuário.

Supondo que o usuário jamais tenha sido instruído a procurar um certificado antes de enviar formulários – e essa é uma suposição certa, considerando que o próprio uso da autenticação de site baseada em imagem parte dessa mesma suposição –, obter um nome do usuário é simples. Além disso, como muitos esquemas de autenticação de site baseados em imagem respondem de maneira diferente a um nome de usuário válido em relação a um nome de usuário inválido, obter o nome do usuário é simples. O invasor pode fazer isso até mesmo fora de banda, antes de um ataque ser iniciado.

No final, temos usuários que acreditam estar mais seguros ou aqueles que só se confundem mais. Gastamos um grande volume do capital próprio dos acionistas implementando a autenticação de site baseada na imagem, e não dificultamos em nada para que usuários mal-intencionados convencessem os usuários finais a enviar suas credenciais para sites falsos.

Acabou o espaço que tinha para esta parte da Security Watch. Não deixe de conferir, no mês que vem, a segunda parte desta série, quando abordarei mais exemplos de práticas de segurança mal orientadas e de más implementações de autenticação.

Jesper M. Johansson é arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele possui Ph.D em MIS, tem mais de 20 anos de experiência em segurança e é MVP Microsoft em segurança corporativa. Seu livro mais recente é 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 autorização.