MeldID uveo režim panike: što se događa kada povjerenje u pristup računu više nije moguće

U prethodnom članku o MeldID-u opisivao sam kako sustav radi u običnom načinu: pohranjuje upravljani profil, pomaže pri prijavi u povezane servise, sinkronizira TOTP zapise između uređaja i omogućava potvrdu novih autorizacija putem mobilne aplikacije.

No, i svaki sustav identifikacije ima scenarij na koji se obično ne pomisli dovoljno rano: što učiniti ako korisnik više ne vjeruje trenutnom stanju pristupa svom računu?

Za to nije nužno imati već narušenu sigurnost. Ponekad je dovoljno neočekivano pismo o oporavku lozinke, nepoznatom sesionu ili prijavi s uređaja kojeg vlasnik ne prepoznaje.

Za takve situacije u MeldID-u su uvedena dva nova mehanizma: odgođena promjena lozinke i režim panike.

Prvo je važno razumjeti kako je LDL lozinka organizirana

U MeldID-u korisnik ne osmišljava lozinku sam — sustav ju generira. To omogućava odmah eliminirati slabe i predvidljive kombinacije, ponovnu upotrebu uobičajene lozinke i druge probleme povezane s vlastitim odabirom.

Pri tome, važeća lozinka se ne šalje korisniku putem e-pošte. E-mail adresa nije mjesto s kojeg se može dohvatiti postojeća lozinka MeldID-a.

Procedura oporavka također ne otkriva staru lozinku: ona omogućava pokretanje procesa stvaranja nove.

Stoga, kompromitacija e-pošte predstavlja drugu prijetnju: osoba koja je dobila pristup e-pošti ne saznaje važeću lozinku MeldID-a, ali može pokušati pokrenuti proces oporavka i postaviti novu.

Ovaj scenarij bio je jedan od razloga za promjenu same logike oporavka.

Sada se lozinka ne mijenja odmah

U uobičajenom scenariju oporavka, sve se događa gotovo odmah. Korisnik traži novu lozinku, prima poruku i završava proces.

To je prikladno dok je pristup e-pošti u rukama vlasnika. No, ako je pristup stekla treća osoba, trenutni oporavak pretvara e-poštu u direktan put za preuzimanje računa.

U MeldID-u, zahtjev za novom lozinkom prvo postaje upozorenje, a ne trenutna zamjena stare. Korisnik dobiva obavijest o pokušaju oporavka, nakon čega slijedi razdoblje čekanja.

Trajanje tog razdoblja može se mijenjati, no načelo ostaje isto: između zahtjeva i stvarne aktivacije nove lozinke postoji vrijeme za provjere.

Stara lozinka u tom razdoblju zadržava svoju valjanost. Stoga, samo zahtjev za oporavak još ne znači da je kontrola nad računom prešla na treću stranu.

Ako aplikacija nije dostupna

Postoji važan scenarij koji se lako može previdjeti. Korisnik može sam oporavljati lozinku, ali nemati pristup MeldID aplikaciji: telefon je izgubljen, pokvaren, pražnjen ili privremeno nedostupan.

U takvom slučaju, oporavak i dalje može biti dovršen. Nakon što istekne razdoblje čekanja, nova lozinka automatski stupi na snagu. Mobilna aplikacija nije obavezni uvjet za standardni proces oporavka.

Zato, osoba koja je sama pokrenula promjenu lozinke i sada ne može otvoriti aplikaciju, ne mora započinjati postupak iznova: dovoljno je pričekati završetak i prijaviti se s novom lozinkom.

Ako je aplikacija dostupna, mogućnosti su veće: korisnik može odmah aktivirati novu lozinku ili otkazati sumnjivi zahtjev. Ako pristupa nema, i dalje radi odgođeni oporavak.

Korisnik sam odlučuje što dalje

Ukoliko je zahtjev za oporavkom doista pokrenuo vlasnik računa i aplikacija je pri ruci, on može otvoriti MeldID i odmah aktivirati novu lozinku, bez čekanja na kraj razdoblja čekanja.

U slučaju neočekivanog zahtjeva, on ga može otkazati iz aplikacije. U tom slučaju, nova lozinka ne postaje valjana, a prethodna ostaje aktivna.

