Autentimine
Seega kasutaja autentimiseks on kolm eraldiseisvat võimalust:
- Teave.
- Midagi, mida ainult antud kasutaja teab, näiteks parool.
- Millegi omamine.
- Midagi, mis ainult antud kasutajal on, näiteks kiipkaart.
- Kasutaja olemus.
- Midagi, mis antud kasutaja ise on, näiteks kasutaja sõrmejäljed.
Ühetasandiline autentimine
Ühetasandilise autentimise korral kasutatakse eelpool toodud nimekirjast ainult ühte võimalust. Kõige tavalisem on kasutaja teadmiste kontroll, kus inimene peab kasutama oma teadmisi, et millegile juurdepääsu saada. Näiteks kui juurdepääsuks nõutakse ainult paroole, PIN koode või erinevaid mustreid.
Näited:
- parooliga emaili või ÕIS-i kontole sisenemine
- mustri abil Android-telefoni ekraaniluku avamine
- parooli ja taaskasutatava paroolikaardi abil panka logimine, ühetasandilise autentimise madala turvalisuse tõttu on päevastele tehingute seatud limiit
Paroolid ja autentimine
Turvalisuse huvides nõutakse kasutajatelt keeruliste paroolide kasutamist. Samas ei tohiks kasutada samasuguseid paroole erinevate kontode jaoks, sest parooli lekkimisel muutuksid kõik kontod avalikuks. Samas on keerukate paroolide kasutamine inimeste jaoks keeruline, sest nad ei suuda meeles pidada pikki ja juhuslikke paroole.
Alternatiivne meetod pikkade juhuslike paroolide meelde jätmisele. Allikas: XKCD koomiksProbleemi illustreerimiseks saate külastada lehekülge, mis ennustab parooli murdmiseks kuluvat aega kui murdmiseks kasutatakse ühte lauaarvutit: https://howsecureismypassword.net/. Ärge sisestage sellele lehele enda reaalseid paroole!
Paraku on nõrkade paroolide kasutamine populaarne, sest neid on lihtne meelde jätta. Võib tekkida küsimus, et kuidas ikkagi teatakse, et inimesed kasutavad siiani nõrku paroole. Sellele küsimusele annavad vastuse nii hooletuse kui ka rünnete tõttu tekkinud andmelekked. Lekkinud paroole analüüsivad nii küberkurjategijad kui ka turvaeksperdid ning tulemuste põhjal saab näha, mis on parajasti kõige levinumad paroolid. RIA avaldas 2017 aasta lõpus uudise, milles loetleti kahtekümment populaarsemat eestlaste poolt kasutatud parooli. Vastav info oli kokku pandud mitmetest erinevatest leketest, täpsema info leiate RIA poolt koostatud uudisest. Järgnev nimekiri kuvab vastavad paroolid alustades kõige levinumast:
- 123456
- parool
- qwerty
- 123456789
- lammas
- 12345
- minaise
- maasikas
- kallis
- killer
- armastus
- lollakas
- samsung
- 123123
- teretere
- lilleke
- martin
- 12345678
- kiisuke
- kallike
Kui te tahate teada kas teie parool võib olla lekkinud, siis saate seda kontrollida lehelt https://haveibeenpwned.com/. Tegemist on turvaeksperdi Troy Hunt-i poolt loodud teenusega, mis võimaldab kontrollida kas emaili aadress on olnud seotud mõne andmelekkega. Võite nüüd mõelda, et kuidas emaili aadress on leketega seotud ja kuidas vastav veebileht suudab kontrollida kas minu emaili aadress on olnud osaks mõnest lekkest. Vastus peitub selles, et suur osa teenusepakkujatest kasutab emaili aadressi kasutajanimena ning isegi kui seda ei tehta, siis küsitakse seda registreerumisel. Troy Hunt kogub paroolileketega seotud andmeid ning võimaldab läbi vastava teenuse kontrollida kas emaili aadress on olnud mõne lekkega seotud.
Kuidas teenused paroole kasutavad ja kontrollivad?
Nüüd anname lühikese selgituse sellest kuidas veebilehed (ja ka muud teenused) paroolide õigsust kontrollivad. Paroolide sisestamisel ei võrrelda sisestatud parooli vaid funktsiooni paroolist. Kui süsteem või veebileht salvestaks kasutajate paroole, siis süsteemi murdmise korral lekiksid kõigi kasutajate paroolid. Selleks, et rünnaku puhul paroolide lekkimist ära hoida salvestatakse hoopis paroolide räsid.
Räsifunktsioon (hash function) saab sisendiks suvalise pikkusega teksti ja väljastab fikseeritud pikkusega sümbolite järjendi nii, et tulemuseks olevast sümbolite järjendist ei ole võimalik leida esialgset teksti.
Näiteks räsifunktsiooni SHA-256 kasutades saame:sha256(“test”) = 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
Veebilehed salvestavadki paroolide asemel nende räsid. Kui kasutaja tahab sisse logida ja oma parooli sisestab, siis saadetakse parool veebiserverisse ja seal arvutab veebileht sellest uuesti räsi ja võrdleb seda andmabaasis olevaga. Juhul kui andmebaasis olev räsi on võrdne paroolis arvutatud räsiga, siis on kasutaja sisestanud õige parooli ja saab veebilehele sisse logida.
Siit tekib järgmine probleem, räsifunktsioon on deterministlik ja seega saab süsteemi ründaja räside tulemused varem välja arvutada. Ründaja võib näiteks arvutada välja kõikide lihtsamate paroolide räsid, muuseas näiteks parooli “test” räsi kasutades räsifunktsiooni SHA-256. Seega kui süsteemi või veebilehe räside andmebaas lekib, siis saab paljud levinud paroolid ikkagi tuvastada. Probleemi lahendab iga kasutaja räsi juhuslikuks muutmine paroolile juhuslikkuse (inglise keeles "salt") lisamisega. Kui varem võis ründaja välja arvutada (räsi, parool) tüüpi sõnaraamatu kõikide levinumate paroolide jaoks, siis nüüd ründaja seda enam teha ei saa. Nüüd on andmebaasis kõik räsid (suure tõenäosusega) unikaalsed ja selleks, et ründaja saaks töö ette ära teha peaks ta sõnaraamatu koostamisel arvesse võtma ka juhuslikkust. Juhul kui sool on 64 bitine, siis on võimalik koostada 2 astmel 64 erinevat juhuslikku soola. Seetõttu peaks ründaja koostama ühe sõnaraamatu asemel 2 astmel 64 erinevat sõnaraamatut, sest tal on vaja iga soola kohta välja arvutada kõikide levinumate paroolide räsid. Nii suure hulga sõnaraamatute koostamine on ründaja jaoks võimatu nii ajalises mõttes kui ka vajamineva andmemahu poolest. Seetõttu kaitseb piisavalt pika soola kasutamine sõnaraamatu rünnete eest ja ründaja peab hakkama paroole murdma alles andmebaasi lekkimisel.
Näide lihtsa soola lisamisest paroolile "test":sha2(“test+j2Bl”)=4cb0ccd18a4f985823c5640e97103b6c7ee23d175cffc01691baeb006773c365
Näide: Vaatame, kuidas saab lihtsate paroolide räsidest vastavaid paroole jõuga ära arvata. Näiteks kui räsi vastab nelja sümboli pikkusele paroolile, siis tuleks vastava parooli leidmiseks genereerida kõigi nelja sümboli pikkuste paroolide räsid. Tegelikult ründaja ei tea kui pikk parool vastab räsile.
Ründajate elu tehakse veelgi keerulisemaks ning tavalise räsifunktsiooni asemel kasutatakse hoopis spetsiaalset paroolipõhist võtmetuletusfunktsiooni (password-based key derivation function). Selliste funktsioonde mõte on selles, et nad räsivad sisendit mitte üks vaid näiteks 10 000 korda, muutes seega ründajal paroolide arvamise oluliselt ajakulukamaks. Näited sellistest funktsioonidest on PBKDF2, scrypt, bcrypt jt.
Näited sellest kuidas ei tohiks paroole andmebaasi salvestada
Väga paljud veebilehed salvestavad paroole enda andmebaasi valesti. Enamasti salvestatakse parool kas lihttekstina või räsitakse parool ilma soolata. Mõnikord leiab ka midagi huvitavamat, näiteks mõned veebilehed krüpteerivad paroole. Paroolide krüpteerimine on väga halb mõte, sest krüpteeritud andmeid saab dekrüpteerida (mõelge, mis juhtub kui krüptovõti lekib).
- 2014. aasta augustis lekkis http://seemnemaailm.ee/ kasutajate andmebaas. Antud andmebaasis olid avatud kujul üle kümne tuhande kasutaja paroolid. Sellest lekkest kirjutas ka Postimees: Veebikeskkond jättis tuhanded kliendid andmelekkest teavitamata. Huvitav on see, et antud artiklis räägitakse lahendusena paroolide krüpteerimisest, mis on samuti vale tegevus.
- 2014. aasta kevadel lekkis Adobe kasutajate andmebaas. Selles andmebaasis olid umbes 150 miljoni kasutaja andmed. Huvitav oli selle lekke juures see, et Adobe oli otsustanud andmebaasis olevaid paroole krüpteerida. See iseenesest on halb valik, sest tegelikult tuleks kasutada paroolide räsimist, sest räsimine on ühesuunaline operatsioon. Teine probleem seisnes selles, et nad kasutasid paroolide krüpteerimise jaoks ebaturvalist lahendust (ECB režiimi), mistõttu samasugused paroolid andsid tulemuseks samasuguse krüpteeritud parooli. Lisaks oli kasutajate andmebaasis ka parooli vihje, mistõttu võib sellest lekkest mõelda kui suurest ristsõnast.
Ühetasandilise autentimise probleemid
Tekib probleem: kuidas kasutada turvalist parooli ja seda ka meeles pidada? Mida turvalisem on parool seda raskem on parooli meeles pidada. Paroolide haldamisest räägime praktikumis. Lahenduste ideed:
- õppida paroolid pähe
- kirjutada paroolid paberile
- salvestada paroolid tekstifaili
- kasutada paroolide haldamise tarkvara
Kasutajanimesid ja paroole saab ilma suurema vaevata kopeerida ja levitada. Samuti on turvalisi paroole raske meelde jätta ning seetõttu on suur osa paroole liiga lühikesed ja liiga kergesti ära arvatavad. Ühetasandilist autentimist saab edukalt rünnata kasutades klahvikuulajat (keylogger), mis salvestab klaviatuuri klahvide vajutused ja saadab vastava info ründajale.
Näidisrünne ja demo:
Arvuti nakatatakse pahavaraga, mis salvestab ja edastab arvutikasutaja klahvivajutusi. Kui arvutikasutaja autendib ennast kasutajatunnuse ja parooli abil, siis edastab pahavara kasutajatunnuse ja parooli ründajale.
Selle ründe demonstreerimiseks on meil brauser nakatatud nii, et see saadaks klahvivajutusi ettemääratud lehele.
Selleks, et autentimist turvalisemaks muuta tuleb lisaks teadmistele kasutada teisi autentimise meetodeid. Lisaks teadmistele saab autentimiseks kasutada eset mida kasutaja omab või midagi kasutajast lähtuvat (biomeetrilised omadused).
Lisamaterjalid
Autentimisest saate hea ülevaate MIT kursuse 6.858 Computer Systems Security poolt pakutava video kaudu, mis on tasuta kättesaadav läbi MIT OpenCourseWare programmi. Viidatud video on lisamaterjal ja seega ei ole selle vaatamine kohustuslik.
Kaksikautentimine (kahetasandiline autentimine)
Kaksikautentimise korral nõutakse kahte erinevat autentimise viisi ehk tuleb valida järgnevatest kaks meetodit:
- teadmistepõhine autentimine
- millegi omamisel põhinev autentimine
- isikust lähtuv autentimine
Levinumatest kahefaktorilistest autentimisviisidest kirjutatakse järgnevas lühiülevaates: A Guide to Common Types of Two-Factor Authentication on the Web (2017)
ID-kaardiga autentimine
Autentimine ID-kaardiga on kaksikautentimine, mis seob teadmistepõhise ja omandil põhineva autentimise. Lisaks kehtiva isikutuvastuse sertifikaadiga ID-kaardi omamisele peab kasutaja teadma ja selle kaardi PIN1 koodi. Oluline on see, et ID-kaarti (ja seal peal olevaid salajasi võtmeid) ei saa kopeerida, seega võib ID-kaarti kasutada kliendikaardina ilma turvalisust ohustamata.
Siiski, kui ID-kaart läheb kaduma, tuleb turvaohu vähendamiseks võimalikult kiiresti isikutuvastuse ja digiallkirja sertifikaadid peatada. Seda saab teha helistades numbrile 1777 ja öeldes oma nime, sünniaasta ja isikukoodi. Kadunud kaardi ülesleidmisel saab kaardi sertifikaadid taas aktiveerida kodakondsus- ja migratsioonibüroos. Selleks, et kaart dokumendina kehtetuks tunnistada tuleb ühendust võtta Politsei- ja Piirivalveametiga. Rohke infot leiate siit:
Ühekordsed paroolid
Selleks, et vältida paroolide lekkimist ja uuesti kasutamist nõuavad mõned süsteemid ühekordsete paroolide kasutamist. Ühekordsete paroolide kasutamise korral on oluline, et serveri ja kliendi paroolid oleksid sünkroniseeritud (selleks kasutatakse algoritme, millest antud aine raames ei räägita). Rohkem infot leiab: https://en.wikipedia.org/wiki/One-time_password.
Tekib küsimus, et kuidas ühekordseid paroole kliendile edastada. Selleks on mitmeid võimalusi:
- Paberil - Ühekordsed paroolid saadetakse kliendile paberil, kasutades näiteks postiteenust või kullerit. Näiteks Nordea pank kasutas ühekordseid paroolikaarte, mis tähendas seda, et igat parooli paroolikaardil sai kasutada ainult ühe korra. Uue paroolikaardi aktiveerimiseks tuli sisestada ka eelmise paroolikaardi viimande kood. See kaitses selle eest, et võõras ei saaks uut paroolikaarti pahatahtlikult kasutada enne kui see on adressaadini jõudnud.
- SMS teel - kättesaadav paljudele, aga SMS krüpteering on liiga nõrk, et tagada parooli/koodi konfidentsiaalsust. Roamingu korral tuleb usaldada mitmeid teenusepakkujaid. See on ka põhjus, miks NIST telefoni (kõne või SMS) teel ühekordsete paroolide edastamist enam ei soovita: Digital Authentication Guideline.
- Seadmete abil - näiteks on võimalik kasutada eelsünkroniseeritud algoritme, mis võimaldavad genereerida autentimiskoode, mis on teise osapoole poolt kontrollitavad. Nii võivad toimida näiteks PIN-kalkulaatorid. Samuti leidub nutiseadmetele rakendusi, mis võimaldavad genereerida ühekordseid autentimiskoode. Üheks tuntumaks näiteks on Google Authenticator, mis kasutab ühe sisendina aega, et genereerida autentimiskoode.
Viimasest kahest räägib täpsemalt järgmine osa.
Autentimine mobiili või muu seadme abil
Mobiiltelefon sobib väga hästi teiseks autentimise faktoriks, kuna see on arvutist eraldiseisev ja kasutab teist sidekanalit (GSM, 3G, 4G). Selleks, et rünnata kaksikautentimist, mis kasutab lisaks paroolile ka mobiili või mõnda muud seadet, tuleb ründajal lisaks paroolile anda käsutusse saada ka see eraldiseisev seade.
Näited:
- PIN-kalkulaatorid pankades
- Google'i kaksikautentimine
- Facebooki kaksikautentimine
PIN-kalkulaator
PIN-kalkulaator on seade, mis genereerib internetipanka sisenemiseks või ülekannete tegemiseks vajaliku koodi. PIN-kalkulaatori tööpõhimõte seisneb selles, et PIN-kalkulaatori poolt genereeritud koodid on pangaga sünkroniseeritud. Oluline on see, et PIN-kalkulaator genereerib iga kord uue parooli ja sama koodi ei saa kasutada kaks korda järjest internetipanka sisenemiseks. Seega pole varastatud koodist enam kasu kui seda on juba korra kasutatud. Selleks, et võõras isik ei saaks seadet kasutada tuleb kõigepealt sisestada enda poolt määratud PIN-kood ja pärast seda saab genereerida internetipanka sisenemiseks või ülekannete tegemiseks kasutatavaid koode. Kuna PIN-kalkulaatori abil autentimine on kaksikautentimine, siis on see palju turvalisem kui ühetasandiline korduvkasutatava paroolikaardi abil autentimine. Seetõttu ei ole pangad seadnud päevalimiite internetipankades PIN-kalkulaatorit kasutavatele klientidele.
PIN-kalkulaatorid toimivad tänu jagatud saladusele, mis asub nii panga andmebaasis kui ka PIN-kalkulaatori sees. PIN-kalkulaatori turvalisuse seisukohast on selle sees kasutatava pseudojuhuslike arvude generaatori turvalisus ja see, et seal sees olev jagatud saladus ei lekiks.
Aga kuidas saavad PIN-kalkulaator ja pank õiges ühekordses paroolis kokku leppida kui PIN-kalkulaatoril internetiühendus puudub? Üheks võimaluseks on see, et nii pank kui PIN-kalkulaator tuletavad parooli jagatud saladusest ja hetke kellaajast. See muidugi eeldab, et mõlemal on juurdepääs suhteliselt täpsele kellaajale. Alternatiivne PIN-kalkulaatori tööpõhimõte töötab räsiahelal ja erinevad värsked ühekordsed paroolid on tegelikult erinev arv kordi räsitud jagatud saladus. Selle toimimiseks peavad pank ja PIN-kalkulaator lisaks jagatud saladusele meeles hoidma ka loenduri väärtust. Iga uue parooli genereerimisel suurendab PIN-kalkulaator loendurit ja iga õige parooli sisestamisel teeb pank sama. Et vältida näpuvigade tõttu PIN-kalkulaatori ja panga loendurite sünkroonist välja minemist, peab pank aktsepteerima "õigeid" paroole mingist loenduri vahemikust. Läbiproovimisel põhinevate rünnakute vältimiseks peab see vahemik muidugi suhteliselt väike olema. Selline järjestikusel räsimisel põhinev PIN-kalkulaator eeldab tegelikult, et loendur töötab tagurpidi (suuremast väiksemaks). Näiteks esimesel korral väljastatakse 10 korda räsitud jagatud juhuslikkus, järgmisel korral 9 korda räsitud juhuslikkus, jne. Miks kasvav loendur ebaturvaline oleks?
Rohkem infot PIN-kalkulaatorite kasutamise kohta leiab allpool viidatud materjalidest:
Google'i kaksikautentimine
Google kaksikautentimine nõuab võõrast brauserist (ehk ka võõrast arvutist) sisse logides lisaks paroolile ka kasutaja mobiilile saadetud verifitseerimiskoodi sisestamist, et kontrollida, kas antud telefon (SIM kaart) on ikka selle inimese käsutuses. Verifitseerimiskood saadetakse telefoni kas SMS või spetsiaalse nutitelefoni rakenduse kaudu, lisaks on võimalik lasta Google'il endale helistada ja verifitseerimiskood kõnega edastada. Google'i kaksikautentimise puhul ei saa klahvikuulajaga parooli kinni püüdnud ründaja kontole juurdepääsu kui tal pole juurdepääsu vastavale telefonile (SIM kaardile). Google kahetasemelisest autentimisest täpsemalt:
Pärast Google kahetasemelise autentimise aktiveerimist tuleb kindlasti luua võimalus juurdepääsuks kontole kui teie telefoniga või telefoninumbriga midagi juhtub. Selleks tuleb salvestada ühekordsed koodid, mis võimaldavad juurdepääsu Google kontole näiteks kui telefon koos SIM-kaardiga ära kaob või ära varastatakse.
Pärast Google kaksikautentimise seadistamist tuleb programmides, mis ei toeta kaksikautentimist ja mis kasutavad vastavat Google kontot, kasutusele võtta rakendusepõhine parool. Näiteks pärast kaksikautentimise seadistamist ei pruugi vanema tarkvaraga nutitelefon enam Google kontole juurdepääsu saada. Kui väljaspool brauserit olevad programmid (mis ei toeta kaksikautentimist) tahavad saada juurdepääsu Google kontole, siis tuleb neile määrata ühekordne parool. Seda tuleb teha Google konto seadede alt "Account -> Security -> 2-step verification -> Manage your application specific passwords".
Facebooki kaksikautentimine
Facebooki kaksikautentimine toimib analoogselt Google kaskikautentimisele. Facebooki kaksikautentimine nõuab võõrast arvutist või brauserist sisse logides lisaks paroolile ka SMS-i teel saadetud koodi sisestamist. Seetõttu ei saa klahvikuulajaga parooli kinni püüdnud ründaja kontole juurdepääsu kui tal pole juurdepääsu vastavale telefonile. Siit leiab rohkem infot Facebooki kaheastmeline autentimise kohta:
- Introducing Login Approvals (2011)
- What is two-factor authentication and how does it work?
- You Gave Facebook Your Number For Security. They Used It For Ads. (2018)
- When 2FA means sweet FA privacy: Facebook admits it slurps mobe numbers for more than just profile security (2019)
Lisaks nendele lehtedele toetab kaksikautentimist näiteks Apple, Twitter, Wordpress jpt.
Biomeetriline autentimine
Biomeetrilise autentimise alla kuuluvad näiteks sõrmejälgede põhine autentimine, kõnepõhine autentimine ja silmaiirise põhine autentimine.
Näide:
- Sülearvuti sõrmejäljelugeja:
Selleks, et tegu oleks mitmefaktorilise autentimisega tuleks kasutada lisaks kas parooli või autentimist võimaldavat eset.
Autentimine kolmanda osapoole abil
Paroolide haldamise teema juures rääkisime, et parool ei tohiks olla liiga lühike või kergesti ära arvatav ning lisaks sellele ei tohiks sama parooli erinevates kohtades kasutada. Samas on palju erinevaid keerulisi paroole ka tülikas meeles pidada. Siinkohal aitab paroolihaldustarkvara, aga on ka teisi võimalusi. Näiteks pakuvad osad veebilehed võimalust neile ennast tuvastada mõne muu veebilehe kaudu. Sel juhul ei pea kasutaja sellele konkreetsele veebilehele ennast registreerima vaid saab kasutada mõnd enda kontot mõne teise veebilehe juures.
OpenID
OpenID on üks esimesi selliseid kolmanda osapoole kaudu autentimise teenuseid. OpenID puhul on lisaks kasutajale ja veebilehele veel ka kolmas osapool - OpenID teenusepakkuja. Veebileht, millele kasutaja end tuvastada (autentida) tahab, peab antud OpenID teenusepakkujat usaldama. Autentimise protsess näeb välja järgmine (allikas):
- Kasutaja läheb veebilehele, valib autentimise viisiks OpenID ning sisestab oma OpenID tunnuse (tavaliselt meiliaadress või mingi domeeninimi).
- Veebileht suunab kasutaja valitud OpenID teenusepakkuja lehele, kes palub kasutajal end tuvastada. Kui kasutaja on OpenID teenusepakkuja lehele juba sisse logitud, siis minnakse siit automaatselt edasi.
- OpenID teenusepakkuja küsib kasutajalt, kas viimane on ikka nõus end soovitud veebilehele autentima ning kas ta on nõus, et OpenID teenusepakkuja edastab sellele veebilehele infot kasutaja kohta. Info, mida edastatakse, sõltub konkreetsest veebilehest. See võib olla näiteks kasutaja alias, päris nimi, e-posti aadress, postiaadress, asukoht, telefoninumber vms.
- Kui kasutaja on nõus, siis saadab OpenID teenusepakkuja veebilehele kinnituse, et on kasutaja tuvastanud ja paneb kaasa nõutud info kasutaja kohta.
OpenID kasutamiseks peab veebileht, kuhu kasutaja soovib sisse logida, seda tehnoloogiat toeatama ja kasutajal peab olema konto mõne OpenID teenusepakkuja juures, mida antud veebileht usaldab. Viimasel ajal on OpenID kasutajate hulk vähenenud, sest minnakse üle OAuth 2.0 ja OpenID Connect lahendustele, millest järgevalt juttu tuleb. OpenID teenusepakkujad on olnud näiteks Google, Yahoo!, Facebook, AOL, PayPal jt. Lisaks saab oma veebilehe või ajaveebi OpenID identifikaatoriks teha (isikliku veebilehe puhul saab siis kasutada suunamist mõnele olemasolevale usaldatud OpenID teenusepakkujale). Loomulikult peavad kõik ühenduskanalid osapoolte vahel ka krüpteeritud olema.
Eestis on Ideelabor teinud OpenID teenusepakkuja nimega OpenID.ee. Selle teenuse teeb eriliseks asjaolu, et OpenID.ee juures saab kasutaja end autentida Mobiil-ID või ID-kaardi abil. Tänu sellele on autentimist nõudvatel veebilehtedel OpenID.ee teenuse usaldamine lihtsam, kuna isikuandmed (päris nimi ja isikukood) on rangemalt (krüptograafiliselt) sisselogimisel kontrollitud.
OAuth 2.0 ja OpenID Connect
OAuth on sarnane raamistik, mis võimaldab kasutajal autoriseerida üht teenust kasutama tema ressursse mõnes teises teenuses. Siinkohal tuleb vahet teha autentimisel (isikutuvastamine) ja autoriseerimisel (õiguste andmine, volitamine). Et juba OAuth raamistikku toetav teenus saaks enda kaudu ka autentimisteenust pakkuda, on OAuth 2.0 raamistiku peale ehitatud eraldi kiht, OpenID Connect, mis just seda võimaldab.
Kuna OAuth 2.0 ei ole mõeldud tegelikult autentimiseks vaid autoriseerimiseks, siis erineb OAuth 2.0 ja OpenID Connect kasutamine mõneti OpenID kasutamisest. Tõsi, kasutaja jaoks näeb protsess brauseris üsna sarnane välja. Erinevalt OpenID-st ei lase kasutaja mitte OpenID teenusepakkujal saata veebilehele kinnitust kasutaja isiku kohta, vaid autoriseerib (annab õiguse) veebilehte ennast küsima OAuth 2.0/OpenID Connect teenusepakkujalt vajalikku infot antud kasutaja nimel. Siit tuleb välja ka OAuth raamistiku suurem funktsionaalsus - lisaks autentimiseks vajalikele isikuandmetele võib kasutaja autoriseerida veebilehte ka nägema muid ressursse OAuth teenusepakkuja juures. See, millele ligipääs antakse, on kasutaja valida, aga veebileht seab omad miinimumnõuded.
OAuth teenusepakkujad ongi paljud sotsiaalvõrgustikud, millel on peale isikuandmete veel muudki (pildid, nimekiri sõpradest) jagada, näiteks Google, Facebook, Flickr jt. Osaline nimekiri on välja toodud Wikipedias.
Miks peaks veebileht lubama kasutajatel end OpenID või OAuth 2.0/OpenID Connect abil autentida?
Veebilehe jaoks annab kolmanda osapoole kasutamine võimaluse loobuda kasutajate andmebaasi haldamisest. Sealhulgas ei pea veebileht kartma, et kasutajate paroolide räsid lekiksid, sest neid lihtsalt pole selle veebilehe valduses. Viimase pärast annavad OpenID ja OAuth ka kasutajale suurema kindlustunde, sest eraldiseisvad teenusepakkujad panustavad kasutaja andmete (sh paroolide ja muude ressursside) kaitsmisesse rohkem kui suvalised väiksed veebilehed.
Viited
- NIST juhendid
- Blogipostitused
- Artiklid
- Muu