Documentul discută despre autentificarea și autorizarea web, explicând procesele prin care se confirmă identitatea utilizatorilor și se determină nivelul de acces la resurse. Se abordează diferitele metode de autentificare, cum ar fi autentificarea tradițională și utilizarea certificatelor, precum și protocoalele OpenID și OAuth pentru identificare și autorizare. Conținutul include, de asemenea, considerații privind securitatea în gestionarea parolelor și structura protocoalelor de autentificare.

1. Autentificarea
şi
Autorizarea WEB
Cezar Derevlean
Andrei Popescu

2. Autentificarea
• Confirmarea unei entităţi şi a veridicităţii acesteia
• Poate să implice confirmarea identităţii unei persoane,
asigurarea că un produs este ceea ce susţine că este sau
asigurarea că o aplicaţie este de încredere
• În domeniul informatic procedura se mai numeşte login, logon
şi implică adesea folosirea unui user şi a unei parole

3. Autentificarea
• autentificarea depinde de secretul partajat care, cel mai
întâlnit, este sub formă de parolă
• Odată autentificat, un utilizator poate executa diverse
comenzi, sarcini, etc. în funcţie de autorizare
• Când autentificarea nu mai este necesară, utilizatorul poate
închide sesiunea (logoff, logout)

4. Autentificarea
Sistemele de autentificare oferă răspunsuri la interogări de
genul:
• Cine este utilizatorul, calculatorul, sau producătorul? Care
anume este produsul?
• Este adevărat că utlizatorul este chiar acela care pretinde a fi?
Sistemele de autentificare pot fi de mai multe tipuri:
• Simplu (nesecurizat) - unde parola este transmisă în formă
textuală în clar, fără cifrare/codificare
• Complicat (sofisticat) – ca de ex. la sistemle Kerberos

5. Autentificarea
• În domenii mai riscante, cum ar fi tranzacţiile online, utilizarea
unui user şi a unei parole nu este suficientă, caz în care pentru
autentificare ar putea fi necesare date suplimentare (cod PIN
etc.)
• În toate cazurile sistemele de autentificare depind de o
informaţie, cunoscută (disponibilă) individului care se
autentifică, precum și sistemului de autentificare – un secret
partajat.
• Autentificarea poate fi nesecurizată (tradiţională) sau
securizată

6. Autentificarea tradițională
(nesecurizată)
• Este cea mai simplă şi cea mai comună metodă de
autentificare
• Informaţiile despre un utilizator sunt stocate local pe un
server
• Utilizatorii trimit numele de utilizator și parola în clar (plain
text) sistemului, care la rândul său compară informaţia de
autentificare cu baza de date locală.

7. Autentificarea tradițională - puncte
slabe:
• În multe cazuri, parolele utilizatorilor sunt stocate în clar pe un
server. Oricine are acces la baza de date a serverului are acces
la informaţiile oricărui utilizator autentificabil.
• În cazurile în care parolele utilizatorilor sunt stocate codificat
(encrypted) pe server, parolele în clar sunt probabil trimise
prin reţele nesigure de la client la server.
• Fiecare sistem separat trebuie să deţină o copie a informaţiei
de autentificare a utilizatorului.
• Autentificarea nu este refolosibilă. Utilizatorii trebuie să se
autentifice pe fiecare sistem sau aplicaţie pe care ei doresc să
îl/o acceseze.

8. Certificate
• Funcţia principală a unui certificat este aceea de a asocia unei
identităţi o chei publică. Certificatele sunt publice și conţin
informaţie referitoare la subiectul certificatului, cheia publică
a certificatului, entitatea care a emis acest certificat și
semnatura acesteia.
• Asocierea cheie-identitate (certificatul) este recunoscută și
garantată de un terţ, entitatea care semnează certificatul și
care este numită Autoritate de Certificare.

9. Certificate
• Un certificat poate fi obţinut printr-o cerere făcută unei astfel
de Autorităţi de Certificare.
• Cel care dorește să deţină un astfel de certificat va genera
local o pereche de chei, publică si privată, va arata cheia
publică Autorităţii de Certificare care îi va creea și semna un
certificat conţinând aceea cheie publică.
• Un certificat al unui client va fi verificat pe lanţul de semnături
până ce se ajunge la o Autoritate de Certificare de incredere
sau se va stabili ca un astfel de lanţ nu există, caz în care,
autentificarea va eșua.

10. Certificate
• Certificatele în formatul X.509 sunt un standard ITU-T pentru
Infrastructura cu Chei Publice.
• Un certificat X.509 conţine cel puţin următoarele date:
• Versiunea,
• Număr Serial,
• Algoritm de Semnare,
• Emitent,
• Perioada de Valabilitate,
• Data,
• Subiectul,
• Cheia Publică
• Semnatura Emitentului

