Coluna do Kurt
COLUNA
Acesso permitido
Terceirizar a autenticação oferece acesso a mais
serviços – por um preço. Vamos examinar os
prós e contras da autenticação distribuída.
N
o mês passado, falamos sobre o gerenciamento de senhas. Ainda aprofundando este tema,
surge a pergunta: o que os administradores de
servidores e sistemas podem fazer para facilitar a vida
dos usuários e deles mesmos? Uma solução óbvia à proliferação de nomes de usuários e senhas é permitir de
alguma forma um único acesso de uma conta a múltiplos serviços. Tradicionalmente, este processo era feito
com serviços de autenticação federados, como LDAP,
Kerberos e assim por diante. Esta técnica funciona bem
para organizações específicas, mas é improvável que
sites deem a qualquer pessoa a possibilidade de criar e
utilizar contas aleatoriamente.
OpenID
Hoje em dia, o OpenID parece ser a única possibilidade
segura e viável para fornecer autenticação distribuída,
mas mesmo nele, muita coisa mudou. Por exemplo, o
suporte é muito melhor e é incluído por padrão em várias distribuições Linux, além de beneficiar-se de vários
anos de uso operacional, o que auxiliou no aperfeiçoamento da ferramenta.
Terceirizar a autenticação
Uma das maiores vantagens da terceirização da autenticação é a possibilidade de escolher um provedor que
consiga oferecer os serviços que você não consegue. A
autenticação com dois fatores, por exemplo, requer outros servidores, licenciamento de softwares e também
a aquisição e transporte de dispositivos de hardware
Figura 1Link de login OpenID no MediaWiki.
16
para os clientes. Vários provedores OpenID suportam
a autenticação de dois fatores, permitindo pegar uma
carona em seus sistemas. Com essa técnica, é possível
reduzir a quantidade de informações sensíveis que é
preciso armazenar e gerenciar. Além disso, um ataque
de SQL Injection (injeção de scripts SQL maliciosos
em um sistema) contra seu serviço de autenticação é
muito menos problemático quando não há hashes de
senhas para roubar e quebrar.
Além disso, é possível manter seu próprio gerenciamento e verificações de identidades internamente. Por exemplo, é possível permitir que os usuários
usem um OpenID para fazer login e depois mapeá-los
a uma conta interna com seu nome real e assim por
diante. Terceirizar o gerenciamento da autenticação
não significa abrir mão das suas próprias verificações
e considerações.
Uma grande desvantagem de terceirizar a autenticação é o fato da perda do controle do que acontece por
trás do sistema de autenticação. Um provedor pode usar
uma função de hash fraca para armazenar as senhas
(por exemplo, MD5) ou pode ter outros problemas (por
exemplo, vulnerabilidades à injeção SQL) dentro de seu
site. Um exemplo disso é o clássico ataque de tempo,
descoberto em uma versão antiga de uma biblioteca
do OpenID. Usando esse ataque, um agressor poderia
adivinhar senhas uma letra de cada vez, verificando o
primeiro caractere em busca de a a z, A a Z etc., partindo depois para o segundo caractere, e assim por diante.
Desta forma, até uma senha com 20 caracteres levaria
apenas alguns poucos milhares de tentativas para ser
descoberta (em vez de 100 elevado a 20, supondo a-z,
A-Z, 0-9 etc.).
As bibliotecas dos protocolos mais antigos, como
LDAP e Kerberos, geralmente já corrigiram tais pro-
www.linuxmagazine.com.br
Kurt | COLUNA
blemas, possuindo menos vulnerabilidades desconhecidas do que protocolos como o OpenID. Outro
problema de fontes externas de autenticação é estabelecer um caminho seguro entre você e ela. Alguns
provedores de OpenID não usam HTTPS, então a
requisição inicial pode ser suscetível a ataques do
tipo man-in-the-middle – embora proteções embutidas possam ajudar.
Essa necessidade de autenticação externa também
significa que seus servidores web precisarão fazer requisições externas para outros sites. Portanto, será preciso
criar portas de saída em seu firewall, e você deve usar
um proxy para o tráfego web de saída (para conseguir
logá-lo) ou usar um sistema IDS para encontrar ataques na saída.
Significado de um nome
Outra questão dos sistemas de autenticação distribuída como o OpenID diz respeito a namespace. Por
exemplo, o kurtseifried no WordPress sou eu, mas o
kurtseifried no Yahoo! não sou eu. Então, quando você
usa nomes de contas OpenID, também é preciso usar
Linux Magazine #75 | Fevereiro de 2011
a porção do nome fornecida pelo provedor, caso contrário haverá conflitos.
Alternativamente, é possível usar a conta OpenID
com fins de autenticação e depois mapeá-la para uma
conta local. Esta técnica tem ainda a vantagem de não
permitir que um agressor insira caracteres estranhos no
nome de usuário ou domínio do nome da conta, o que
poderia causar problemas no futuro (por exemplo, ataques de injeção SQL ou estouros de buffer).
Conexão ao OpenID
Então, como plugar o OpenID a um aplicativo
web? O MediaWiki é um ótimo exemplo, pois é
comum querer que as pessoas façam login antes de
editar documentos, para minimizar o vandalismo
ou simplesmente rastrear quem mudou o quê. Para
começar, será preciso suporte ao OpenID no PHP
(linguagem do MediaWiki e da maioria de suas extensões). Para isso, você pode usar o OpenID Enabled
[1], disponível como pacote no Debian, o Fedora e
em várias outras distribuições Linux importantes, ou
você pode obter os fontes e instalá-los manualmente.
17
COLUNA | Kurt
Quadro 1: Quebras de senhas
Como questão de política, a maioria dos sites agora fazem verificação de senhas usando uma função de sentido único; portanto, se um agressor roubar o arquivo de
senha, não conseguirá descobri-las.
Esta teoria, no entanto, tem alguns problemas: GPU e
armazenamento barato. GPUs como a Tesla da NVIDIA
(que agora está disponível para aluguel na Amazon EC2)
possuem várias centenas de núcleos que, apesar de
não serem bons para computação de propósito geral,
são ideais para tarefas altamente paralelizáveis, como
quebra de senhas. Se você adicionar armazenamento
barato a esta mistura, o agressor poderá gerar enormes
listas de senhas criptografadas. Existem vários sites [8]
de busca MD5 que permitem fornecer um hash MD5,
esperar alguns segundos e receber uma entrada que
gerará a senha.
Então, ao escolher um algoritmo de hash, lembre-se de
que os mais velhos (como o MD5) e os mais rápidos
(como o SHA1) não são exatamente os ideais.
Note que, no Fedora, o pacote se chama php-pearAuth-OpenID.noarch.
Após o pacote ser instalado, será necessária a extensão MediaWiki OpenID [2], também disponível como
pacote no Debian, Fedora (chamada media-wiki-openid.
noarch), e assim por diante. Ativar a extensão do MediaWiki é trivial; basta inserir a seguinte linha de include no
seu arquivo LocalSettings.php: require_once(“extensions/
OpenID/OpenID.setup.php”);.
Em seguida, é possível criar outra tabela (usando o
script openid_table.sql) no banco de dados do MediaWiki, que será usada para mapear as contas do OpenID
aos nomes de usuários locais. Note que nem todos os
nomes de usuários OpenID são compatíveis com as
exigências de contas do MediaWiki. Depois, você pode
clicar no link para fazer login e definir seu nome de
usuário local no MediaWiki.
Há amplo suporte ao OpenID em outras linguagens
de programação, como listas de bibliotecas que podem
ser conferidas em [3].
Serviços OpenID
Usar o OpenID é muito fácil, mas e se você quiser
fornecer serviços OpenID para que seus usuários se
beneficiem de uma conta única para múltiplos serviços? Vários provedores de hospedagem, como o Google, agora oferecem suporte a OpenID para usuários
de empresas e estudantes, mas, infelizmente, não para
a versão gratuita do Google Apps para domínios particulares. Se você possui uma conta no Yahoo!, pode
18
ir para o endereço [4] para ativar o uso de OpenID
com sua conta (o melhor a fazer é digitar no Google
o nome do seu provedor + OpenID). Para criar seu
próprio servidor OpenID, não existem tantas alternativas assim [5].
OAuth e PAPE
Talvez você ainda não tenha ouvido falar do OAuth
[6] ou do PAPE [7] – eu também não tinha. O OAuth
oferece uma camada de interface entre o OpenID e
a autenticação dos serviços. Com isso, é possível, por
exemplo, dar acesso a fotos hospedadas em um site de
compartilhamento de fotos em algum local protegido
sem precisar informar seu nome de usuário e senha ao
aplicativo. Basicamente, o OAuth oferece uma forma
fácil de interagir com servidores OpenID de forma
transparente aos usuários.
O PAPE é a OpenID Provider Authentication Policy Extension, uma forma sofisticada de dizer que um
site que usa o OpenID também pode definir regras
como “somente permitir que contas do OpenID tenham autenticação de dois fatores usando um token
físico”. Esta possibilidade reduz a probabilidade de
uma conta comprometida conseguir acessar seu serviço (quadro 1). n
Mais informações
[1]OpenID Enabled:
http://www.janrain.com/openid-enabled
[2]Extensão OpenID do MediaWiki:
http://www.mediawiki.org/wiki/Extension:OpenID
[3]Bibliotecas OpenID: http://wiki.openid.net/
w/page/12995176/Libraries
[4]OpenID no Yahoo!: http://openid.yahoo.com/
[5]Seu próprio servidor de identidade:
http://wiki.openid.net/w/page/12995226/
Run-you-own-identity-server
[6]OAuth: http://oauth.net/
[7]PAPE: http://openid.net/specs/openidprovider-authentication-policyextension-1_0.html
[8]Lookup reverso de hash MD5:
http://tools.benramsey.com/md5/
Kurt Seifried é consultor de segurança da informação especializado em
redes e Linux desde 1996. Ele frequentemente se pergunta como a tecnologia
funciona em grande escala mas costuma falhar em pequena escala.
www.linuxmagazine.com.br