Passkey või parool: andmepüük taandub, kuid konto taastamine jääb nõrgaks

Passkey kaitseb tavalist sisselogimist andmepüügi eest paremini kui parool: võltsdomeen ei saa kasutada teise veebiteenuse jaoks loodud võtit. W3C WebAuthni standard seob sisselogimistõendi teenuse domeeniga ning laseb serveril kontrollida allkirja avaliku võtmega, ilma et privaatvõti serverisse jõuaks.

Konto turvalisus sõltub siiski ka varuteedest. Kui teenus lubab passkey kõrval parooli, uue võtme lisamist nõrgema kontrolliga või ligipääsu taastamist e-posti kaudu, saab ründaja sihtida neid võimalusi. FIDO Alliance’i passkey kasutuselevõtu käsitlus kirjeldab neid teid eraldi riskidena ning märgib, et üksnes passkey kasutamise nõue võib mõne õigustatud kasutaja sisselogimist raskendada.

Mida passkey sisselogimisel muudab?

Parool on saladus, mille inimene veebilehele sisestab. Teenus kontrollib seda tavaliselt serveris hoitava räsi abil. Kui kasutaja annab parooli veenvale petulehele, saab ründaja seda päris teenuses proovida; sama parooli korduv kasutamine võimaldab proovida seda ka mujal. Lisakood võib kahju piirata, kuid õngitsusleht võib küsida ka koodi.

Passkey loomisel tekib teenuse jaoks võtmepaar. Avalik võti registreeritakse teenuses, privaatvõtit kasutab autentikaator seadmes allkirjastamiseks. Enne allkirjastamist kinnitab inimene toimingu näiteks seadme PIN-koodi või biomeetriaga; need andmed ei muutu teenusele sisestatava parooli asendajaks. Brauser ja autentikaator seovad toimingu õige teenuse identiteediga. Seetõttu ei anna lihtsalt sarnase välimusega domeen ründajale tõendit, millega algses teenuses sisse logida.

Kuidas erinevad peamised ohud?

• Andmepüük. Parooli ja ühekordset koodi saab petulehel küsida ning edasi kasutada. Tavalise võltsdomeeni puhul passkeyga sama võte ei tööta. FIDO2 ründeanalüüs leidis siiski teostatavad ründed, kui autentikaator on juba rikutud või ründaja muudab brauseri usaldatud sertifikaadiasutuste loendit; need eeldavad märksa suuremat ligipääsu kui tavaline petuleht.
• Teenuse serveri leke. Parooliräside lekkimine annab ründajale võimaluse nõrku paroole võrguväliselt ära arvata. Passkey puhul hoiab teenus avalikku võtit, millest ei saa iseenesest teha allkirja privaatvõtme nimel. Lekkinud e-posti aadress või kontoteave võib siiski aidata valida taastamisrünnaku sihtmärki.
• Seadme kaotus. Ühte seadmesse seotud võti kaob kasutaja jaoks koos seadmega, kui varuautentikaatorit ei ole. Sünkroonitud passkey võib jõuda teise sobivasse seadmesse, kuid see eeldab ligipääsu võtmehaldurile. Seadme enda ekraanilukk ja võimalus kadunud seade kontolt eemaldada jäävad oluliseks.
• Võtmehalduri või seadme rikkumine. Sünkroonimine lisab teise usalduspiiri: võtmete säilitamise ja uue seadme lubamise halduri juures. Pilvekonto ülevõtmine, pilvetaristu rikkumine ja avatud seadmele ligipääs on erinevad sündmused. Nende tagajärg sõltub võtmehalduri krüpteerimisest, seadmete kinnitamisest ja taastamisreeglitest.

Mis juhtub pärast telefoni kaotust?

Sünkroonitud passkey eelis tuleb esile siis, kui kasutaja saab teises seadmes sama võtmehalduri kaudu oma võtmed taastada. FIDO Alliance’i sünkroonitud võtmete juhend eristab neid seadmega seotud passkey’dest ja kirjeldab tõrkeid, mis tekivad haldurile ligipääsu kaotamisel või sellele mittesobiva seadme kasutamisel. Sünkroonimine parandab seega taastamise võimalust, kuid ei taga seda igas olukorras.

