Sistema de Identificação
OpenID
Vanessa Marques de Assis
O Problema
Muitas senhas para lembrar
Muitos sites onde preciso inserir meus dados
Page  2
O que fazer?
 Anotar minhas senhas?
 Usar o mesmo username e senha
para todos os sites?
Page  3
A solução: OpenID
 Autenticação Única
 O usuário escolhe seu provedor
 Poucos locais com seus dados
Page  4
Protocolo
Agentes
Page  5
Protocolo
 Processo de autenticação
1. URL ou XRI único
2. Descoberta, redirecionamento e pedido de autenticação
3. Entrada de username e senha
Page  6
Protocolo
 Processo de autenticação
1. URL ou XRI único
2. Descoberta, redirecionamento e pedido de autenticação
3. Entrada de username e senha e confirmação de informações.
4. Autenticação realizada com sucesso
Page  7
Protocolo
 Autenticação Única
5. URL ou XRI único
6. Pedido de autenticação. Verificação do ID da sessão.
7. Permitir autenticação: dessa vez, sempre ou negar
8. Verificação realizada com sucesso
Page  8
Protocolo
 Processo de Descoberta
•
Protocolo XRI para a descoberta do documento XRDS
•
Protocolo Yadis para a descoberta do documento XRDS
•
Análise do documento HTML apontado pela URL
Ex.: <link rel="openid2.provider" href="http://www.exemplo.org/openid"/>
Page  9
Protocolo
 Protocolo Yadis
•
Identificador único: ID Yadis
•
Pedido HTTP
•
Resposta contém uma referência para documento XRDS
Page  10
Segurança
 Três Cenários
•
Usuário Malicioso
•
RP Malicioso
•
Provedor Malicioso
Page  11
Segurança
 Usuário Malicioso
•
Acessar host interno
Ex.: localhost/admin.php?action=sql&query=DROP TABLE user
•
Forçar acesso a host externo
Ex.: www.exemplo.com/falhadeseguranca.php?attack=true
•
Inundação e negação de serviço
Ex.: Muitos pedidos de autenticação em pouco tempo
Page  12
Segurança
 Como evitar?
•
Filtros
Não deixe o usuário inserir a URL que quiser
•
Banir excesso de pedidos de autenticação que não passam
pelo processo de descoberta
•
Banir muitos pedidos de autenticação em pouco tempo
Page  13
Segurança
 RP Malicioso
Page  14
Segurança
 Como usuário evita?
Page  15
Segurança
 Como provedor evita?
Page  16
Segurança
 Provedor Malicioso
•
Privilégios únicos
•
Pode passar-se por usuário
•
Possui informações sobre o usuário
Page  17
Segurança
 Como evitar?
•
Provedor de confiança
•
Utilização de domínio próprio
Ex.: O domínio http://vanessa.exemplo.net possui em seu HTML o trecho:
<link rel="openid2.provider" href="http://www.exemplo.org/openid"/>
<link rel="openid2.local_id" href="http://vanessa.exemplo.org"/>
Page  18
Conclusão
Solução barata e simples de implementar
Principais falhas de segurança
Popularização é um ponto positivo
Não é ideal para alguns tipos de tarefa
Page  19
Perguntas
1. Quais são os principais problemas que o protocolo OpenID
visa solucionar?
Page  20
Perguntas
1. Quais são os principais problemas que o protocolo OpenID
visa solucionar?
Com o aumento do número de serviços online, um mesmo
usuário acaba tendo diversas contas, precisando decorar muitas
senhas diferentes. E como há a necessidade da criação de uma
conta para a utilização de cada serviço, acabamos inserindo
informações pessoais em websites que por vezes não confiamos
ou conhecemos a fim de conseguir uma autenticação para
acessá-lo, o que permite que diversos locais tenham acesso a
essas informações.
Page  21
Perguntas
2. Por que a prática de utilizar um mesmo username e senha
para diversos sites não é segura?
Page  22
Perguntas
2. Por que a prática de utilizar um mesmo username e senha
para diversos sites não é segura?
Essa é uma prática pouquíssimo segura pois basta que um dos
websites em que o usuário se inscreveu seja malicioso ou tenha
sua segurança violada para que obtenham a autenticação do
usuário e, através dela, tenham acesso a outros websites onde o
usuário é cadastrado. Sendo assim, a segurança de todos os
websites utilizados pelo usuário estará sujeita àquele com menor
segurança.
Page  23
Perguntas
3. Quais são os principais agente envolvidos no protocolo OpenID?
Page  24
Perguntas
3. Quais são os principais agente envolvidos no protocolo OpenID?
Usuário: Pode ser representado pelo navegador utilizado pelo usuário
final para acessar um website (relying party) e autenticar-se utilizando
uma identidade OpenID obtida de um provedor OpenID de sua escolha
Provedor OpenID (OP): Um servidor de autenticação que fornece uma ou
mais identidades para o usuário final e valida as credenciais do usuário
para autenticação. O usuário tem liberdade para escolher um provedor
OpenID no qual confie
Relying Party (RP): O website onde o usuário deseja conectar-se,
utilizando um identificador OpenID. Esse identificador será validado pelo
provedor OpenID do usuário.
Page  25
Perguntas
4. O que é phishing e qual agente do protocolo OpenID pode
realizar esse tipo de ataque?
Page  26
Perguntas
4. O que é phishing e qual agente do protocolo OpenID pode
realizar esse tipo de ataque?
Phishing é uma forma de fraude virtual, onde o atacante faz uma
cópia de um website a fim de fazer com que o usuário acredite que
se encontra no website verdadeiro para então obter a identidade do
usuário e os dados pessoais que ele fornece ao local que ele
acredita que seja de sua confiança. No protocolo OpenID, o agente
que pode realizar esse tipo de ataque é o RP, falsificando o site do
provedor OpenID utilizado pelo usuário com o objetivo de obter seu
username e senha.
Page  27
Perguntas
5. Que medidas o usuário e o provedor podem tomar para se
prevenir de fraudes como phishing?
Page  28
Perguntas
5. Que medidas o usuário e o provedor podem tomar para se
prevenir de fraudes como phishing?
Para o usuário, uma das maneiras mais rápidas e eficazes de se
identificar o phishing é através da análise da URL. Ou seja, é
fortemente recomendado que o usuário verifique com atenção a URL
do provedor OpenID e confirme que ela de fato está de acordo com a
URL original antes de inserir os dados para sua autenticação. Se a
URL parecer suspeita, é possível que o RP esteja tentando executar
um ataque de phishing. O usuário pode também utilizar
complementos em seu navegador que realizem esse tipo de
verificação.
Já o provedor deve criar uma página de autenticação que seja fácil
para que os usuários reconheçam mas que ao mesmo tempo seja
difícil para que terceiros falsifiquem. Um exemplo apresentado é o
selo de autenticação utilizado pelo Yahoo!.
Page  29
Fim
Obrigada.
Page  30