11. SSL - istoric
• SSL a fost dezvoltat de Netscape Communications scopul
urmărit fiind realizarea de tranzacţii sigure, cu carţi de credit
pe Internet utilizând un browser și un server web. Versiunile 1
și 2 ale protocolului s-au dovedit a avea slăbiciuni de
securitate, însa în 1995 odată cu lansarea SSl v3, protocolul s-a
impus ca un standard de facto.

12. SSL
• SSL este un protocol de securitate care reunește toate aceste
mecanisme. Prin intermediul său se poate asigura
confidentialitatea, integritatea mesajelor și autentificarea
parţilor.
• SSL acţionează peste un flux TCP și oferă servicii nivelelor
superioare.
• Protocolul SSL este format din doua etape: handshake si
transfer.

13. Tehnici pentru programare sigură
• Parolele trebuie ţinute în memorie nu ca String, ci ca array de
caractere;
• Parolele trebuie suprascrise cu zero imediat după folosire
pentru a preveni memmory sau disk snooping.
• Atunci când se serializează obiectele, se folosește cuvântul
cheie transient pentru ca informaţia de pe aceste canale să nu
fie trimisă în streamul de date.
• De exemplu, informaţia ar putea să fie citită usor atunci când
mașina este obligată să facă swapping.

14. Password-Based Encryption
• Password-Based Encryption (PBE) creează o cheie de criptare dintr-o
parolă. Pentru a minimaliza șansele ca un atacator să ghicească
parola prin fortă bruta, implementările de PBE implementations
folosesc în plus un numar aleator (salt) pentru a creea cheia.
• Exemplu: Pe orice sistem unix care are pachetul openssl
instalat, puteţi realiza scripturi care să realizeze PBE.
• Pentru criptare folosind idea-cbc:
• >openssl enc -idea-cbc -e -in plaintext_filename -out ciphertext_filename
• Pentru decriptare:
• >openssl enc -idea-cbc -d -in ciphertext_filename

15. Autorizarea
• Mecanismul prin care un sistem informaţional determină
nivelul de accces al unui utilizator pentru a accesa resurse
securizate
• A nu se confunda cu autentificarea! Autentificarea este prima
etapă prin care se identifică cine este utilizatorul, după care
urmează autorizarea, care determină ce poate face utilizatorul
• Utilizatorii de tip anonim sau guest nu trebuie să se
autentifice, însă au autorizare limitată

16. Autorizarea
Sistemele de autorizare oferă răspunsuri la următoarele
interogări:
• Utilizatorul X este autorizat de a accesa resursele R?
• Utilizatorul X este autorizat de a efectua operaţia P?
• Utilizatorul X este autorizat de a efectua operaţia P pe resursa
R?

17. OpenID
• OpenID este un protocol de autentificare
descentralizat, rapid, sigur şi uşor
• Scopul: autentificarea pe diverse site-uri web folosind aceleaşi
date de conectare ne mai fiind nevoie să te înregistrezi de
fiecare dată sau să ţii minte multe parole

18. OpenID - istoric
• A fost dezvoltat în 2005 de creatorul comunităţii LiveJournal
• Prin 2007-2008 giganiţi precum Yahoo! sau Google au început
să colaboreze şi chiar să adopte standardul OpenID
• În decembrie 2009 aproximativ 9 milioane de site-uri aveau
integrat standardul OpenID şi existau peste un miliard de
conturi activate
• Momentan este integrat de Google, Yahoo!, Blogger,
Wordpress, Aol, Flickr şi mulţi alţii

19. OpenID - obținere
• Cel mai probabil majoritatea au deja un OpenID chiar fără a fi
conştienţi de acest fapt
• URL-ul de la profilul Google, cel de la blogul de pe Blogspot
sau Wordpress – toate reprezintă un OpenID
• Dacă totuşi vrei să-ţi creezi manual un OpenID o poţi face de
exemplu pe http://myopenid.com

20. OpenID - conectare
• În funcţie de interfaţa pusă la dispoziţie de site-ul ce
integrează conectarea cu OpenID te poţi conecta fie dând click
pe butoanele de tip „Connect with Google” sau „with
Facebook”, etc. fie introducând URL-ul menţionat slide-ul
anterior
• La prima încercare va apărea o fereastră pentru a autoriza
accesul.

21. OpenID - implementare
• Oricine poate implementa OpenID pentru site-ul
propriu, pentru asta având la dispoziţie diverse biblioteci open
source pe www.openid.net
• Pe acelaşi site se găseşte şi o colecţie link-uri către plug-in-uri
pentru varii CMS-uri

22. OpenID - furnizare
• Poţi deveni şi furnizor de OpenID-uri, cea mai uşoară metodă
fiind tot utilizând bibliotecile sau plug-in-urile de pe site-ul
OpenID

23. OpenID – similar
• În România, pe toate site-urile din reţeaua Intact Interactive se
foloseşte un serviciu asemanator OpenID numit „iDunic” -
https://www.idunic.ro

