Capitolul 9

OpenID

9.1 Prezentare generală

OpenID este un standard de comunicare pentru conexiunile individuale la Internet care
a câştigat o mare popularitate ı̂n ultima vreme, mai ales datorită utilizării sale free.
Primul protocol OpenID a fost dezvoltat ı̂n 2005 de Brad Fitzpatrick. Intenţia era
de a minimiza efortul utilizatorilor de a trece prin procesele (uneori descurajante) de
ı̂nregistrare pe diverse site-uri, bloguri, reţele de socializare. Datorită metodei unice de
accesare a unei palete largi de site-uri, protocolul a devenit popular foarte rapid. Cum
toate conturile Google, Yahoo, Facebook, AOL suportă OpenID, sunt mari şanse ca un
utilizator (mediu) ales arbitrar să deţină deja un ”OpenID enabled login”;
Ultima versiune (2.0) de autentificare OpenID Authentication ([18]), cu facilităţi
sporite, a apărut ı̂n decembrie 2007, derivată dintr-o versiune ı̂mbunătăţită a variantei
inţiale a lui Fitzpatrick.
Scopul principal al protocolului OpenID a fost simplificarea autentificării pe site-uri
web, bloguri, reţele de discuţii etc. El nu a fost realizat pentru aplicaţii de ı̂ncredere cum
ar fi protocoalele bancare sau notariale. Cerinţa de a asigura doar că un utilizator să fie
cel care pretinde că este, reprezintă un nivel de securitate scăzut.
În general, OpenId este un protocol open care permite unui utilizator (Bob) să foloseas-
că un U RL ca o identitate care ı̂l reprezintă pentru a accesa site-uri multiple (care suportă
acest protocol). Aplicaţiile Web pot folosi identitatea U RL pentru autentificare, autor-
izare sau alte scopuri. Bob, ca proprietar al identităţii, are control complet şi poate decide
asupra informaţiei pe care trebuie să o ofere ı̂n procesul de autentificare (pentru o aplicaţie
sau un site web). Printre altele, OpenId permite lui Bob:
• Conectarea la o aplicaţie sau site web fără a introduce informaţii de autentificare
de tip ”username” şi ”password”.
• Să selecteze informaţia care poate fi trimisă unui site web ı̂n procesul de autentifi-
care/autorizare.

1
2 CAPITOLUL 9. OPENID

• Să aleagă seturile de informaţie (numite ”profiluri” sau ”carduri”) care pot fi trimise
site-urilor web, ı̂n funcţie de nivelul de solicitare şi risc.
• Implementarea autorizării graduate şi bazate pe risc.
• Implementarea unei semnături unice pentru aplicaţii multiple.
• Integrarea de aplicaţii ı̂ntr-un sistem OpenId unitar, folosind mecanisme simple.
• Un cost redus de implementare şi maintenanţă.
OpenID nu este unic prin scopul propus sau metodele folosite. Există şi alte specificaţii
simple de autentificare a utilizatorilor, cu aproximativ aceleaşi scopuri; cel mai utilizat
este probabil SAML Web Browser Single Sign On. Principala diferenţă este aceea că
SAM L solicită ca aplicaţiile web pentru autentificare să fie acceptate anterior de cele
două părţi, iar autentificarea este o componentă a unei construcţii mai largi. Specificaţia
SAM L a fost realizată de companii, ı̂n timp ce OpenID este un proiect coordonat public
de comunitatea Internet (oarecum similar cu P HP de la poşta electronică).
Alte specificaţii similare sunt OAuth ([17]), WS-Trust ([10]) şi Information Card ([12]).

9.2 Schema generală a unui protocol OpenID

In prezentarea modului de funcţionare al protocoalelor OpenID vor fi folosiţi o serie de
termeni specifici:
• Identitificator de asociere: U RL-ul (Uniform Resource Locator) sau XRI-ul (Ex-
tensible Resource Identifier) ales de utilizatorul Bob pentru a-şi defini identitatea.
• Relying Party (RP ): o aplicaţie Web care vrea să verifice că Bob are controlul asupra
Identificatorului de asociere.
• OpenID Provider (OP ): un server de autentificare OpenID, pe care se bazează
Relying Party ı̂n operaţia de verificare a utilizatorului.
• User Agent (U A): un program client (browser Web) folosit de Bob pentru a comu-
nica cu RP şi OP .
Să ı̂ncepem cu un exemplu:
Exemplul 9.1. Bob doreşte să se ı̂nregistreze pe aplicaţia web cryptounibuc.com (ges-
tionată de RP ). În loc de a completa un formular de ı̂nregistrare, el trimite lui RP un
URL care reprezintă identitatea sa – să spunem www.bob.com. RP poate afla apartenenţa
lui Bob la acest URL; ı̂n particular RP descoperă că proprietarul acestui URL are ca-
pacitatea de a se conecta la openid.yahoo.com (providerul OpenID – OP ) folosind ca
username 0 bobita0 .
9.2. SCHEMA GENERALĂ A UNUI PROTOCOL OP EN ID 3

RP redirecţionează pe Bob spre OP , unde i se cere să completeze parola pentru user-
name-ul 0 bobita0 . După această autentificare locală, Bob este ı̂ntrebat dacă doreşte ı̂ntr-
adevăr să folosească identitatea sa pentru *.cryptounibuc.com (realm) şi – ı̂n caz afirmativ
– să confirme atributele cerute de RP (cum ar fi numele complet şi adresa de e-mail).
Confirmarea este retrimisă de OP spre RP .
Folosind o conexiune directă, RP se asigură că identitatea locală primită este au-
tentificată de OP . Presupunând că doar proprietarul poate modifica conţinutul site-ului
www.bob.com, cryptounibuc este asigurat că Bob este de fapt proprietarul acestui URL şi
RP ı̂i va genera un cont local pe aplicaţia sa web.
Ulterior, la orice solicitare a lui Bob, RP ı̂l va loga la cryptounibuc folosind identita-
tea lui.

Pe baza acestui exemplu, să detaliem specificaţiile unui protocol OpenId ([18]). O
privire schematică este dată de Figura următoare:

 (4) ⊕
RP OP
3 -
(8)
:
6 6 (7) 6
(3)
(2) (1)
(5)
+ h
(6)
U RL  ”=” - UA 

1. U RL-ul identităţii mele;