Seadmega seotud FIDO turvavõti pakub teistsugust varu: seda saab hoida telefonist eraldi ja kasutada siis, kui teenus lubab kontole registreerida mitu autentikaatorit. Kui olemas on vaid üks selline võti ja see kaob, peab teenus pakkuma muud viisi isiku tuvastamiseks. Kasutaja jaoks on oluline teada, kas võti asub ainult telefonis, sünkroonitakse halduriga või paikneb eraldi turvavõtmes; sama sõna „passkey” ei ütle kadumise tagajärge ära.

Taastamine ja uue võtme lisamine

Taastamise turvatase määrab, kas sisselogimise eelistest saab kasu kogu konto. Kui e-kirjaga saadetud link annab õiguse parooli lähtestada või uue passkey lisada, muutub postkasti kaitse konto kaitse osaks. SMS-koodiga taastamisel tuleb arvestada koodi õngitsemise võimalusega. Ründaja ei pea privaatvõtit kätte saama, kui tal õnnestub läbida teenuse nõrgem taastamiskontroll.

Uue passkey registreerimine väärib eraldi tähelepanu. Kui teenus lubab seda teha pärast parooliga sisselogimist, võib varastatud paroolist saada püsiva juurdepääsu alus: ründaja lisab oma autentikaatori ja kasutab seda edaspidi. Teenuse omanik saab piirata sellist muutust tugevama korduskinnituse, muudatusest teatamise ja uute võtmete haldamise võimalusega. Rangem kontroll tähendab siiski, et kadunud seadmega õigustatud kasutajal peab olema läbimõeldud taastamistee.

Mida tähendab sõltuvus võtmehaldurist?

Sünkroonitud võtme kaitset ei saa hinnata üksnes selle järgi, et see liigub pilve kaudu. Määrav on, kas teenusepakkuja saab võtmematerjali lugeda, kuidas lubatakse kontole uus seade ja mida nõutakse siis, kui varasemaid seadmeid enam pole. Apple’i iCloud Keychaini turvakirjeldus ütleb, et selle paroolid ja passkey’d sünkroonitakse kasutaja seadmete vahel neid Apple’ile avaldamata ning kaitse on kavandatud toimima ka iCloudi konto või taristu kompromiteerumise korral. See on konkreetse süsteemi ülesehituse kirjeldus, mitte kõigi võtmehaldurite ühine omadus.

Kontrollnimekiri valiku tegemiseks

1. Vaata, kas teenus lülitab pärast passkey lisamist parooliga sisselogimise välja või jätab selle alles. Alles jäetud parool on ka alles jäetud õngitsusvõimalus.
2. Selgita välja, kas kasutatav passkey sünkroonitakse, jääb ühte seadmesse või asub eraldi turvavõtmes. Mõtle läbi, millise teise seadmega saad sisse pärast põhiseadme kaotust.
3. Uuri, millise tõendi alusel saab kontot taastada ja uut passkey’d lisada. Kui selleks piisab e-postist, kaitse postkasti eraldi ning arvesta sellega konto riskihinnangus.
4. Kui teenus toetab mitut autentikaatorit, registreeri sõltumatu varuvõimalus enne, kui seda vaja läheb. Kontrolli, et varuvõimalus sobib ka kasutatavate seadmetega.
5. Teenuse omanikuna jälgi pärast paroolitee muutmist nii edukat sisselogimist kui ka taastamisjuhtumeid. Turvalisem vaikimisi valik toimib vaid siis, kui õigustatud kasutaja saab ligipääsu tagasi ilma nõrga ümbersõiduta.

Loe ka:

• Instagrami konto kaaperdati: taastamine algab e-postist, mitte uuest profiilist
• GitHubi 2FA võib konto lukku jätta — üks varumeetod pole piisav
• Signal või WhatsApp: sõnum on krüpteeritud, metaandmete vahe jääb