Za mene je ovo važna promjena u samoj logici oporavka. Sustav ne smatra bilo koji zahtjev automatski valjanim samo zato što je pokrenut putem e-pošte. Vlasniku računa ostavlja se mogućnost interveniranja i donošenja odluke preko pouzdanog mobilnog uređaja.

Zamislimo običnu situaciju: korisnik prima obavijest o promjeni lozinke, a da nije sam zahtijevao takvu promjenu. On otkazuje operaciju u aplikaciji, zatim provjerava e-poštu, uređaje i traži razlog sumnjive aktivnosti.

MeldID ne može vratiti kontrolu nad kompromitiranom e-poštom, ali može spriječiti da kompromitacija povuče automatsku promjenu glavni lozinke računa.

Režim panike povlači aktivne pristupe

Odgođena promjena lozinke pomaže dobiti vrijeme. Režim panike namijenjen je kada to više nije dovoljno i korisnik želi odmah prekinuti izvođenje prethodno odobrenih pristupa računu.

Aktivira se iz mobilne aplikacije jednim dodirom.

Nakon aktivacije, sustav povlači važeće tokene — ključeve pristupa pomoću kojih aplikacije i web stranice prepoznaju da je korisnik već autoriziran. Istovremeno, prekida postojeće sesije na mobilnim uređajima i web platformama povezanima s tim računom.

To znači da prestaju ne samo trenutna sesija na telefonu, već i pristupi na drugim pametnim telefonima, tabletima, preglednicima i povezanim aplikacijama gdje je prethodno izvršena prijava.

Režim traje određeni period, čiji se trajanje može mijenjati, ali važno je načelo: postojeći pristupi se prekidaju, a korisniku se pruža zaštićeno vrijeme za provjere.

Režim panike ne briše podatke

Naziv režima može zvučati drastično, pa je važno razjasniti što on ne čini.

Režim panike ne briše TOTP zapise, spremljene profile, postavke niti bilo koje korisničke podatke. On ne čisti sadržaj računa i ne pretvara ga u prazan.

Stanje pristupa mijenja se: važeći tokeni se povlače, a otvorene sesije se prekidaju. Nakon povratka računa u normalan režim, spremljeni podaci ostaju netaknuti i ne zahtijevaju ponovno dodavanje.

Ovo je ključno razilaženje između hitnog prekida pristupa i trajnog brisanja sadržaja računa. Korisnik može zatvoriti postojeće veze, ne bojeći se da će mu pritom nestati zapisi ili postavke.

Što se događa s promjenom lozinke tijekom panike

Režim panike ima još jedno važno pravilo: on prekida sve nedovršene pokušaje promjene lozinke.

Nije važno kada je zahtjev za novom lozinkom podnesen — prije aktivacije režima panike ili za vrijeme trajanja istog. Takav zahtjev se ne može automatski dovršiti nakon završetka režima zaštite.

Po završetku panike, važeća ostaje lozinka koja je bila postavljena prije aktivacije.

To je namjerno tako.

Obična procedura oporavka namijenjena je tome da vlasnik računa može uočiti sumnjivi zahtjev u MeldID-u i ga otkazati prije nego nova lozinka stupi na snagu.

Za vrijeme panike, taj scenarij više nije pouzdan.

Zamislimo da je korisnik primijetio sumnjivu aktivnost i aktivirao zaštitni režim. Ako bi tada dozvolio normalnom tajmeru oporavka da radi, zlonamjernik bi mogao zahtijevati novu lozinku za vrijeme panike. Ako bi razdoblje čekanja završilo prije samog završetka režima, nova lozinka bi još mogla stupiti na snagu prije nego se račun vrati u normalu.

Pojavio bi se paradoks: korisnik je aktivirao pojačanu zaštitu, ali baš u tom razdoblju sustav bi mogućio promjenu lozinke, ne dajući vlasniku da ga otkaže putem aplikacije.

Zato panika ne pauzira oporavak, već prekida nedovršeni proces.

Zahtjevi podneseni prije aktiviranja panike neće moći promijeniti lozinku nakon završetka režima. Isto vrijedi i za zahtjeve nastale tijekom trajanja režima zaštite.

Stoga, ništa od nedovršenog oporavka ne prenosi se preko granice panike.

A ako korisnik želi prvo promijeniti lozinku