2. Ce dovedeşte posesia acestei identităţi ?

3. Posibilitatea de logare la OP ca ”username”;

4. Stabilirea asocierilor;

5. Redirectare;

6. Autentifică Utilizatorul cu ”username”;

7. Redirectare;

8. Verificarea autentificării (XOR cu (4)).

Protocolul conţine o serie de operaţii pe care să le detaliem:

• Descoperirea identităţii Utilizatorului. RP se duce la componenta de identi-

tate a U RL-ului specificat de utilizator, pentru a găsi OP -ul solicitat. În versiunea
4 CAPITOLUL 9. OPENID

2.0 acesta poate fi un link static conţinând OP -ul şi identitatea locală sau un docu-
ment XRDS care oferă lui Bob posibilitatea de specifica mai multe OP -uri (pentru
protocoale diferite). În acest caz se face apel la Y adis1 pentru a găsi OP şi versiunea
protocolului care se va folosi.
• Stabilirea unei asocieri. Asocierea este folosită pentru a garanta că numai OP -ul
stabilit a autentificat identitatea locală a utilizatorului. Eventual, RP poate alege
să omită acest pas şi să valideze identitatea la sfârşitul execuţiei protocolului.
Între RP şi OP O este stabilită asociere formată din două componente: un Identi-
ficator de asociere (unic) şi un cod M AC pentru semnarea mesajelor. Sunt două
metode de stabilire a unei asocieri: printr-un schimb de chei Diffie-Hellman sau prin
solicitarea unui canal securizat (de exemplu SSL). Vom detalia această construtie
ı̂ntr-o secţiune ulterioară.
• Redirectare spre OP . După aflarea OP -ului ţintă şi stabilirea (opţional) unei
asocieri, RP forwardează cererea utilizatorului spre OP (via o redirectare Web).
Cererea conţine o serie de parametri (detaliaţi ı̂n secţiunea 4), cei mai importanţi
fiind identitatea, Identificatorul de asociere (dacă a fost folosit), domeniul RP care
trebuie alocat (realm) şi un U RL la RP -ul unde trebuie redirectat utilizatorul după
autentificare (return to).
• Redirectare spre RP . După ce OP a autentificat identitatea locală a lui Bob,
iar acesta a permis utilizarea identităţii sale ı̂n domeniul realm specificat, la pasul
următor OP redirectează utilizatorul spre RP , ı̂mpreună cu anumiţi parametri.
Aceştia includ Identificatorul de asociere (dacă a fost folosit), un server-time bazat
pe un nonce (pentru prevenirea atacurilor replay) şi o semnătură peste valorile unora
din parametri (cei menţionaţi sunt obligatoriu semnaţi).
Dacă a fost stabilită o asociere, atunci semnătura foloseşte codul M AC şi algoritmul
de semnătură specificate de aceasta.
• Verificarea răspunsului. Dacă nu a fost stabilită nici o asociere, atunci RP
trebuie să se asigure că răspunsul a fost generat de OP , Pentru aceasta, RP trimite
parametrii primiţi direct spre OP , iar acesta răspunde – printre altele – cu un
parametru valid care să-i certifice semnătura.

9.3 Autentificarea
Deoarece noţiunea de autentificare este esenţială ı̂n construirea unui protocol OpenId, să
reluăm o parte din paşii anteriori, detaliind acest aspect. pe forma generală.
1
Protocolul Y adis (Yet Another Distributed Identity System) a fost dezvoltat ı̂n aceeaşi comunitate
ca şi OpenID, dar fără a fi legate funcţional ı̂ntre ele. OpenID s-a numit inţial Y adis.
9.3. AUTENTIFICAREA 5

Versiunea 2.0 protocolului de autentificare ([18]) foloseşte pentru comunicaţie proto-

colul HT T P (sau HT T P S), iar mesajele sunt codificate cu U T F − 8.
1. U A −→ RP : Prezentare Identificator de asociere.
2. RP ←→ OP : [Opţional] Negocierea unei chei secrete.
3. RP −→ U A: Redirectarea U A către OP .
4. U A −→ OP : Trimiterea credenţialelor pentru autentificare.
5. OP −→ U A: Redirectarea U A spre RP .
6. U A −→ RP : Trimite decizia de autentificare semnată de OP .
7. RP ←→ OP : [Opţional] Verificarea rezultatelor autentificării (dacă s-a trecut de
pasul 2)
8. RP −→ U A: Permite sau respinge accesul la resursa protejată.
Descriere:
1. Primul pas ı̂n realizarea autentificării este – aşa cum s-a văzut – trimiterea Identi-
ficatorului utilizatorului (U RL) prin U A către RP -ul care solicită autentificarea.
2. RP şi OP stabilesc o cheie secretă ce va fi stocată de RP .
3. RP redirectează U A-ul utilizatorului către OP , pentru ca bob să se poată autentifica
direct. Metoda de autentificare poate varia, dar de obicei un furnizor OpenID (OP ) va
cere utilizatorului o parolă (sau un InfoCard) şi apoi ı̂l va ı̂ntreba dacă are ı̂ncredere ca
RP -ul să primească detaliile necesare privind identitatea sa.
4. − 5. Dacă utilizatorul nu are ı̂ncredere ı̂n RP, U A-ul său va fi redirectat către
RP cu un mesaj indicând respingerea autentificării, iar RP va refuza la rândul său să-l
autentifice pe Bob.
Dacă utilizatorul decide să aibă ı̂ncredere ı̂n RP atunci U A-ul va fi redirectat către
RP ı̂mpreună cu credenţialele sale. RP trebuie să confirme lui Bob dacă credenţialele au
venit de la OP .
Dacă RP şi OP au stabilit anterior o cheie secretă, atunci RP poate valida identi-
tatea OP -ului comparând copia cheii secrete (pe care a stocat-o) cu cea primită ı̂mpreună
cu credenţialele utilizatorului. Compararea se face ı̂n varianta 2.0 printr-o operaţie
XOR (⊕).
Acest tip de RP se numeşte stateful deoarece stochează cheia secretă ı̂ntre sesiuni,
spre deosebire de cel stateless – care trebuie să mai facă o cerere (check authentication)
pentru a se asigura că datele au venit de la OP .
6. După ce identitatea a fost verificată, autentificarea este terminată cu succes iar
utilizatorul este considerat a fi conectat la RP cu identitatea autentificată de OP . RP
va stoca identitatea utilizatorului ı̂mpreună cu alte informaţii de sesiune.
Pentru negocierea cheii secrete ı̂ntre RP şi OP (de la pasul 2):
6 CAPITOLUL 9. OPENID

