Az OpenID egy nyílt szabványú decentralizált hitelesítési rendszer , amely lehetővé teszi a felhasználó számára, hogy egyetlen fiókot hozzon létre a hitelesítéshez számos független internetes erőforráson , harmadik féltől származó szolgáltatások segítségével [1] .
Az OpenID alapvető funkciója, hogy hordozható, kliensközpontú, digitális identitást biztosítson ingyenes és decentralizált használatra [2] .
A szabvány leírja a hitelesítést igénylő internetes erőforrások (Relying Parties) és az OpenID szolgáltatók (OpenID szolgáltatók) közötti kommunikáció folyamatát. Számos OpenID szolgáltató létezik, amely OpenID URL -eket tárol [3] . Az OpenID hitelesítést a Google használja , a Yahoo! , AOL , LiveJournal , MySpace , IBM [4] , Steam [5] és Orange . A szabvány kiterjesztése (az OpenID Attribute Exchange) megkönnyíti a felhasználói adatok, például a név vagy a nem átvitelét egy OpenID szolgáltatótól egy internetes erőforráshoz [6] .
2009 decemberéig több mint 1 milliárd OpenID-fiók és körülbelül 9 millió webhely támogatta az OpenID technológiát [7] .
A szabvány jelenlegi verziója, az OpenID Connect 1.0 2014 februárjában jelent meg, és 2014 novemberében frissült [8] [9] .
2005-ben a LiveJournal alkotójaként ismert Brad Fitzpatrick , aki akkoriban a Six Apart -nál dolgozott, a különböző internetes források egyetlen fiókjának koncepcióját javasolta az internetes közösségnek [10] . Azt javasolta, hogy fiókját tartsa egy szerveren, és használja ezt a fiókot, amikor más internetes forrásokon regisztrál. Eredetileg Yadis néven (a "Yet another distributed identitásrendszer" rövidítése) a protokoll OpenID nevét azután kapta, hogy a Six Apart regisztrálta az openid.net domain nevet a projektje számára. Hamarosan az OpenID támogatása bevezetésre került a LiveJournalon, és ez a technológia gyorsan felkeltette az internetes közösség figyelmét [11] .
2006-ban elkészült az első OpenID specifikáció – az OpenID Authentication 1.1 [12] .
2007. december 5-én a Sun Microsystems , a VeriSign és számos, az OpenID fejlesztésében részt vevő vállalat kiadta az OpenID 2.0 specifikációt, és hivatalosan kijelentette, hogy nem tesz követelést, ha valaki az OpenID technológiát használja, kivéve a használó személy cselekedeteit. a technológia a technológia megvalósítása vagy a technológia tulajdonjoga ellen irányul [13] .
Az OpenID védjegyet 2008 márciusában jegyezték be az Egyesült Államokban [14] .
Például egy webhelyen example.comvan egy bejelentkezési űrlap egyetlen beviteli mezővel az OpenID azonosítóhoz. Gyakran ez a mező mellett található az OpenID logó. Ahhoz, hogy ezen az oldalon az Ön azonosítójával – például pupkin.openid-provider.orgaz OpenID szolgáltatónál regisztrálva – engedélyezze magát openid-provider.org, a felhasználónak meg kell adnia azonosítóját az oldalon található bejelentkezési űrlapon. A webhely ezután example.com átirányítja a felhasználót a szolgáltató webhelyére. A szolgáltató webhelye arra kéri a felhasználót, hogy erősítse meg, hogy a felhasználó valóban információt kíván-e adni a fiókjáról. Ha a felhasználó beleegyezik, akkor a szolgáltató webhelye visszairányítja a felhasználót a függő fél oldalára. Fordított átirányítás esetén a szolgáltató továbbítja a felhasználói információkat az érintett félnek [15] .
Egy OpenID szolgáltató például a LiveJournal , így a LiveJournalban lévő naplód címét használhatod OpenID-azonosítóként [16] .
Az OpenID lehetővé teszi a felhasználó számára, hogy egy OpenID-szolgáltatónál regisztrált fiókot több más webhelyen is használjon. A felhasználó kiválaszthatja, hogy milyen információkat közöljön az oldallal. A profilinformációk vagy az OpenID specifikációban nem leírt egyéb információk cseréje az OpenID protokollon keresztül megvalósítható kiegészítő szolgáltatások segítségével. Ehhez az OpenID protokoll által hivatalosan támogatott protokollbővítési mechanizmus [17] biztosított .
Lehetőség van az OpenID delegálására. Ez azt jelenti, hogy egy adott domain név tulajdonosa használhatja azt egy már létező OpenID azonosító szinonimájaként (aliasként), amelyet bármely OpenID szolgáltatótól szerezhet be. Ehhez hozzá kell adni néhány metataget a delegáltként használt oldalhoz [18] .
Az OpenID rendszer decentralizált rendszer. Ez azt jelenti, hogy nincs olyan központi szolgáltatás vagy szervezet, amely lehetővé tenné a rendszer használatát, vagy regisztrálná az OpenID hitelesítést igénylő internetes erőforrásokat vagy OpenID szolgáltatókat. A végfelhasználó szabadon választhat, hogy melyik OpenID szolgáltatót használja, és ha az OpenID szolgáltató megváltozik, megtartja az azonosítót [1] .
A szabvány nem igényel JavaScriptet vagy modern böngészőket , azonban a hitelesítési séma jól kompatibilis az AJAX megközelítéssel . Ez azt jelenti, hogy a végfelhasználó az aktuális oldal elhagyása nélkül hitelesítheti magát a webhelyen. Ebben az esetben az internetes erőforrás kommunikációja az OpenID szolgáltatóval a háttérben történik. Az OpenID hitelesítés csak szabványos HTTP (S) kéréseket és válaszokat használ, így a szabvány nem követeli meg a felhasználótól további szoftverek telepítését . Az OpenID nem igényli cookie -k vagy más munkamenet-kezelési mechanizmusok használatát. A különféle kiterjesztések megkönnyíthetik az OpenID használatát, de nem szükséges a szabvány [2] használata .
Az OpenID Foundation (OIDF) egy non-profit szervezet, amely 2007 júniusában alakult az OpenID közösséghez kapcsolódó szerzői jogok, védjegyek, marketing és egyéb tevékenységek kezelésére [20] .
A szervezet Igazgatósága 4 közösségi és 8 társasági tagból áll [21] :
| Közösségi tagok
• John Bradley ( Independent ) (Eng. John Bradley) • George Fletcher (AOL) (angolul George Fletcher) • Mike Jones ( Microsoft ) (ang. Mike Jones) • Nat Sakimura ( Nomura Research Institute ) |
Vállalati tagok
• Google – Adam Dawes • Microsoft – Anthony Nadalin (eng. Anthony Nadalin) • Ping Identity – Pamela Dingle (ang. Pamela Dingle) • Symantec – Brian Berliner • Verizon – Bjorn Helm (ang. Bjorn Hjelm) • Oracle – Prateek Mishra • VMware – Ashish Jain • Amerikai Egyesült Államok Egészségügyi és Humánszolgáltatási Minisztériuma – Debbie Bucci |
Az Egyesült Államokban 2008 márciusában az OpenID Foundation bejegyezte az OpenID védjegyet. Korábban a NetMesh Inc. tulajdonában volt. Európában 2007. augusztus 31-én az OpenID Europe Foundation bejegyezte az OpenID védjegyet [14] .
Az OpenID hitelesítés lehetőséget biztosít a végfelhasználónak, hogy igazolja személyazonosságát az oldalon anélkül, hogy megadná jelszavát, e-mail címét vagy egyéb olyan információt, amelyet nem szeretne megadni ezen az erőforráson. Az OpenID 1.1 specifikációja nem biztosít semmilyen mechanizmust a végfelhasználói profil információinak cseréjéhez [18] .
A fő különbség az OpenID 2.0 és az OpenID 1.1 között a végfelhasználók számára az XRI azonosítóként való használatának lehetősége. Az OpenID 2.0 az OpenID 1.1-től eltérően támogatja a HMAC-SHA256 algoritmust – egy 256 bites ( [RFC2104 ] digitális aláírást, amely biztonságosabbá teszi az OpenID üzenetek hitelesítését. Az OpenID 2.0 egy kiterjesztési mechanizmust vezetett be, amely lehetővé teszi további információk hozzáadását a hitelesítési kérésekhez és válaszok [22] .
Az OpenID 2.0 kompatibilis az OpenID 1.1-gyel [23] .
Az OpenID technológia harmadik generációja, amely egy hitelesítési bővítmény az OAuth 2.0 engedélyezési protokollon keresztül . Az OpenID Connect lehetővé teszi, hogy az internetes erőforrások egy jogosultság-kiszolgáló által végzett hitelesítés alapján ellenőrizzék a felhasználó azonosságát . A munkához a specifikációban leírt RESTful API-t használják. Ezenkívül az OpenID Connect további mechanizmusokat határoz meg az erős titkosítás és a digitális aláírás érdekében. A szabvány további funkciókat tesz lehetővé, mint például a munkamenet-kezelés és az OpenID-szolgáltatók felderítése [8] .
Míg az OAuth 1.0a szabvány OpenID 2.0-val való integrációja bővítést igényel, az OpenID Connect már magával a protokollal integrálja az OAuth 2.0 képességeit [24] .
Egyes kutatók úgy vélik, hogy az OpenID protokoll sebezhető az adathalász támadásokkal szemben , amikor szolgáltató helyett a támadók egy hasonló kialakítású webhelyre irányítják a végfelhasználót. Ha a felhasználó nem veszi észre a helyettesítést, akkor megadja a hitelesítési adatait (bejelentkezés, jelszó). Ennek eredményeként a támadók adott felhasználóként jelenhetnek meg az internetes forrásokban, és hozzáférhetnek az ezeken az erőforrásokon tárolt információihoz [25] .
Adathalász támadások akkor is lehetségesek, ha egy OpenID-engedélyezést támogató webhelyet meghamisítanak annak érdekében, hogy információkat szerezzenek a felhasználóról a szolgáltatótól. A "stealth redirect" sebezhetőség segítségével a támadók azt az illúziót kelthetik a felhasználóban, hogy az információt a valódi webhely kéri [26] .
Az OpenID nem tartalmaz olyan mechanizmusokat, amelyek megakadályozzák az adathalász támadásokat. Az adathalász támadások felelőssége az OpenID szolgáltatókra hárul [27] .
Az adathalászat elleni védelem érdekében a felhasználók további szoftvereket használhatnak, mint például a Microsoft Identity Selector [28] . Vannak olyan megoldások is, amelyekhez nincs szükség további szoftverek telepítésére, ilyen például a BeamAuth, amely a böngésző könyvjelzőit használja a munkájához [29] .
Ha nem TLS/SSL protokollokat használnak a felhasználó és az OpenID-szolgáltató közötti kapcsolat biztosítására , akkor a hitelesítés utolsó szakaszában sérülékenység lép fel. A felhasználó saját magáról az internetszolgáltatásra való átirányításához a szolgáltató egy speciális URL-t küld a felhasználónak. A probléma az, hogy bárki, aki meg tudja szerezni ezt az URL-t (például egy csavart érpárú kábel szippantásával), újra lejátszhatja, és felhasználóként hozzáférhet az oldalhoz. Egyes szolgáltatók egyszeri kódot ( Nonce ) használnak a támadás elleni védelem érdekében, amely lehetővé teszi egy adott URL egyszeri használatát. A nem megoldás csak akkor működik, ha a Felhasználó először az URL-t használja. A kommunikációs csatornán figyelő, a felhasználó és az internetszolgáltató között tartózkodó támadó azonban megszerezheti az URL-címet, azonnal megszakíthatja a felhasználó TCP-kapcsolatát, majd végrehajthatja a támadást. Így az egyszeri kódok csak a passzív támadók ellen védenek, de nem akadályozhatják meg az aktív támadók támadásait. A TLS/SSL használata a hitelesítési folyamatban kiküszöböli ezt a kockázatot [30] .
A felhasználó megváltoztathatja az OpenID szolgáltatót, így felszabadítja az előző szolgáltatótól származó azonosítóját. Az új felhasználó átveheti ezt az azonosítót, és ugyanazokon a webhelyeken használhatja, mint az előző felhasználó. Ezzel az új felhasználó hozzáférhet az adott azonosítóhoz kapcsolódó összes információhoz. Ez a helyzet véletlenül is előfordulhat – nem szükséges, hogy az új felhasználó támadó legyen, és hozzá akarjon férni a megadott információkhoz [31] .
Az OpenID 2.0 specifikációban az azonosító újrafelhasználásának problémájának megoldására töredékek használata javasolt - minden felhasználó számára egyedi töredéket kell hozzáadni az azonosítóhoz [19] .
2012-ben a kutatók publikáltak egy tanulmányt, amelyben leírják az OpenID két sebezhetőségét. Mindkét sebezhetőség lehetővé teszi a támadó számára, hogy hozzáférjen az áldozat fiókjához [32] .
Az első biztonsági rés az OpenID Attribute Exchange szolgáltatást használja. A probléma az, hogy egyes internetes szolgáltatások nem ellenőrzik az Attribute Exchange-en keresztül küldött adatokat. Ha az Attribute Exchange segítségével manipulációbiztos információkat adnak át a felhasználóról (például a nemről), akkor ez a biztonsági rés nem használható ki. Az Attribute Exchange azonban használható például a felhasználó e-mail-címének átvitelére is. A támadó megpróbál hitelesíteni a függő fél webhelyét, és a válaszban hozzáadja az áldozat e-mail szolgáltatóját. Ha az érintett fél nem ellenőrzi ezen információ hitelességét, akkor a támadót áldozatként azonosítják. Így bármely regisztrált fiókhoz hozzáférhet. A kutatók jelentése szerint sok népszerű weboldalt érintett ez a támadás, köztük a Yahoo! Mail [33] .
A második sérülékenység a szolgáltató oldalán lévő hibához kapcsolódik, és hozzáférést tesz lehetővé a függő fél webhelyén található fiókhoz. A szolgáltató válasza tartalmazza az openid.ext1.value.email mezőt , amelyet az érintett fél a felhasználó e-mail-címeként kezel. A szolgáltató által ebbe a mezőbe hozzáadott adatok típusát azonban a támadó szabályozhatja – a szolgáltatóhoz intézett kérés tartalmazza a type.email mezőt , amely a mezőt leíró sémára mutató hivatkozást tartalmaz. A támadó hivatkozást adhat hozzá egy sémához, amely leírja a felhasználónevet a type.email fájlban . Ha egy támadó regisztrálhat a szolgáltató webhelyén egy névvel, például [email protected], akkor a szolgáltató hozzáadja ezt a nevet az openid.ext1.value.email mezőhöz , és az érintett fél feltételezi, hogy az ezzel rendelkező fiók az email a támadóé. A Google és a Paypal implementációit sebezhetőnek találták [33] .
Az OpenID mindkét sérülékenységről jelentést tett közzé, és frissítések is megjelentek a javításukra [34] [35] .
| Hitelesítési és kulcscsere protokollok | |
|---|---|
| Szimmetrikus algoritmusokkal | |
| Szimmetrikus és aszimmetrikus algoritmusokkal | |
| Az interneten használt protokollok és szolgáltatások | |