Autentimine

Seega kasutaja autentimiseks on kolm eraldiseisvat võimalust:

1. Teave.
   • Midagi, mida ainult antud kasutaja teab, näiteks parool.
2. Millegi omamine.
   • Midagi, mis ainult antud kasutajal on, näiteks kiipkaart.
3. 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.

Probleemi illustreerimiseks saate külastada lehekülge, mis ennustab parooli murdmiseks kuluvat aega kui murdmiseks kasutatakse ühte lauaarvutit: https://www.security.org/how-secure-is-my-password/. Ä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:

1. 123456
2. parool
3. qwerty
4. 123456789
5. lammas
6. 12345
7. minaise
8. maasikas
9. kallis
10. killer
11. armastus
12. lollakas
13. samsung
14. 123123
15. teretere
16. lilleke
17. martin
18. 12345678
19. kiisuke
20. 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 veebilehed 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 ja kasutavad muid algoritmilisi trikke, mis muudavad ründajal paroolide arvamise oluliselt ajakulukamaks. Näited sellistest funktsioonidest on Argon2, PBKDF2, scrypt, bcrypt jt.

Näited: 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.

Allikas: XKCD koomiks

Ü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).

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

Aja puudusel tutvustame loengu käigus ainult mõnda kaksikautentimise meetodit. Parema ülevaate saamiseks soovitame lugeda EFF-i ülevaadet, mis kirjeldab levinumaid kahefaktorilisi autentimisviise: 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. Sellest kuidas tehniliselt ID-kaardiga autentimine toimib on kirjutatud ID-kaardi kohta käivates loengumaterjalides.

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:

• ID.ee: Kadunud ID-kaart
• PPA: Kui isikut tõendav dokument kaob

Ü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 viimane 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 enda 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:

• Swedbank: PIN-kalkulaatori kasutusjuhend
• SEB PIN-kalkulaatori kasutusjuhend
• LHV: PIN-kalkulaatori kasutusjuhend

Autentimine riistvaralise pääsmiku abil

Riistvaraline pääsmik võimaldab genereerida krüptovõtmeid ning neid turvalise riistvaraseadme sees endaga kaasas kanda või säilitada. Enamasti on niisugused seadmed väiksed ja ühenduvad arvutiga läbi USB või NFC liidese. Nende poolt pakutavad võtme salvestamise turvaomadused on sarnased ID-kaardi poolt pakutavatele. Seadmel olevate krüptovõtmete kasutamiseks on vaja füüsilist juurdepääsu vastavale seadmele. Kui krüptovõtit pole võimalik kopeerida, siis ei saa ka arvutis olev pahavara teha sellest koopiat.

Hea ülevaate niisuguste seadmete kasutamiseks annab järgnev artikkel: Getting started with security keys. Riistvaralisi võtmehoidjad müüb näiteks Rootsi ettevõte Yubico ning nende toote nimeks on YubiKey. Siinjuures on oluline, et Yubico toodab oma seadmeid ise vastavalt Rootsis ja USA-s. Seeläbi vähenevad tarneahelega seonduvad turvariskid. Kui hakata niisugust seadet ostma, siis võiks osta pigem kaks tükki, et tagada töökindlust juhul kui ühe seadmega midagi juhtub (tuleb seadistada kohe kaks seadet, täpsem info on eelnevalt viidatud juhendis).

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:

• Google 2FA sissejuhatus
• Google konto seadistamine

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:

• 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)

Muud veebilehed ja teenused

Lisaks Google-le ja Facebookile toetab kaksikautentimist näiteks Apple, Twitter, Wordpress jpt. Veebileht https://2fa.directory/ sisaldab nimekirja erinevatest teenustest, mis võimaldavad kasutada kaksikautentimist.

Biomeetriline autentimine

Biomeetrilise autentimise alla kuuluvad muuhulgas näiteks sõrmejälgede põhine autentimine, kõnepõhine autentimine ja silmaiirise põhine autentimine. Biomeetriat kasutatakse pigem mugavuse huvides, kuna turvalisuse osas on sellega mitmeid probleeme. Näiteks sõrmejälgi ja häält on lihtne kopeerida. Samuti on tänapäeval probleemiks nn. deepfake loomine, mistõttu pole videolt isiku tuvastamine enam triviaalne. Kasutaja privaatsuse seisukohalt on biomeetria kasutamine väga küsitava väärtusega, sest biomeetrilisi tunnuseid ei saa muuta. Seega on eriti oluline vältida biomeetriliste andmete lekkimist, mistõttu tuleks hoolega mõelda, et missuguseid biomeetrilisi andmeid teenusepakkujatega jagada.

Biomeetriat kasutades on peaaegu alati kasutusel ka tagavarameetod, mis võimaldab kasutajat tuvastada ka siis kui biomeetria alt veab. Näiteks alati ei pruugi sõrmejälje lugemine õnnestuda ning siis võidakse küsida selle asemel PIN-koodi. Seetõttu ei tohi kindlasti kasutada nõrka PIN-koodi, sest ründaja saab ignoreerida biomeetrilist autentimist ning proovida hoopis PIN-koodi ära arvata.