1. RP −→ OP : În prima etapă se stabilesc tipurile de M AC, modurile de protejare a

sesiunii şi alţi parametri utilizaţi de protocol.

• Tipurile posibile de M AC sunt HM AC − SHA1 şi HM AC − SHA256.

• Tipurile posibile de protecţie a sesiunii sunt: fără criptare, DH − SHA1 şi
DH − SHA256.
• Criptarea nu trebuie eliminată decât dacă se asigură securitatea transportului
(prin protocolul T LS de exemplu).

2. OP −→ RP : În acest pas se primesc parametrii răspunsului:

(a) Parametri comuni (tipul sesiunii, durata);

(b) Parametri ı̂n clar (M AC(key));
(c) Parametrii Diffie-Hellman (cheia publică a OP , cheia MAC criptată cu DH);
(d) Parametri de insucces (mesaje şi coduri de eroare indicând problema apărută).

În cazul ı̂n care cheia M AC este protejată prin Diffie-Hellman ea va fi transformată
ı̂nainte de a fi trimisă ı̂n reţea astfel:

base64(H(btwoc(g xA ∗xB (mod p))) ⊕ M AC(key))

unde g, p, xA şi xB sunt parametrii Diffie-Hellman stabiliţi anterior, btwoc este o funcţie
ce primeşte ca parametru de intrare un ı̂ntreg (cu o anumită precizie) şi ı̂ntoarce cea mai
scurtă reprezentare complementară big-endian.
De asemenea trebuie respectată următoarea condiţie: ”M AC(key) trebuie să aibă
aceeaşi lungime ca rezultatul funcţiei de dispersie H: 160 biţi pentru DH − SHA1 sau
256 biţi pentru DH − SHA256”.

9.4 Tipul mesajelor din procesul de autentificare OpenId

Toate părţile implicate ı̂n procesul de autentificare comunică prin schimb de mesaje.
Formatul acestor mesaje este bine definit de protocolul OpenId 2.0, astfel că succesul
comunicării depinde de utilizarea lor corectă. Există 4 tipuri principale de mesaje ı̂n
cadrul protocolului:

1. Mesajul de asociere (associate);

2. Mesajul ”checkid immediate”;

3. Mesajul ”checkid setup”;

4. Mesajul de verificare a autentificării (check authentication).

9.4. TIPUL MESAJELOR DIN PROCESUL DE AUTENTIFICARE OP EN ID 7

Toate aceste tipuri de mesaje sunt protocoale de tip cerere/răspuns, fiecare dintre ele
putând avea diferiţi parametri. De asemenea, ı̂n funcţie de tipul mesajului, utilizatorul
Bob şi serverul OP pot apela la metode de comunicare directe sau indirecte.
În cazul celor directe, se foloseşte protocolul HT T P de tip POST, iar pentru cele indirecte
protocolul HT T P de tip GET.

9.4.1 Cererea de asociere

Acest tip de mesaj este trimis de Identificatorul de asociere (U RL) spre serverul OP
(pasul 4). Scopul principal al acestor mesaje este de a stabili o cheie secretă comună ı̂ntre
Utilizator şi OP . Utilizatorul poate trimite acest mesaj ori de câte ori este cerut de OP .
Având ı̂n vedere că cei doi parteneri comunică direct, metoda folosită din cadrul
protocolului HT T P este POST. În timp ce se iniţiază cererea de asociere, OP va trimite
odată cu ea şi o serie de parametri. Lista cu parametrii care pot fi trimişi este: openid.ns,
openid.mode, openid.assoc type, openid.session type, openid.dh modulus, openid.dh gen şi
openid.dh consumer public.

• openid.ns.
Acest parametru (opţional) defineşte versiunea protocolului folosit. Utilizarea ver-
siunii OpenId 2.0 se specifică prin valoarea ”http://specs.openid.net/auth/2.0”.
Dacă acest parametru lipseşte sau are altă valoare, atunci se foloseşte automat
versiunea 1.1 a protocolului – din motive de compatibilitate cu implementări ce
utilizează versiuni mai vechi.
• openid.mode.
Acest parametru permite destinatarului să ştie cu ce tip de mesaj are de a face. Din
acest motiv, Bob trebuie să fie prezent ı̂n cadrul tuturor mesajelor; ı̂n caz contrar
mesajul nu face parte din procesul de autentificare OpenID.
Pentru mesajul de asociere, valoarea parametrului este ”associate”.
• openid.assoc type.
Prin acest parametru, cele două părţi care comunică se pun de acord asupra algo-
ritmului folosit la semnarea mesajelor.
În momentul de faţă sunt utilizate două tipuri de algoritmi:
– HM AC − SHA1: lungimea cheii este de 160 biţi, valoarea parametrului fiind
”HM AC − SHA1” (conform RF C2104/RF C3174);
– HM AC − SHA256: lungimea cheii este de 256 biţi, valoarea parametrului
fiind ”HM AC − SHA256” (RF C2104/F IP S180 − 2).
Recomandarea este folosirea algoritmului pe 256 biţi – dacă acest lucru este posibil.
8 CAPITOLUL 9. OPENID

• openid.session type.
Prin intermediul acestui parametru se stabileşte tipul de sistem criptare folosit ı̂n
cadrul mesajului, pentru a cripta M AC-ul. Trei valori sunt valide pentru acest
parametru:
– no-encription. Valoare folosită dacă se doreşte ca M AC-ul să fie trimis necrip-
tat. Acest lucru nu este recomandat, deoarece un atacator ar putea modifica
cu uşurinţă mesajul prin metode de tip eavesdropping.
Se poate ı̂nsă utiliza această valoare dacă pentru comunicare se folosesc canale
securizate prin SSL, care asigură deja criptarea conţinutului.
– DH − SHA1. În acest caz algoritmul folosit pentru schimbul de chei este
Difie-Hellman, ı̂mpreună cu funcţia de dispersie de tip SHA − 1.
– DH − SHA256. Şi aici se foloseşte algoritmul Difie-Hellman, combinat ı̂nsă cu
funcţia de dispersie SHA pe 256 biţi.
Pentru valorile bazate pe algoritmul DH şi funcţia de dispersie SHA, M AC-ul
trebuie să aibă aceeaşi lungime cu rezultatul funcţiei de dispersie (160 biţi pentru
DH − SHA1, respectiv 256 biţi pentru DH − SHA256), precum şi cu rezultatul
algoritmului folosit pentru semnarea asocierii.
Detaliind, RP specifică un număr prim mare p şi un generator q. De asemenea, tot
el generează aleator o cheie secretă xA , iar serverul OP alege – tot aleator – o cheie
secretă xB , ambele din intervalul [1, p − 1].
Astfel, cheia secretă folosită pentru criptarea M AC-ului va fi
g xA ∗xB (mod p) = (g xA )xB (mod p) = (g xB )xA (mod p)

