SEGURANÇA EM SISTEMAS INFORMÁTICOS SENHAS DE UTILIZAÇÃO ÚNICA GRUPO 12 DAVID RIBEIRO FÁBIO NEVES EI06053@FE.UP.PT EI06102@FE.UP.PT Porto, 7 de Dezembro de 2010
Índice
Resumo O presente relatório tem como objectivo, a documentação do trabalho prático elaborado no âmbito da cadeira de Segurança em Sistemas Informáticos (SSIN). Será apresentada uma breve contextualização do panorama actual do problema a que o nosso sistema se propõe a melhorar, uma especificação detalhada do sistema então desenvolvido, nomeadamente em que consiste, a forma como está estruturado e o seu método de funcionamento. Abordaremos também, algumas possíveis falhas e vulnerabilidades a que o sistema pode estar exposto, e possíveis melhorias a implementar.
Introdução Nos dias de hoje, e cada vez mais, (quase) tudo é processado através da Internet. E para isso, é usual, cada pessoa ter uma conta própria em cada serviço online de que usufrui, a partir da qual pode tomar as suas acções. Ora, para garantir que ninguém, para além do titular, acede indevidamente à conta, é necessário garantir um sistema seguro de autenticação, contando claramente que o próprio não forneça as suas credenciais de acesso indevidamente a terceiros. Assim, e por forma a evitar que os utilizadores vejam as suas passwords descobertas por outros, e dando mais segurança a todo o mecanismo é usual adoptar-se algumas técnicas, como por exemplo: Password com data de expiração Após um certo tempo da definição da chave, esta expira a sua validade e é exigido ao utilizador que defina uma nova. Impossibilidade de repetir chave anterior De certa forma, esta medida interliga-se com o ponto anterior, já que de nada serve mudar de password se o utilizador irá definir a mesma. Logo define-se a impossibilidade de usar uma chave já usada anteriormente. Obrigatoriedade de usar um certo número de caracteres Por forma a aumentar a força da chave pede-se ao utilizador que misture, por exemplo, um determinado número de caracteres alfabéticos com numéricos. Isto faz com as chaves sejam mais complexas, e mais difíceis de obter. Inibir a utilização de determinadas palavras como chave Muitos utilizadores usam como chave coisas básicas e simples, como o próprio nome, data de nascimento, número de telefone, etc. De facto este é um dos maiores erros para quem não pretende ver a segurança da sua conta quebrada. Logo, através dos dados de registo, inibe-se a utilização destes na password. Mas, como em tudo, nada é totalmente garantido, e por isso todas estes medidas podem não ser suficientes. E assim, surge
falarmos num sistema de autenticação denominado por Chaves de Utilização Única ou One-Time Password (OTP).
Chaves de Utilização Única O método de Chaves de Utilização Única (OTP), baseia-se no facto que em cada vez que o utilizador se autentica no sistema, é utilizada uma chave diferente das anteriores. Portanto, trata-se de uma chave que logo após ser usada na autenticação, perde a sua validade, não podendo esta ser mais utilizada. Ora, isto evita que, mesmo o utilizador perdendo para mãos alheias a chave, esta já não servirá de nada, uma vez que fica logo inutilizável, sendo necessário uma nova chave para fazer novo acesso. Este sistema já é bastante utilizado hoje em dia, principalmente em sistemas bancários online, que veio substituir o antigo sistema de autenticação por cartão matriz. Métodos de Geração Uma vez que é necessária uma chave diferente a cada acesso, torna-se necessário definir um mecanismo que gere essas mesmas chaves. Normalmente os algoritmos utilizados fazem-no aleatoriamente, sendo assim mais difícil adivinhar a próxima chave tendo como base as anteriores, já que não teriam qualquer relação entre elas, mas existem outras formas de geração. Uma das formas é baseada na sincronização pelo tempo (data e hora). Este sistema implica que o utilizador tenha na sua posse um dispositivo de hardware (token) que se sincroniza com um servidor. Aqui a chave gerada tem como base o tempo actual, e que pode também ser conjugado, ou não, com as chaves geradas anteriormente. Um dos principais problemas aqui à vista é caso se dê um desfasamento da hora entre os dois pontos ligação. E neste caso o token do utilizador e o servidor iriam gerar chaves diferentes e a autenticação iria falhar. Outro método de sincronização é através de um contador. Este é sincronizado entre o token do utilizador e o servidor, e sempre que é solicitada uma nova chave, o contador é incrementado.
Um caso especial de autenticação bastante usado para cartões de crédito e débito debate-se com OTPs baseadas em desafio, isto é, para gerar uma nova chave é pedido ao utilizador um valor conhecido, como por exemplo um PIN. As chaves baseadas em hash utilizam então algoritmos de hash para computar a chave, que não são mais que uma função unidireccional que mapeia uma mensagem de tamanho arbitrário para uma chave de tamanho fixo. Assim, a função após receber o valor de entrada, como o PIN ou palavra-chave do utilizador, podendo também envolver um dos parâmetros de sincronização (tempo ou contador), irá executar e produzir então a chave pretendida. Métodos de Envio A forma como o utilizador toma conhecimento das chaves, ou da informação necessária à geração destas, é crucial nestes sistemas de segurança, pois é o momento mais frágil. Existem várias formas de passar esta informação ao utilizador: SMS Este será talvez o método mais simples e económico. Hoje em dia praticamente qualquer pessoa possui um telemóvel capaz de receber mensagens de texto, e assim poderá receber facilmente instantaneamente a chave gerada pelo servidor. Software executável em dispositivos móveis (Tlm, PDA, etc) Este método exige que o utilizador transporte consigo um dispositivo móvel capaz de executar um software que faça a ligação com o servidor e obtenha então a chave. Token próprio para o efeito Isto trata-se de um dispositivo concebido exclusivamente para o efeito, e que poderá assemelhar-se a um cartão de crédito, mas que terá embutido um sistema capaz de comunicar remotamente com o servidor, e depois apresentar, por exemplo, num pequeno ecrã a chave gerada.
Produto Nesta secção será feita uma descrição detalhada do sistema desenvolvido por nós, que implementa um sistema de chaves de utilização única. O nosso sistema é então constituído por duas partes fundamentais: Aplicação Cliente Servidor Web Fig. Arquitectura do sistema
Aplicação do cliente Fig. Arquitectura da aplicação cliente Esta é uma aplicação que executa do lado do cliente, e que sendo construída em Java é então multiplataforma, compatível com qualquer sistema. Uma vez que executa localmente para a geração das chaves, há assim maior protecção nos dados, uma vez que não há troca de informação sensível com o servidor, tornando bem mais complicada qualquer tentativa de fraude, uma vez que não é comunicado nem o algoritmo usado na encriptação das chaves, nem o segredo a partir do qual elas são geradas. Também oferece a possibilidade de guardar a lista das chaves geradas localmente para um ficheiro, sendo este também protegido através de um segredo definido pelo utilizador, o qual é sempre pedido para abrir a listagem das chaves guardadas.
Servidor Web Fig. Arquitectura do servidor web O Servidor encontra-se então alojado na web, e foi construído usando a linguagem PHP com recurso a uma base de dados MySQL. Este é responsável pelo registo de novos utilizadores e pela sua posterior autenticação no sistema. Ele é também capaz de verificar quando as chaves do utilizador esgotaram, recomendando-lhe que gere nova listagem, permitindo actualizar a senha deste.
Funcionamento Fig. Modo de funcionamento do sistema de autenticação Descrevendo então como todo o processo de geração de chaves e autenticação funciona, começamos pela aplicação cliente. Antes de tudo, é necessário abrir a aplicação cliente para gerar a listagem das chaves secretas a usar. Para isso fornece-se à aplicação um segredo, a partir do qual são computadas as chaves, e o número de chaves pretendidas. A listagem é criada, usando o segredo fornecido e aplicando sucessivamente o algoritmo de encriptação md5. Depois disto, é hora de registar no site (servidor), para tal fornecendo um nome de utilizador ao nosso agrado, a última chave gerada pela aplicação cliente e o número de chaves geradas. O número de chaves geradas apenas servirá para o servidor fazer a verificação de quando se esgotam as chaves do utilizador, nada mais. A última chave gerada é muito importante, porque é com ela que se irá verificar a validade das posteriores autenticações.
E o processo é feito da seguinte forma, uma vez geradas as chaves de 1 até N, e fornecendo no registo a chave N, na autenticação seguinte é pedido o nome de utilizador e a chave N-1. E para a autenticação ser bem sucedida, obviamente o nome de utilizador terá de existir, e a chave a ele associado terá de ser igual à chave criada, aplicando o algoritmo md5 à chave N-1 fornecida pelo utilizador. Se isso acontecer, a autenticação é permitida, o N decresce uma unidade e a chave na base de dados é actualizada para chave acabada de inserir. E para as seguintes autenticações repete-se o processo, fornecendo sempre a chave anterior, aplicando o md5, e verificando se é igual à chave que se encontra armazenada na BD. Quando o N chegar a 0, é então altura de gerar novas chaves na aplicação cliente, e actualizar no site a última chave gerada e o respectivo N.
Conclusões Este sistema apesar de não ser de fácil utilização, pois é necessária a formação dos utilizadores na forma como este funciona e os utilizadores necessitam ter consigo o programa com as suas chaves, é de fácil implementação e aumenta consideravelmente a segurança pois: As senhas são mais longas e aleatórias, logo mais difíceis de decorar ou adivinhar Cada senha utilizada torna-se inútil logo após a sua utilização, logo mesmo que esta caia em mãos erradas, não poderão ser causados danos Como a geração das chaves é feita do lado do cliente, a informação passada na comunicação com o servidor não é sensível As passwords guardadas no computador do cliente são encriptadas com uma senha do utilizador, podendo ser desencriptadas apenas com a posse desta e da aplicação cliente Embora tenhamos implementado este sistema utilizando um site web, este pode ser estendido a qualquer sistema que requeira autenticação. As maiores fragilidades detectadas são as situações em que o utilizador chega ao fim das suas chaves e não actualiza o site, e neste caso a senha a utilizar é sempre a última das suas chaves. Existe ainda outra situação, que é no caso de o utilizador perder as suas senhas. Neste caso o utilizador poderia ser autenticado utilizando um email ou uma sms, permitindo assim reiniciar o sistema utilizando outro conjunto de senhas. O nosso sistema poderia ser melhorado implementando esse mesmo sistema de recuperação de contas de utilizadores. Ainda, se o utilizador utilizar um número de senhas pequeno, isto pode constituir uma vulnerabilidade que pode ser agravada pelo facto de utilizar sempre a mesma senha para gerar as palavras passe. Se isto acontecer significa que as palavras passe a utilizar para se autenticar no sistema serão poucas e muito repetidas,
sendo possível obter uma delas e utilizá-la para se autenticar na próxima vez que seja repetida.
Bibliografia Wikipédia, último acesso em 28 de Outubro de 2010 http://en.wikipedia.org/wiki/one-time_password MSDN Magazine Setembro 2010, último acesso em 28 de Outubro de 2010 http://msdn.microsoft.com/pt-br/magazine/cc507635.aspx Web Foundations, último acesso em 28 de Outubro de 2010 http://www.webfoundations.com.br/blog/?tag=otp Internet FAQ Archives, último acesso em 28 de Outubro de 2010 http://www.faqs.org/rfcs/rfc2289.html