q
O mecanismo de autenticação de usuários mais comumente empregado por aplicações web consiste no fornecimento de identificador e senha, cuja correção deve ser verificada pela aplicação contra uma base de contas cadastradas. Essa abordagem pode ser imple- mentada por meio das seguintes tecnologias:
1Autenticação HTTP: baseia-se nos métodos Basic e Digest, nativos do protocolo HTTP,
que solicitam as credenciais por meio de uma caixa de diálogo exibida ao usuário pelo navegador web. Não é muito utilizada em aplicações acessíveis pela internet, salvo em alguns sistemas de correio eletrônico corporativo. Possui a desvantagem de não permitir travamento de conta, após múltiplas tentativas inválidas e sucessivas de autenticação.
1Autenticação integrada ao Windows: antigamente, conhecida por autenticação NTLM ou NT LAN Manager é um método suportado pelos produtos da Microsoft, que
utiliza Kerberos ou NTLM no processo de autenticação de usuários. Diferentemente da autenticação HTTP, primeiro tenta utilizar as informações de conta Windows presentes no cliente, antes de solicitar as credenciais para o usuário. Como não é capaz de traba- lhar em conexões com proxy, nunca é empregada em aplicações web na internet.
1Autenticação por formulários: segundo Stuttard e Pinto (2007), essa tecnologia é
usada por mais de 90% dos sistemas na internet, devido à flexibilidade e à facilidade de personalização que apresenta. A captura de credenciais ocorre em um formulário em HTML e a verificação é efetuada no lado do servidor. Políticas de senhas fortes e controles adicionais de segurança podem ser desenvolvidos da maneira que se queira, bastando que sejam codificadas pela aplicação ou suportadas pelo arcabouço de autenticação empregado.
Atualmente, é comum que uma única pessoa tenha contas em dezenas de sites web, que vão de aplicações de correio eletrônico a sistemas de internet banking. Uma prática de segurança importante é que sejam utilizadas senhas diferentes e fortes para cada uma das contas, mas isso dificulta que o usuário memorize todas elas. Para resolver esse problema, os navegadores web modernos e suítes de proteção de computadores pessoais apresentam funcionalidades para armazenamento seguro de senhas, por meio de uma senha mestra. Embora alguns riscos de segurança pairem sobre essas soluções, ainda é uma abordagem muito melhor que a escrita das senhas em um pedaço de papel ou o armazenamento em arquivo não cifrado.
q
Outro problema decorrente das soluções baseadas em senhas é que elas podem ser capturadas por software malicioso (keylogger) enquanto são digitadas em máquinas infectadas. Isso levou muitas empresas a adotarem teclados virtuais, como o ilustrado na Figura 3.1(a), que permitem que o usuário clique nos caracteres que compõem a senha escolhida, anulando a ameaça de interceptação. A resposta criminosa foi a criação de screenloggers, capazes de gravar regiões da tela ao redor do ponto clicado com o mouse, bem como as coordenadas dessa posição. Um novo avanço foi necessário e, hoje, alguns teclados virtuais permutam as posições dos elementos, aleatoriamente, antes de apresentá-los, e escondem o símbolo de uma tecla, quando o mouse passa por cima dela – vide Figura 3.1(b).
Aplicações de internet banking e sistemas que requerem um alto grau de segurança adotam, frequentemente, tokens como um segundo fator de autenticação.
A forma mais simples consiste em uma cartela contendo cerca de cinquenta senhas de quatro dígitos geradas aleatoriamente para cada usuário e numeradas sequencialmente –
NTLM
Antiga suíte de protocolos de segurança, desenvolvida pela Microsoft para uso em redes Windows, com o objetivo de prover autenticação, sigilo e integridade. Como não suporta algoritmos criptográficos modernos, não deve ser empregada em novas implementações, segundo recomendação do próprio fornecedor.
Saiba mais
Kerberos é um proto- colo de autenticação de entidades, para aplicações cliente/ser- vidor, criado pelo Mas- sachusetts Institute of Technology (MIT). Uti- liza uma terceira parte confiável e criptografia simétrica, para corro- borar as identidades das partes envolvidas e, ao mesmo tempo, estabelecer uma chave, para proteção do canal de comunicação.Te st e d e I nv as ão d e A pl ic aç õe s W eb
vide Figura 3.2(a). Quando uma transação crítica, como transferência de fundos, é requisi- tada, a aplicação solicita que uma senha específica da cartela e a senha geral sejam fornecidas. Se o usuário não possui a cartela correta, a chance de acerto é de uma em dez mil possibilidades, o que é razoavelmente seguro, quando o travamento de contas é utilizado. O problema, porém, reside no fato de que adivinhação de senhas não é o caminho adotado pelos criminosos. O que normalmente eles fazem é induzir o usuário, por meio de engenharia social, a acessar uma página falsificada e fornecer todas as posições da tabela, sob pretexto de um problema ter ocorrido na base da aplicação. Infelizmente, ainda hoje, muitas pessoas são susceptíveis a esse tipo de ataque!
(a) (b)
q
Considerando o ataque acima, uma tecnologia mais eficaz, porém mais custosa, compre- ende dispositivos de geração de senhas dinâmicas, as quais podem ser usadas apenas uma única vez pelo usuário. Desse modo, a captura delas torna-se uma ameaça irrele- vante, pois não é possível reutilizá-las para autenticação, por serem descartáveis. Porém, como em toda solução baseada em token, um problema surge quando a pessoa perde ou danifica o equipamento, porque ela será impedida de utilizar a aplicação, até que aquele seja substituído. De modo geral, esses dispositivos apresentam um visor de LCD (Figura 3.2(b)), no qual a senha é exibida, e, eventualmente, um teclado numérico para entrada de senha pessoal e desafios. Para que o usuário possa ser validado corretamente, os tokens precisam estar sincronizados com o servidor de autenticação da aplicação, o que é realizado de acordo com a classe a que pertencem (Harris, 2008):
1Síncronos: a senha é gerada a partir de uma semente secreta e individualizada e
de uma informação, como o horário ou um contador, as quais são compartilhadas entre o servidor de autenticação e o dispositivo. No primeiro caso, a senha é alterada depois de transcorrido um intervalo de tempo pré-determinado, enquanto que, no segundo, o usuário precisa apertar um botão para avançar para o próximo valor.
1Assíncronos: essa classe de dispositivos é baseada no seguinte protocolo de
desafio-resposta: o servidor de autenticação gera um número aleatório, que é exibido ao usuário pela aplicação. Este digita o valor no token, juntamente com a senha pessoal, e a senha resultante é calculada e exibida no visor de LCD. Para encerrar a autenticação, o valor correto deve ser fornecido à aplicação, que com- pleta a operação solicitada, somente caso a validação seja realizada com sucesso. Outra solução interessante envolvendo tokens consiste no envio, quando necessário, de informações de autenticação ao aparelho celular cadastrado para o usuário.
Por exemplo, ao receber uma requisição de operação crítica, a aplicação gera um número aleatório de confirmação e o envia, por meio de SMS, ao telefone do cliente, que deve digitá-lo em campo específico do sistema. Para atacar uma solução assim, é necessário, além de obter as credenciais válidas de um usuário, adivinhar o valor de confirmação gerado pelo
Figura 3.1
Teclados virtuais: (a) Tradicional. (b) Com proteção contra screenlogger.
Ca pí tu lo 3 - T es te d o m ec an is m o d e a ut en tic aç ão
servidor ou ter acesso ao celular da vítima. Um problema dessa tecnologia, porém, é que não há garantia de entrega de mensagens SMS, o que pode impedir a concretização de uma transação, se o valor de confirmação não for recebido a tempo.
(a) (b)
Embora soluções baseadas em smart cards e tokens criptográficos estejam disponíveis há um bom tempo (Hamman et al., 2001), não é fácil encontrar aplicações web que as utilizem, devido ao alto custo de implantação e dificuldade de operacionalização. Apesar disso, há um exemplo de uso dessas tecnologias no cenário brasileiro, o site da Receita Federal, que permite realizar a autenticação do usuário por meio do e-CPF (vide Figura 3.3).
q
O princípio básico da autenticação por token criptográfico consiste no protocolo de desafio-resposta ilustrado, de maneira simplificada, na Figura 3.4:
1. O usuário solicita à aplicação a realização de uma operação crítica.
2. Como resposta, o servidor envia um número aleatório (desafio) ao cliente, que deve ser assinado digitalmente com a chave privada contida no token.
3. O lado cliente da aplicação solicita ao usuário a senha do smart card.
4. Usuário fornece à aplicação a senha de acesso ao smart card.
5. A senha é enviada ao smart card, para autenticação do usuário.
Figura 3.2
Tokens: (a) Cartela de senhas. (b) Dispositivo síncrono de senhas dinâmicas baseado em horário. Figura 3.3 Aplicação da Receita Federal, que permite acesso via e-CPF.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
q
6. A aplicação cliente fornece o desafio para o smart card, para geração de assinatura.
7. O smart card assina o desafio e o devolve à aplicação cliente.
8. O desafio assinado é enviado ao servidor, para verificação por meio da chave pública cadastrada do usuário. Caso uma resposta positiva seja obtida, é possível corroborar a identidade do usuário, pois somente ele, que detém o smart card e conhece a senha de acesso, é capaz de gerar uma assinatura digital válida.
(1) Operação crítica (2) Desafio (3) Solicita senha (4) Senha (5) Senha (6) Desafio
(7) Desafio assinado (8) Desafio assinado
Usuário
Smart card Aplicação - lado cliente Aplicação - lado servidor
Alternativamente, é possível calcular um MAC sobre o desafio, em vez de uma assinatura digital, empregando uma chave simétrica armazenada no dispositivo criptográfico e compar- tilhada com a aplicação. Qual dos mecanismos escolher depende do tipo de smart card utili- zado, que pode suportar apenas criptografia simétrica ou, também, algoritmos assimétricos. Conforme visto, uma ameaça contra sistemas baseados em senhas consiste na captura destas por meio de softwares maliciosos instalados na máquina do usuário. Embora isso também possa acontecer no caso das senhas de acesso às chaves criptográficas, como elas nunca deixam o dispositivo criptográfico, é preciso roubá-lo, para executar um ataque efetivo contra a aplicação. Outro cenário hipotético, mas factível se o token fica conectado ao ambiente o tempo inteiro, é utilizar o próprio malware que captura a senha para rea- lizar transações fraudulentas em nome da vítima. Nesse caso, o dispositivo criptográfico é tratado como um oráculo, que responde a todas as perguntas que lhe são direcionadas.
q
Outro método possível de corroborar a identidade do usuário, porém, pouco presente em aplicações web, emprega o próprio protocolo SSL/TLS, que permite autenticação mútua de entidades. Isso requer que um certificado digital de usuário e a chave privada correspondente, normalmente, em formato Public-Key Cryptography Standards #12 (PCKS #12), sejam inseridos no navegador web.
Quando o usuário acessar uma aplicação que requeira o uso de certificado de cliente, o navegador abre uma janela solicitando que um par de chaves seja escolhido (vide Figura 3.5). Caso o servidor consiga validar o certificado apresentado, a negociação SSL/TLS é com- pletada com sucesso, e acesso a regiões protegidas da aplicação é concedido ao usuário. As seguintes dificuldades, pelo menos, podem ser enumeradas para a autenticação de usuário baseada no protocolo SSL/TLS:
1Dificuldade de implantação: cada usuário da aplicação precisa obter um certificado de uma autoridade certificadora válida ou então a entidade dona da aplicação necessita criar e manter infraestrutura de chaves públicas própria. Qualquer uma das abordagens gera um custo financeiro e/ou operacional, que, muitas vezes, pode ser proibitivo.
Figura 3.4
Autenticação de usuário com smart card.
PKCS #12
Padrão criado pelo RSA Laboratories, para o armazenamento e transferência seguros de chaves privadas e outras informações sigilosas de identificação.
Ca pí tu lo 3 - T es te d o m ec an is m o d e a ut en tic aç ão
1Proteção da chave privada de usuário: de modo geral, os navegadores web somente pedem a senha do arquivo PKCS #12, contendo a chave privada, no momento de impor- tação. Após isso, qualquer pessoa que tenha acesso à máquina é capaz de se autenticar na aplicação, selecionando o par de chaves adequado.
1Controle de acesso: os privilégios de acesso são concedidos com base em configurações no servidor web, que especifica os recursos da aplicação que cada usuário pode acessar, de acordo com o nome contido no certificado. Fica claro que gerenciar os privilégios em um ambiente assim não é nada prático, pois cada alteração requer que o servidor seja reiniciado, para que as novas configurações tornem-se ativas.
q
A última tecnologia de autenticação a ser abordada é a baseada em biometria, cujas vertentes mais simples de serem utilizadas em ambientes genéricos são as de reconheci- mento de face e de locutor.
A razão disso é que, atualmente, a grande maioria de computadores pessoais e portáteis possui câmera e microfone instalados, descartando a necessidade de se adquirir equi- pamento caro e especializado. Esse tipo de solução requer, como no caso de dispositivos criptográficos, que um módulo no lado cliente, escrito em Java ou ActiveX, por exemplo, seja carregado e executado pelo navegador web, para controle do dispositivo de captura de dados biométricos.
Diversos fatores impedem uma adoção em massa de biometria:
1O processo de registro de usuário não é simples e requer que diversas amostras sejam coletadas em dois tipos de ambiente: naturais e controlados. Para aplicações web de pro- pósito geral, isso é extremamente complicado de ser realizado, pois o usuário se registra a partir do próprio computador pessoal, sem interagir fisicamente com a empresa que oferece o serviço.
1Métodos biométricos precisam ser regulados para balancear as taxas de falsos positivos e falsos negativos. Este último mede a proporção de usuários válidos que não são auten- ticados pelo sistema, enquanto que o primeiro avalia a taxa de pessoas, eventualmente atacantes, que são incorretamente autenticadas como outras.
Figura 3.5
Tela do Firefox solicitando escolha de certificado para acesso à apli-
Te st e d e I nv as ão d e A pl ic aç õe s W eb
1Diversos métodos de ataque foram descritos na literatura para comprometer autenti- cação biométrica (Duc e Mihn, 2009; Uludag e Jain, 2004) e as principais estratégias de mitigação requerem o uso de tecnologia especial ou ferem a usabilidade do sistema.
Exercício de nivelamento 2 e
Vulnerabilidades
Que tipos de vulnerabilidades podem ser encontrados em mecanismos de autenticação?
Descoberta de vulnerabilidades e exploração
q
Um exemplo de vulnerabilidade em mecanismos de autenticação, que afeta diversas aplicações web, consiste na submissão de credenciais de acesso, por meio do protocolo HTTP, o qual não protege a confidencialidade do canal.
Consequentemente, essas informações podem ser facilmente capturadas, no caminho até o servidor, e utilizadas por um atacante para autenticar-se no sistema. Para ratificar esta constatação, considere-se que, até bem pouco tempo atrás, diversos sítios de correio eletrônico funcionavam dessa maneira. Felizmente, isso melhorou muito, hoje em dia, mas são poucos os que protegem a sessão inteira por meio do protocolo HTTPS, deixando, ainda, uma brecha para ataques de sequestro de sessão.
q
Outra técnica que pode ser empregada para quebrar o mecanismo de autenticação é o ataque por força bruta, que consiste em testar todas as senhas possíveis para um con- junto de identificadores de usuário.
O ponto de partida depende da enumeração de alguns usuários da aplicação, o que pode ser facilitado pelo uso de identificadores previsíveis, contas pré-instaladas ou mensagens de erro detalhadas. Adicionalmente, para o sucesso da exploração, a aplicação precisa ser incapaz de travar contas, após múltiplas tentativas inválidas e sucessivas de autenticação, além de não implementar uma política de senhas fortes.
q
Cuidados devem ser tomados para evitar que o mecanismo de autenticação seja evadido. Um deslize comum, nesse sentido, é criar uma página de autenticação que, em caso de sucesso, redireciona o usuário para áreas protegidas da aplicação, mas sem impedir o acesso direto a essas páginas.
Nessa mesma linha, algumas aplicações podem ser enganadas pela simples manipulação de parâmetros. Por exemplo, um atacante pode, simplesmente, trocar o valor de um campo escondido, que indica se um usuário está autenticado, de “não” para “sim”. Ademais, se o trecho de código que trata a autenticação contiver erros lógicos, muito provavelmente não serão necessárias credenciais válidas para acesso à aplicação.
q
Mecanismos de recuperação e troca de senhas podem, muitas vezes, ser um caminho para acesso não autorizado à aplicação.
Alguns erros que devem ser evitados no primeiro caso compreendem: utilização de per- guntas secretas com respostas fáceis de serem adivinhadas; inexistência de mecanismo de travamento por tentativas inválidas; e exibição da senha atual, caso o usuário responda cor- retamente às perguntas secretas. Já com relação à troca de senhas, ataques são possíveis quando a senha antiga não é solicitada, antes da realização da operação.
Ca pí tu lo 3 - T es te d o m ec an is m o d e a ut en tic aç ão
q
Para finalizar, é importante mencionar que o principal problema com a autenticação de usuário não é de origem técnica, mas sim de natureza humana.