• Parametrii openid.dh modulus, openid.dh gen şi openid.dh consumer public.

Dacă pentru tipul asocierii s-a ales una din cele două variante bazate pe algoritmul
Difie-Hillman şi pe una din funcţiile de dispersie SHA, aceşti trei parametri trebuie
să fie prezenţi.
Valoarea lui openid.dh modulus reţine numărul prim p (modulul) şi trebuie să fie ı̂n
forma base64 (btwoc(p)). Valoarea default a acestuia – ı̂n hexazecimal – este:
DCF 93A0B883972EC0E19989AC5A2CE310E1D37717E8D9571BB7
623731866E61EF 75A2E27898B057F 9891C2E27A639C3F 29B608
14581CD3B2CA3986D2683705577D45C2E7E52DC81C7A171876E
5CEA74B1448BF DF AF 18828EF D2519F 14E45E3826634AF 1949E5
B535CC829A483B8A76223E5D490A257F 05BDF F 16F 2F B22C583AB
Valoarea lui openid.dh gen reţine numărul ales g şi trebuie să fie tot ı̂n forma
base64 (btwoc(g)), iar valoarea sa default este g = 2.
openid.dh consumer public are ca valoare base64 (btwoc(g xA (mod p))).
9.4. TIPUL MESAJELOR DIN PROCESUL DE AUTENTIFICARE OP EN ID 9

9.4.2 Răspunsul la cererea de asociere

Mesajul de răspuns la cererea de asociere este trimis de OP spre U A (site-ul care a iniţiat
cererea). Codul HT T P pentru răspuns este 200 şi poate reprezenta succesul sau eşecul
asocierii.
În cazul succesului, răspunsul va conţine un token valid şi intervalul (ı̂n secunde) de
validitate; altfel va fi returnat un mesaj de eroare.
Parametrii ce trebuie să facă parte din răspuns (pentru ca asocierea să reuşească) sunt:
openid.ns, openid.assoc handle, openid.session type, openid.assoc type, openid.expires in,
openid.mac key, openid.dh server public, openid.enc mac key.

• openid.assoc handle
Este folosit ı̂n mesajele ulterioare, pentru a identifica asocierea deja reuşită. Va-
loarea este un şir de cel mult 255 caractere ASCII, având coduri ı̂n intervalul
[33, 126].
De asemenea, acest parametru este folosit şi pentru a identifica ce cheie va fi
(re)folosită pentru criptare/decriptare.

• openid.session type.
Pentru ca asocierea să fie acceptată, valoarea acestui parametru trebuie să fie aceeaşi
ca cea primită la trimiterea cererii. În cazul ı̂n care utilizatorul propune pentru
acesta folosirea unui algoritm pe care serverul nu-l are, valoarea lui va fi de tip
”răspuns nereuşit”, iar asocierea va pica.

• openid.assoc type.
Similar situaţiei anterioare, şi valoarea acestui parametru de răspuns trebuie să fie
identică cu cea primită ca lerere. În caz contrar, asocierea va pica, iar valoarea
parametrului va fi de tip ”răspuns nereuşit”.

• openid.expires in.
Reprezintă perioada de timp – ı̂n secunde – cât este valabilă asocierea. După expi-
rarea ei, aplicaţia nu va mai lua ı̂n considerare asocierea.

• openid.mac key.
Acest parametru se foloseşte doar dacă ı̂n timpul cererii s-a optat pentru tipul
sesiunii fără criptare. Valoarea trebuie să fie ı̂n format base64.

• openid.dh server public.

Reprezintă cheia publică a serverului OP . Va fi folosită ı̂n cadrul algoritmului Difie-
Hellman.
10 CAPITOLUL 9. OPENID

• openid.enc mac key.

Conţine codul MAC, criptat cu cheia secretă Difie-Hellman.
Funcţia de dispersie este fie SHA1, fie SHA256, ı̂n funcţie de cum s-a stabilit ı̂n
timpul sesiunii.

9.4.3 Cererile de tip checkid setup şi checkid immediate

Aceste două mesaje sunt folosite pentru a primi informaţii de la OP . Trimiterea mesajelor
se face de către U RL, comunicarea fiind de tip indirect – deci se utilizează protocolul
HT T P de tip GET.
Există totuşi o diferenţă ı̂ntre cele două cereri. Mesajul checkid immediate este
folosit de utilizatorii care suportă comunicarea prin AJAX (Asynchronous JavaScript
and XML), ı̂n timp ce checkid setup este specific celorlalţi utilizatori (care nu suportă
AJAX).
În ambele situaţii sunt folosiţi parametrii openid.ns, openid.mode, openid.claimed id,
openid.identity, openid.assoc handle, openid.return to, openid.realm.

• openid.mode.
Valorile posibile sunt ”checkid immediate” şi ”checkid setup”. Dacă Identificatorul
de asociere doreşte ca utilizatorii să poată interacţiona cu OP , valoarea folosită este
”checkid setup”.
În general, interacţiunea ı̂ntre Bob şi OP nu este dorită ı̂n cazul comunicării asin-
crone.

• openid.claimed id şi openid.identity.

Aceşti parametri trebuie să fie prezenţi amândoi sau nici unul. Primul conţine
valoarea identificatorului pe care utilizatorul pretinde că-l deţine – şi deci trebuie
verificat.

• openid.assoc handle.
Este un parametru opţional; prezenţa lui semnifică faptul că a fost realizată o
asociere ı̂ntre părţi şi că aceasta trebuie folosită.