24. OAuth
• Un protocol pentru autorizare
• Oferă acces la un site pentru partajarea de resurse private
stocate pe acesta fără a fi nevoit să dezvăluie sau să facă
schimb de informaţii precum user sau parolă (credentials)
• OAuth este un serviciu complementar cu, dar distinct
de, OpenID

25. OAuth – istoric
• A fost dezvoltat în 2006 când se încerca implementarea
OpenID pentru Twitter
• De la jumătatea anului 2010, toate aplicaţiile third-party ce
implică autentificarea la Twitter trebuie să folosească OAuth

26. OAuth
• Protocolul OAuth se bazează pe:
• Resurse – sunt obiectele private ale unui utilizator la care se doreşte
accesul selectiv de către alte site-uri sau aplicaţii
• Furnizorul de Servicii – este cel care suportă toate aspectele ale
implementării protocolului, cel care urmează să ofere acces la
resursele care le are în administrare către alţi clienţi. Poate fi, în
general, orice serviciu care oferă stocarea de informaţii private şi
accesibile selectiv.
• Utilizatorul – este cel pentru care s-a inventat acest protocol.
Utilizatorul are resurse în cadrul unui furnizor de servicii (imagini,
video, contacte, mesaje) care nu vrea să le facă publice, dar care
vrea să le folosească şi pe alte site-uri
• Consumatorul – este site-ul de pe care se doreşte accesarea
resurselor aflate la furnizorul de servicii.
• Jetonul sau tokenul – este identificatorul prin care furnizorul de
servicii va comunica cu consumatorul.

27. OAuth – cine foloseşte
• În primul rând: Twitter
• API-ul Graph de la Facebook suportă OAuth 2.0
• Google a implementat OAuth 2.0 la unele API-uri
experimentale
• Poate fi folosit pentru protejarea conţinutului de tip feed

28. OAuth – similar
• Protocoale similare ce se folosesc în prezent sunt Google
AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr
API, Amazon Web Services API, etc.
• OAuth a fost creat prin alegerea a celor mai bune caracteristici
aparţinând fiecăreia dintre aceste protocoale cu speranţa de a
crea un protocol „universal”

29. OAuth – implementare
• Pe site-ul oficial, www.oauth.net, se găsesc tot felul de resurse
pentru cele mai comune limbaje de programare.

30. OAuth @ Twitter
• Oricine işi poate crea propria aplicaţie pe Twitter, urmând
linkul https://dev.twitter.com/apps
• vei putea alege între o aplicatie desktop sau o aplicaţie web
• Pentru autentificare se folosește standardul Oauth

31. OAuth @ Twitter
• Standardul Oauth folosește următorul ciclu:

32. OAuth @ Twitter
• Oauth poate fi confuz pentru ca folosește deverse variante:
• Folosește Oauth header-based
• Folosește SSL pentru end-point-urile /oauth/*
• Folosește api.twitter.com
• Tot timpul folosește oauth_callback
Requesturile OAuth 1.0A sunt la fel ca algoritmii de creare a unei
semnături digitale.

33. OAuth @ Twitter
Obţinerea unei cereri de request se poate obţine la adresa
http://api.twitter.com/oauth/request_token
• Trebuie folosită metoda HTTP POST și este recomandat să se
folosească SSL.
Variabile necesare:
• oauth_callback -
http://localhost:3005/the_dance/process_callback?service_provider_id=11
• oauth_consumer_key - GDdmIQH6jhtmLUypg82g
• oauth_nonce - QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk
• oauth_signature_method - HMAC-SHA1
• oauth_timestamp - 1272323042
• oauth_version - 1.0

34. Algoritmul OAuth @ Twitter
• In pseudo cod, algoritmul arată astfel:
httpMethod + "&" +
url_encode( base_uri ) + "&" +
sorted_query_params.each { | k, v |
url_encode ( k ) + "%3D" +
url_encode ( v )
}.join("%26")

35. OAuth @ Facebook
• Facebook.com folosește Oauth 2.0 pentru autentificare si
autorizare;
• Necesită 3 pași diferiți:
• Autenfiticarea userului : la acest pas se asigură cp userul este cu
adevarat cel ce predinde ca este;
• Autorizarea aplicației : la acest pas se asigurp cp userul știe exact
ce date și ce capabilităţi are aplicaţia respectivă;
• Autenfificarea aplicației: la acest pas se asigură că userul va
furniza propriile informaţii și nu pe ale altcuiva;

36. OAuth @ Facebook
• Pasul 1 :
Pasul 2 :

37. OAuth @ Facebook
• Pasul 3 :

38. Bibliografie
• http://en.wikipedia.org/wiki/Authentication
• http://en.wikipedia.org/wiki/Authorisation
• http://openid.net/
• http://en.wikipedia.org/wiki/Openid
• http://oauth.net/
• http://en.wikipedia.org/wiki/Oauth
• https://dev.twitter.com/
• http://developers.facebook.com