Biomeetria kasutamise eelis tuleb välja näiteks nutiseadme kasutamisel rahvarohketes kohtades kus ei ole sobilik PIN-koodi või parooli sisestada (sama ka kaamera olemasolu korral). Näiteks sõrmejäljepõhise autentimise kasutamine võib aidata ära hoida PIN-koodi või parooli lekkimist ühistranspordis või loengus. Samas on sõrmejälje kopeerimine lihtne ning see toob omakorda kaasa järgmise probleemi. Sõrmejälge saab kopeerida ka fotolt juhul kui fotograafil õnnestub pildistada sõrmi (foto peab olema väga hea kvaliteediga). Seega jälle näeme, et vaja on leida tasakaal ning absoluutse turvalisuse leidmine polegi võimalik. Järelikult oleks optimaalne rahvarohkes kohas üldse mitte oma nutiseadet kasutada, sest isegi kui parooli / PIN-koodi / sõrmejälge ei õnnestu kopeerida, siis võidakse näha ja kopeerida näol kuvatavat infot.

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.

OAuth 2.0 ja OpenID Connect

OAuth on raamistik, mis võimaldab kasutajal delegeerida üht teenust kasutama tema ressursse mõnes teises teenuses. Siinkohal tuleb vahet teha autentimisel (isikutuvastamine) ja delegeerimisel (õiguste üleandmine). 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.

OAuth 2.0 ja OpenID Connect lihtsustatud töövoog (tegelikkuses on kaks eraldi serverit, üks volituste andmiseks ja teine kus on ressursid, mille kasutust delegeeritakse):

1. Kasutaja läheb veebilehele, kuhu soovib kolmanda osapoole abil sisse logida või mida soovib delegeerida oma ressursse kasutama. Veebileht võib toetada mitut sellist teenusepakkujat ja kasutaja valib endale sobiva (sellise, kus tal juba konto eksisteerib).
2. Veebileht suunab kasutaja valitud OAuth 2.0/OpenID Connect teenusepakkuja lehele, kes palub kasutajal end tuvastada. Kui kasutaja on selle teenusepakkuja lehele juba sisse logitud, siis minnakse siit automaatselt edasi.
3. Autentimise (st OpenID Connect) puhul küsib teenusepakkuja kasutajalt, kas viimane on ikka nõus end soovitud veebilehele autentima ning kas ta on nõus, et 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.
   • Kuna OAuth 2.0 on siiski delegeerimisraamistik, siis 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.
4. Kui kasutaja on nõus, siis saadab teenusepakkuja veebilehele (kasutaja veebilehitseja kaudu) volituskoodi (authorization code). Autentimise puhul koostab ja allkirjastab teenusepakkuja lisaks ka tõendi, kus on kirjas küsitud kasutaja profiili andmed. Autentimise korral sellega töövoog lõppeb.
5. Veebiteenus võtab teenusepakkujaga ühendust (otse, mitte läbi kasutaja veebibrauseri) ja vahetab volituskoodi pääsutalongi (access token) vastu.
6. Pääsutalongi abil pääseb veebiteenus ligi kasutaja ressurssidele (nt fotod, kontaktide nimekiri) teenusepakkuja serveris.

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 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 annab OpenID Connect ka kasutajale suurema kindlustunde, sest eraldiseisvad teenusepakkujad panustavad kasutaja andmete (sh paroolide ja muude ressursside) kaitsmisesse rohkem kui suvalised väiksed veebilehed.

Lisamaterjalid - MIT autentimise loeng

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.

Viited

• NIST juhendid
  • NIST: Digital Identity Guidelines (2017)
  • NIST: Digital Identity Guidelines - Enrollment and Identity Proofing (2017)
  • NIST: Digital Identity Guidelines - Authentication and Lifecycle Management (2017)
  • NIST: Digital Identity Guidelines - Federation and Assertions (2017)
• Blogipostitused
  • iOS Privacy: steal.password - Easily get the user's Apple ID password, just by asking (2017)
  • The man who put us through password hell regrets everything (2017)
  • The Market for Stolen Account Credentials (2017)
• Artiklid
  • Why Do Developers Get Password Storage Wrong? A Qualitative Usability Study (2017)
  • The Password Reset MitM Attack (2017)
• Paroolihaldurid
  • Firefox - password manager
  • Google Chrome - password manager
  • Why passwords have never been weaker—and crackers have never been stronger (2012)
  • The secret to online safety: Lies, random characters, and a password manager (2013)
  • Websites, Please Stop Blocking Password Managers. It’s 2015 (2015)
  • You Gave Facebook Your Number For Security. They Used It For Ads. (2018)
• Muu
  • Pääsmik ehk füüsiline identsustõend
  • Password Guidance: Simplifying Your Approach (2016)
  • A Guide to Common Types of Two-Factor Authentication on the Web (2017)