• openid.return to.
După procesarea cererii, serverul OP trebuie să ı̂ntoarcă un răspuns. Dacă este
specificată o valoare pentru acest parametru (o adresă U RL), atunci browserul va
fi redirectat către această adresă, cu tot cu răspuns.

• openid.realm.
9.4. TIPUL MESAJELOR DIN PROCESUL DE AUTENTIFICARE OP EN ID 11

Prin intermediul acestui parametru se specifică domeniul site-ului cu care comunică

OP . Această valoare trebuie să existe dacă parametrul openid.return to nu a fost
specificat.

9.4.4 Răspunsul la cererile checkid setup şi checkid immediate

După ce au fost trimise cererile spre OP , acesta le analizează şi formulează un răspuns. În
funcţie de moment, serverul OP poate cere – ı̂nainte de a oferi răspunsul – autentificarea
utilizatorului, ca să fie sigur că totul este ı̂n regulă.
Ca şi ı̂n cazurile anterioare sunt definiţi o serie de parametri: openid.ns, openid.mode,
openid.op endpoint, openid.claimed id, openid.identity, openid.return to, openid.response
nonce, openid.invalidate handle, openid.assoc handle, openid.signed, openid.sig.

• openid.mode.
În cazul unei asocieri reuşite, valoarea parametrului trebuie să fie ”id res”.
Dacă – dintr-un motiv sau altul – asocierea a picat, valoarea parametrului trebuie
să fie ”setup needed” dacă cererea a fost de tip ”checkid immediate”, sau ”cancel”
ı̂n cazul cererii de tip ”checkid setup”.

• openid.op endpoint.
Valoarea acestuia este adresa serverului OP .

• openid.return to.
Copia exactă a parametrului similar primit ı̂n cazul cererii.

• openid.response nonce.
Acest parametru – unic pentru fiecare mesaj – este foarte important deoarece ajută
la blocarea atacurilor prin reluare (replay attacks). Valoarea sa este de maxim 255
caractere şi trebuie să ı̂nceapă cu data de pe serverul OP – ı̂n format U T C 2 şi
delimitat prin litera Z – urmată de caractere ASCII din intervalul [32, 126], câte
sunt necesare pentru asigura unicitatea răspunsului.

• openid.invalidate handle.
Acest parametru verifică validitatea asocierii. Dacă este setat, ı̂nseamnă că ceva a
fost ı̂n neregulă, iar utilizatorul trebuie să respingă asocierea.

• openid.assoc handle.
Conţine legătura spre asocierea cu care a fost semnat mesajul. Pe baza lui se pot
face verificări privind autenticitatea mesajelor.
2
http://www.ietf.org/rfc/rfc3339.txt - Formatul datei conform standardului U T C.
12 CAPITOLUL 9. OPENID

• openid.signed.
Conţine o listă cu parametrii care au fost semnaţi, despărţiţi prin virgulă.

• openid.sig.
Acest parametru conţine semnătura mesajului, ı̂n format base64.

9.4.5 Cererea pentru verificarea autentificării (check authentica-

tion)
Verificarea autentificării este poate pasul cel mai important ı̂n tot acest proces, deoarece
el asigură că toate mesajele sunt trimise ı̂ntr-adevăr de OP şi nu de altcineva (care
impersonează acest server). Există câteva observaţii privind acest mesaj:

1. Mesajul este trimis doar dacă nu există deja o asociere stabilită ı̂ntre utilizatorul
Bob şi OP .

2. Dacă se foloseşte o asociere deja existentă, cererea lui Bob trebuie să conţină parame-
trul ”openid.assoc handle”, iar OP va avea ı̂n răspuns aceeaşi valoare de asociere.

3. Se poate ı̂ntâmpla şi cazul ı̂n care serverul OP nu este de acord cu asocierea primită
de la utilizator; atunci răspunsul va conţine parametrul ”openid.invalidate handle”,
precum şi un alt parametru (”openid.assoc handle”) pentru a fi folosit de Bob.

9.4.6 Răspunsul la cererea de verificarea autentificării

Răspunsul serverului OP este foarte scurt, având doar trei parametri: openid.ns, openid.is
valid, openid.invalidate handle.

• openid.ns:
Identic cu cel din cererea de asociere.

• openid.is valid.
Are o valoare de tip boolean, ”true” sau ”false”, specificând dacă semnătura cererii
este validă sau nu.

• openid.invalidate handle.
Dacă parametrul openid.is valid are valoarea ”false”, acest parametru trebuie trimis
ı̂n cadrul răspunsului pentru ca utilizatorul să ştie şi să elimine asocierea respectivă
din lista celor valide.
9.5. SECURITATEA OP EN ID 13

9.5 Securitatea OpenId

O analiză a securităţii oferite de protocolul OpenId poate fi clasificată ı̂n patru categorii,
reprezentând caracteristici ale scopurilor pe care ı̂şi propune să le rezolve, ale practicilor
de implementare, ale specificaţiilor OpenID şi ale infrastructurii oferite de Web3 .

1. Semnătură unică. Scopul construirii unui protocol OpenID este accesarea de

site-uri Web diferite, folosind o singură semnătură (SSO – Single Sign On). Ideea
este că odată ce un utilizator (U A) s-a autentificat la un OP , nu va mai trebui
să repete ulterior acest protocol. Într-o implementare standard, odată ce există o
aprobare de autentificare pentru un RP , ea nu mai trebuie repetată.

2. Acces liber. O caracteristică importantă a unui OpenId este aceea că un utilizator
este capabil să-şi aleagă propria sa identitate (U RL), OP şi RP -urile. În principiu,
oricine se poate alătura structurii deja existente, implementând un OP sau ı̂ncepând
să accepte tranzactii OpenID (ca un RP ).

3. Specificaţii OpenID proprii. Anumite cerinţe dintr-o specificaţie OpenID pot

fi adăugate sau eliminate. Această faciliatte poate duce ı̂nsă la diferenţe ı̂n imple-
mentare şi – ı̂n consecinţă – la unele falii de securitate.

4. Utilizare de standarde W eb. Pentru transferul datelor lui Bob ı̂ntre RP şi OP
pot fi folosite redirectări W eb deja existente. Acest lucru uşurează cerinţele celor
trei parteneri (RP, OP şi U A), dar OpenID va moşteni toate slăbiciunile posibil
existente ı̂n aceste mecanisme de redirectare.