Režim panike ne ograničava vlasnika u izboru slijeda koraka.

Ako pristup aplikaciji MeldID postoji i smatra da je lozinka također potrebna promjena, on može najprije pokrenuti promjenu lozinke i odmah potvrditi novu preko aplikacije.

U tom slučaju, promjena završava prije aktivacije panike.

Nakon toga, korisnik aktivira zaštitni režim s novom važećom lozinkom. Taj će lozinku zadržati nakon završetka panike.

Druga opcija je: prvo aktivirati paniku, istražiti uzrok sumnjive aktivnosti, a po završetku, ako je potrebno, pokrenuti novu promjenu lozinke.

Svrha mehanizma nije prisiliti korisnika na određeni redoslijed postupaka. Glavnog pravila: nedovršena promjena lozinke ne smije preživjeti režim panike.

Panika pruža vrijeme za povrat kontrole nad e-poštom

Postoji scenarij gdje je ovaj mehanizam posebno važan: korisnik misli da problem nije u MeldID-u niti u uređaju, već u e-pošti.

To je zbog toga što se e-pošta koristi kao jedan od kanala za oporavak. Stoga je njezina kompromitacija opasna čak i kada je važeća lozinka MeldID-a nepoznata trećoj osobi.

U takvoj situaciji, korisnik može aktivirati režim panike i fokusirati se na samu prijetnju: povrat pristupa e-pošti, promjenu lozinke, zatvaranje nepoznatih sesija i provjeru sigurnosnih postavki.

Tijekom trajanja panike, MeldID ne omogućava stvaranje nove važeće lozinke oporavkom.

Akcije koje je netko već podnio prije aktivacije panike neće proći. Ako nova oporavka zahtijeva za vrijeme panike, njezin će ishod biti isti.

Stvara se zaštićeni vremenski interval: aktivni pristupi MeldID-a su povučeni, kompromitirana e-pošta ne može služiti za pripremu nove lozinke do završetka panike, a vlasnik dobiva vrijeme za povrat kontrole nad e-poštom.

Nakon završetka režima zaštite, važeća ostaje stara lozinka MeldID. Ako je kontrola nad e-poštom ponovo uspostavljena i nema drugih problema, korisnik može ponovno koristiti račun u normalnom režimu.

Ako odluči promijeniti i lozinku MeldID-a, to može učiniti zasebno.

Razlozi za aktiviranje panike mogu biti mnogi

Za pokretanje režima nije potrebno prvo dokazati da je došlo do napada. Telefon je mogao pasti u ruke nepoznate osobe. Na popisu uređaja pojavila se nepoznata sesija. Korisnik je mogao dobiti neočekiveno obavještenje o pristupu ili oporavku. Ponekad se sumnja javlja ne zbog jednog očiglednog događaja, već zbog niza malih znakova.

U takvim okolnostima, nije uvijek potrebno prvo provesti detaljnu istragu. Ponekad je razumijevanje da je najbolje najprije privremeno povući aktivne pristupe, a tek potom provjeriti detalje.

MeldID se temelji na jednostavnoj logici: ako vlasnik računa smatra da je situacija opasna i ima pristup pouzdanoj aplikaciji, treba imati mogućnost odmah aktivirati zaštitni scenarij. Sustav ne zahtijeva prvo dokazivanje napada.

Zašto jedna promjena lozinke često nije dovoljna

Lozinka je samo jedan od elemenata autorizacije. Ako je već aktivna sesija ili je izdana pristupna token, promjena same lozinke sama po sebi nije isto što i povlačenje svih prethodno izdanih pristupa.

Stoga, režim panike djeluje šire: ne samo što mijenja jedan parametar profila, već stavlja cijeli račun u poseban sigurnosni režim.

Redoslijed je sljedeći:

1. Aktivne sesije i tokeni se povlače;

2. Nedovršeni pokušaji promjene lozinke, pokrenuti prije panike, se prekidaju;

3. Zahtjevi za oporavak tijekom panike više ne mogu promijeniti lozinku nakon njenog završetka;

4. Valjana ostaje lozinka s kojom je račun ušao u režim panike;

5. Korisnik dobiva vrijeme za provjeru e-pošte, uređaja i drugih izvora problema;

6. Nakon izlaska iz zaštitnog režima, vraća se na normalni rad ili može zasebno promijeniti lozinku.