9.5.1 Semnătura unică

• Atacurile se direcţionează spre OP -uri. Bob foloseşte acelaşi OP pentru a se
conecta la multiple RP -uri. Dacă Oscar poate afla aceste credenţiale, el va obţine
acces la toate RP -urile, inclusiv la datele lui Bob (stocate acolo).
Credenţialele stocate ı̂ntr-un OP devin cu atât mai valoroase cu cât popularitatea
standardului OpenID creşte. Pe de-altă parte, deoarece OpenID devine de facto
un standard pentru SSO de pe Web, OP -urile trebuie să se concentreze foarte
mult pe asigurarea protecţiei datelor utilizatorilor săi, ceea ce ı̂ngreunează mult
implementarea.

• Spionarea OP -urilor. Deoarece pentru conectare se foloseşte totdeauna acelaşi

OP , acesta are posibilitatea de a conecta orice tranzacţie cu orice RP vizitat de
utilizator. El poate monitoriza frecvenţa apariţiei unei tranzacţii, momentele de
3
În literatură se pot ı̂ntâlni şi alte clasificări, dar toate sunt ı̂n final similare cu cea prezentată ı̂n acest
capitol.
14 CAPITOLUL 9. OPENID

solicitare etc. Singurul efort al OP -ului este de a se conecta la orice tranzacţie.

Folosind apoi tehnici de data mining (a se vedea [15]) se pot completa şi prelucra
datele obţinute, totul ducând la un posibil atac.
Într-un mediu fără această facilitate OpenID, acest drept ı̂l are numai browserul
Web folosit de Bob. De exemplu, browser-ul Google Chrome trimite server-elor
Google toate URL-urile vizitate de (orice) utilizator, scopul declarat fiind o ı̂mbună-
tăţire a mecanismmelor de funcţionare, dar şi pentru alte prelucrări posibile.

• Atacuri ”Cross-Site Scripting”. Prin facilitatea ca Bob să se conecteze cu OP -ul

său la orice RP fără nici o restricţie, el nu mai va avea contact cu pagina de conectare
sau cu solicitarea unui RP de a se autentifica. Acest lucru permite dezvoltarea unor
atacuri ”cross-site scripting”. Oscar poate plasa un frame ascuns pe un site Web,
ı̂ncărcând datele de conectare OpenId ale lui Bob, aflate pe un RP ţintă. După
aceea ı̂l conectează pe Bob permanent la RP , fără permisiunea acestuia. În acest
fel, Oscar poate lansa un atac XSRF (cross-site request forgery), acţionând ı̂n
numele lui Bob ([15]). Din acest motiv (aşa cum specifică solicitarea de deconectare
după terminarea vizitării unei pagini) nu se poate garanta protecţie contra atacurilor
de acest gen.
Din această categorie face parte şi atacul ”clickjacking” ([7]) unde – folosind unele
proprietăţi de vizualizare a paginilor – Bob crede că se conectează la un link (cu un
click pe numele acestuia) controlat de Oscar, conectându-se de fapt pe altă pagină
(de reclamă – ı̂n cel mai inofensiv caz).

• Sesiuni false. Intr-un astfel de atac, Oscar ı̂l păcăleşte pe Bob să viziteze replica
unei pagini despre care Bob crede că are un anume RP . El va conecta apoi automat
pe Bob la RP -ul real, dintr-un cont controlat de Oscar. Datorită ideii de semnătură
unică, se presupune că Bob a semnat conectarea din contul său ([9]).
Prin acest atac, Oscar va căuta diverse informaţii – cum ar fi de exemplu cele legate
de conturi sau carduri – depuse de Bob pe RP ı̂n convingerea că aceasta este contul
său – proprietarul real fiind de fapt Oscar.

9.5.2 Acces liber

• RP ca scaner de port. La ı̂nceputul protocolului, RP extrage identificatorul U RL
specificat de U A. Deoarece utilizatorul are libertatea de a alege orice valoare pentru
U RL, un adversar poate introduce U RL-uri cum ar fi http://www.example.com:21,
(deci – practic – un scaner proxy de port pentru RP ). El poate (ı̂n funcţie de
configuraţia RP -ului) să scaneze chiar şi locaţii interne, cum ar fi 192.168.1.45 : 3654
([15]).
9.5. SECURITATEA OP EN ID 15

Scanerul de port nu este propriu zis o slăbiciune, dar posibilitatea de a scana adrese
din zona internă a unei reţele locale a RP -ului şi faptul că această scanare poate fi
realizată automat oferă o facilitate ı̂n construcţia unui atac.

• RP pierdut ı̂n căutare. Acest atac foloseşte faptul că RP trebuie să se conecteze
la identificatorul U RL oferit de utilizator. Un cod maliţios poate folosi fişiere mari
sau fără marcaj de sfârşit ca identificatori de U RL-uri, ca prim pas pentru un atac
DoS asupra RP -ului ([15]).
Apărarea contra unei astfel de ı̂ncercări este foarte simplă: RP trebuie să efectueze
căutarea unui U RL ı̂n anumite limite de timp şi spaţiu.

9.5.3 Specificaţii OpenID proprii

• Atac Man-in-the-Middle. Protocoalele folosite pentru stabilirea de asocieri de
securitate şi trimiterea M AC-urilor corespunzătoare de la OP spre RP folosesc cu
predilecţie schimbul de chei Diffie-Hellman. Dar acesta este vulnerabil la un atac de
tip Man-in-the-Middle, ı̂n care Oscar acţionează drept OP pentru RP şi drept RP
pentru OP . Deci el va putea modifica toate datele trimise de OP spre RP , fără ca
RP să realizeze că semnătura este incorectă. În funcţie de locaţie, Oscar se poate
conecta ca utilizator U A la un RP sau, ca utilizator U A dintr-un OP la orice RP .

• Association Poisoning. În acest atac Oscar caută numele unei asocieri (the as-
sociation handle) pentru o anumită comunicare RP ←→ OP . Apoi se conectează la
RP folosind propriul său OP . Deoarece OP ı̂i permite să aleagă numele asocierii,
Oscar va alege exact numele pe care l-a găsit, ı̂nlocuind cheia M AC originală cu
una aleasă de el. Din acest moment, pentru o anumită durată de timp (până
când adevăratul OP rescrie numele asocierii), el poate semna (şi eventual modifica)
atributele trimise de OP spre RP , folosind propria semnătură. RP va considera că
mesajele trimise de OP sunt incorect semnate şi le va respinge ([3]).
Pentru a modifica datele trimise de OP spre RP , Oscar trebuie să instaleze (ca ı̂n
atacul Man-in-the-middle) un nod ı̂ntre cei doi parteneri.

• Reciclarea OpenID-lui. În timp, Bob poate renunţa la OP , lăsând lui Alice
identitatea sa locală. Dacă acest OP a fost conceput să suplinească identitatea
U RL-lui său (de exemplu, dacă s-a folosit username.myid.net sau dacă butoanele
Google/Yahoo! etc. au fost utilizate direct), aceasta ı̂nseamnă că nu numai identi-
tatea locală dar şi identitatea U RL a lui Bob este deţinută acum de Alice. Ea se
poate conecta ulterior la un RP şi afla date ale lui Bob.
Specificaţiile OpenID 2.0 recomandă o soluţie pentru această problemă, dar OP -
urile nu sunt obligate să o adopte.
16 CAPITOLUL 9. OPENID

9.5.4 Utilizarea standardelor W eb

• Phishing. Într-un astfel de atac, Bob este ispitit să viziteze un site Web imper-
sonând ecranul său de conectare din OP . Dacă el nu observă că acesta nu este
site-ul oficial al OP -lui şi-şi introduce credenţialele, acestea sunt la dispoziţia lui
Oscar ([11], [14]).
Astfel de atacuri au loc numai dacă Bob face click pe un link nesigur; dar fap-
tul că OpenID redirecţionează automat legăturile face posibilă existenţa unui atac
phishing mai puţin evident. Un RP controlat de Oscar poate pur şi simplu să-
l direcţioneze pe Bob la un OP fals, fără a genera nici o suspiciune că se face o
conectare nedorită.
Folosirea unui OpenId ridică deci riscul unui atac de tip phishing.