Ovo nije zamjena za uobičajene sigurnosne mehanizme, već zaseban hitni scenarij za situaciju kada je povjerenje u trenutni pristup privremeno izgubljeno.

Mobilna aplikacija kao pouzdana točka

Nova funkcionalnost dostupna je u MeldID aplikacijama za iPhone i Android. U toj arhitekturi, telefon postaje ne samo još jedno uređaj za pristup, već pouzdana točka upravljanja sigurnošću računa.

Pomoću aplikacije možete:

• potvrditi odgođeno promjenu lozinke;

• otkazati sumnjivi zahtjev;

• aktivirati režim panike;

• prekinuti aktivne sesije na različitim uređajima;

• odrediti što će se događati s računom nakon toga.

Pri tome, mobilna aplikacija ne ukida TOTP i ne zamjenjuje druge metode zaštite. Ona dodaje poseban kanal upravljanja za situacije kada obična autorizacija više nije dovoljna za sigurnost računa.

Gdje prolazi granica zaštite MeldID-a

Važno je razlučiti sigurnost samog mehanizma MeldID-a i sigurnost okoline u kojoj se koristi.

MeldID je tako konstruiran da sam servis ne stvara uobičajeni kanal za dohvat važeće lozinke. Lozinka se generira sustavom, ne odabire se od strane korisnika i ne prenosi putem e-pošte. Oporavak također ne otkriva postojeću lozinku, već pokreće postupak njenog stvaranja nove.

No, korisnik još uvijek može samotvo otkriti svoje podatke, na primjer prosljeđivanjem drugoj osobi ili unutar mjesta gdje to nije trebalo učiniti.

Viši sloj je sigurnost samog uređaja i operacijskog sustava. Mobilna aplikacija radi unutar zaštitnih mehanizama iOS-a i Androida, i ne može zamijeniti sigurnost same platforme.

Zbog toga, MeldID je fokusiran na rizike kojima može upravljati s svoje strane: generiranje podataka, autorizaciju, tokene, sesije, oporavak i reakcije na potencijalne pokušaje kompromitacije kanala za oporavak.

Od prijave do reakcije

Kada sam prvi put upoznao MeldID, mogao sam ga opisati kao sustav jedinstvene identifikacije i upravljanja profilom. No, nakon izlaska mobilnih aplikacija i pojave novih zaštitnih mehanizama, ta definicija postala je previše uska.

Sada sustav odgovara ne samo na pitanje „kako se prijaviti?“, već i na složenija pitanja:

• što učiniti pri neočekivanom zahtjevu oporavka;

• kako obnoviti račun bez pristupa aplikaciji;

• kako dobiti vrijeme za provjeru prije aktivacije nove lozinke;

• kako otkazati oporavak koji nije pokrenuo vlasnik;

• kako povući aktivne sesije;

• kako spriječiti da kompromitirana e-pošta promijeni lozinku tijekom hitnog režima;

• kako povratiti kontrolu nad vanjskim kanalima oporavka;

• kako sačuvati korisničke podatke nakon prekida svih aktivnih pristupa;

• kako se vratiti u normalan rad nakon provjere situacije.

Kao rezultat, nastaje sekvencijalni sigurnosni model.

Valjana lozinka MeldID-a se ne prenosi kanalima oporavka. Pristup e-pošti sam po sebi ne otkriva lozinku, ali može omogućiti pokretanje postupka stvaranja nove. Zato se oporavak odvija sa odgodom i može ga otkazati pouzdana aplikacija.

A ako ni to nije dovoljno, režim panike prekida aktivne sesije, opoziva tokene i ne dopušta da nedovršeni proces oporavka preživi zaštitno razdoblje.

Korisnik dobiva ono što je izrazito važno u slučaju incidenta: vrijeme.

Vrijeme za povrat kontrole nad e-poštom, provjeru uređaja, istraživanje situacije i tek nakon toga ponovno otvaranje normalnog pristupa računu.

Stoga, režim panike u MeldID-u nije samo gumb „Izađi svugdje“. To je poseban scenarij reagiranja u situaciji kada obična autorizacija više nije dovoljna i potrebno je najprije povratiti povjerenje u okolinu računa.

Više o projektu: meldid.de.