• Realm Spoofing. Acest atac ([11]) presupune existenţa unui RP având un XSS
(sau altă vulnerabilitate) care să permită forwardarea spre alte websituri (de exem-
plu http://www.example.com?goto=http://evil.com). Oscar crează un website care
imită acest RP şi dacă Bob ı̂ncearcă conectarea folosind OpenID, Oscar ı̂i spune că
OP cu acest domeniu aparţine unui RP oficial. Ca urmare ı̂n returul spre U RL (ul-
timul pas din schema de funcţionare) el poate abuza de posibilitatea de forwardare
(care-l returnează pe Bob spre propriu site web).
În caz de succes, OP şi Bob sunt convinşi că atributele sunt trimise spre RP -ul
oficial, ele fiind de fapt redirectate de Oscar la un RP fals (deşi OP a comparat
domeniul realm şi a făcut corect revenirea la U RL).

Categorie Vulnerabilitate Tip de atac =1 >1

Semnătură unică Totdeauna aceleaşi OP -uri Atacuri spre OP S M
OP ı̂şi urmăreşte userii M M
Conectare ne-interactivă Cross-Site Scripting R R
Sesiuni false S M
Acces liber Specifică orice identitate U RL Scaner de port RP M M
RP pierdut ı̂n căutare R R
Specificaţii Folosire chei Diffie-Hellmann Man-in-the-middle S R
OpenID proprii Specificaţii uşoare Association Poisoning M R
Reciclare OpenId -
Utilizare de RP duce U A la OP Phising R R
standarde W eb U A este ı̂n browser Clickjacking M R
Realm Spoofing - -
Tabelul prezentat sumarizează aceste slăbiciuni posibile generate de OpenId.
Ultimele două coloane dau o estimare a riscului (S- scăzut, M - mediu, R - ridicat)
pentru două scenarii: unul ı̂n care OpenID este utilizat ı̂n servicii cu nivel de securitate
egal cu 1 (standard dezvoltat ı̂n [16]), iar al doilea ı̂n care OpenID este utilizat pentru
9.6. REZOLVĂRI POSIBILE 17

servicii cu nivel de securitate ridicat. Estimările de risc sunt bazate pe o combinaţie ı̂ntre
efortul necesar atacului respectiv şi avantajul pe care ı̂l poate obţine Oscar ı̂n caz de
reuşită. Principala diferenţă dintre cele două scenarii pleacă de la prezumţia că serviciile
cu un nivel de securitate ridicat implică un câştig potenţial mai mare pentru atacator,
deci o preferinţă a atacurilor pe falia de securitate respectivă.
O analiză a tabelului duce la concluzia că un risc mediu ı̂ntr-un nivel de securitate
egal cu 1 este relativ moderat, ı̂n timp ce riscul mediu pentru serviciile cu nivel ridicat de
securitate este ridicat atunci când se foloseşte OpenId.

9.6 Rezolvări posibile

În [4] sunt trecute ı̂n revistă o serie de propuneri de rezolvare a majorităţii acestor vul-
nerabilităţi din construcţia OpenId 2.0 (propuneri care nu au fost ı̂ncă implementate).

9.6.1 Configuraţii de ı̂ncredere

Multe din probleme provin din modul liber de comunicare oferit de OpenId; deci ele se
pot rezolva prin crearea unor bariere de securitate (Trust Frameworks) ı̂ntre identităţi,
OP -uri şi RP -uri. Dacă acestea sunt protejate, orice ı̂ncercare a lui Oscar de a controla
una din ele ar fi prevenită.
Ca o consecinţă, nu va mai fi posibilă conectarea unui potenţial OpenID la orice
potenţial RP , iar utilizatorii nu vor mai putea utiliza după plac orice identitate sau OP .

9.6.2 Tehnici anti-phishing

Sunt două modalităţi de prevenire a atacurilor phishing.

• OP -ul poate adăuga elemente de personalizare – cum ar fi un icon personal – la

paginile de conectare. Aceste iconuri sunt bazate pe cookie-uri şi deci vor fi activate
numai atunci când utilizatorul vizitează un OP de la un singur browser.

• Clientul poate instala un software adiţional (ı̂ncărcat de browser) care va asista uti-
lizatorul ı̂n marcarea unor atacuri phishing potenţiale. Un astfel de software poate
include mecanisme de ajutor ı̂n verificarea certificatelor şi adreselor de domeniu
(cum ar fi apariţia barei de adrese, efect iniţiat cu prioritate de multe browsere) şi
specificaţii OpenID suplimentare (de exemplu SeatBelt [5] de la VeriSign, Sxipper
[6] şi selectori de identitate Microsoft [7]).
Unele articole propun ca soluţie BeamAuth (utilizarea de bookmark-uri), sugerată
de Adida ı̂n [2], al cărei principal avantaj este acela că nu necesită instalarea de
software suplimentar.
18 CAPITOLUL 9. OPENID

9.6.3 Prevenirea atacurilor de tip Cross-Site Scripting

RP şi OP pot lua diverse măsuri pentru contorizarea atacurilor cross-site scripting. De
exemplu, se poate folosi JavaScript pentru a asigura RP sau OP că nu este ı̂ncărcat
ı̂ntr-un frame ascuns. Altă opţiune posibilă pentru RP -uri şi OP -uri este de a solicita
o semnătură redusă (sesiunea de informare nu este folosită, dar Bob trebuie să se re-
autentifice spre OP pentru fiecare RP specific).
În plus, se pot folosi soluţiile generale construite pentru evitarea atacurilor cross-site
scripting; de exemplu se poate recomanda adăugarea de nonce-uri la fiecare interacţiune
dintre utilizator şi aplicaţia de pe RP , lucru care va preveni generarea de acţiuni generate
automat cu identitatea altui utilizator.

9.6.4 Specificaţii adaptate

Unele probleme pot fi evitate sau diminuate folosind specificaţiile OpenID 2.0 ([18]).
Probleme cum ar fi abuzul de RP (ca un scaner de port) sau atacuri DoS – prezentând
un Identificator U RL fals – pot fi evitate solicitând anumite standardizări suplimentare
ale Identificatorului U RL (de exemplu refuzul U RL-lor care conţin numere de port sau
adresări de IP -uri locale)
Altă solicitare ar fi ca RP – având un nonce ı̂n protocolul de iniţializare Utilizator
- Client, să verifice dacă acest nonce există şi la sfârşitul sesiunii (astfel se ı̂nlătură o
ı̂ncercare de Sesiune falsă).

9.7 Concluzii
Protocolul OpenID poate fi considerat sigur dacă M AC-ul şi canalul de comunicaţie
sunt considerate sigure. Totuşi securitatea depinde de metodele de autentificare folosite
de furnizorii serviciilor OpenId. Unii furnizori folosesc parole, ı̂n timp ce alţii au soluţii
mai sofisticate.
Un utilizator trebuie să poată avea ı̂ncredere ı̂n securitatea generală şi integritatea OP -
ului său. Dacă un furnizor este compromis, un intrus se poate da drept orice utilizator
al acelui furnizor, pentru orice serviciu bazat pe OpenID. Din acest motiv, este puţin
probabil ca OpenID – sau orice alt sistem similar – să fie adoptat pe scară largă ı̂n
domenii ı̂n care securitatea comunicării este esenţială (de exemplu internet banking). O
soluţie ar putea fi totuşi existenţa câtorva furnizori de servicii OpenId recunoscuţi oficial
(de exemplu modul ı̂n care sunt emise legitimaţiile electronice suedeze).
Până atunci, OpenID rămâne un instrument folosit atunci când comoditatea este mai
importantă decât siguranţa.
Bibliografie

[1] Atanasiu, A – Securitatea informaţiei, vol. 2 (Protocoale de securitate), Ed. Infodata,

Cluj (2009)

[2] Adida, B. – BeamAuth: Two-Factor Web Authentication with a Bookmark, In ACM

Conference on Computer and Communications Security, pp. 48-57 (2007)

[3] Arnott, A. – OpenID Association Spoofing. blog.nerbank.net (March 2009),

http://blog.nerdbank.net/2009/03/openid-association-poisoning.html

[4] van Delft, B., Oostdijk, M. – A Security Analysis of OpenID, de Leeuw, E, Fischer-
Hubner, Fritsch, L. (Eds.), IDMAN 2010, IFIP AICT 343, pp. 73-84 (2010), IFIP
International Federation for Information Processing 2010

[5] Diffie, W., Hellman, M.E. – New directions in Cryptography, IEEE Transactions on
Information Theory IT-22, 644-654 (1976)

[6] Drebes, L. – Relying Party Stats as of Jan 1st, 2009, JanRain Blog (January 2009),
http://blog.janrain.com/2009/01/relying-party-stats-as-of-jan-1st-2008.html

[7] Hansen,R., Grossman, J. – Clickjacking (September 2008),

http://www.sectheory.com/clickjacking.htm

[8] Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R., Maler, E.
– Profiles for the OASIS Securit Assertion Markup Language (SAML) V2.0 (March
2005), http://docs.oasis-open.org/security/saml/v2.0/

[9] Jain, A., Nash, A., Hodges, J. – OpenID Security Issues. Presentation PayPal Infor-
mation Risk Management (November 2009).

[10] Lawrence, K., Kaer, C. – WS-Trust 1.4 OASIS Editor Draft (February 2008),
http://docs.oasis-open.org/ws-sx/ws-trust/ 200802/ws-trust-1.4-ed-01.html

[11] Messina, C. – OpenID Phising Brainstorm (December 2008),

http : //wiki.openid.net, http : //wiki.openid.net/OpenID P hishing Brainstorm

19
20 BIBLIOGRAFIE

[12] Nanda, A. – Identity Selector Interoperability Profile V1.0 (2007)

[13] Sovis, P., Kohlar, F., Schwenk, J. – Security Analysis of OpenID

[14] Tom, A., Arnott, A. – OpenID Security Best Practices. openid.net (July 2009),
http://wiki.openid.net/OpenID-Security-Best-Practices

[15] Tsyrklevich, E., Tsyrklevich, V. – Single Sign-On for the Internet: A Security Story,
ı̂n BlackHat USA (2007)

[16] Office of Management and Budget (OMB). E-Authentication Guidance for Federal
Agencies, Memorandum M-04-04 (December 2003),
http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf

[17] oauth.net. OAuth Core 1.0 Revision A (June 2009), http://oauth.net/core/1.0a/

[18] openid.net. OpenID Authentication 2.0 - Final (December 2007),

http://openid.net/specs/openid-authentication-2 0.html (2009)

[19] http://dev.aol.com/OpenidTokenExchange