MeldID lisäsi hätätila-tilan: mitä tapahtuu, kun tilille ei enää voi luottaa

Edellisessä artikkelissani MeldID:stä kerroin, kuinka järjestelmä toimii normaalisti: se tallentaa hallittavan profiilin, auttaa kirjautumisessa yhdistettyihin palveluihin, synkronoi TOTP-tallenteet laitteiden välillä ja mahdollistaa uusien valtuutusten vahvistamisen mobiilisovelluksen kautta.

Mutta kaikissa tunnistusjärjestelmissä on lopulta skenaario, johon muistetaan usein vasta liian myöhään: mitä tehdä, jos käyttäjä ei enää luota nykyiseen pääsytilanteeseensa?

Ei tarvitse edes tietää, että järjestelmää on hakkeroitu. Joskus riittää yllättävä viesti palautettavasta salasanasta, epäilyttävä istunto tai sisäänkirjautuminen laitteella, jota käyttäjä ei tunnista.

Näihin tilanteisiin on nyt jotenkin ratkaisuna kaksi uutta mekanismia MeldID:ssä: viivästetty salasanan vaihto ja hätätila.

On ensin ymmärrettävä, miten MeldID:n salasana on muodostettu

MeldID:ssä käyttäjä ei keksi salasanaa itse — järjestelmä generoi sen. Tämä poistaa heti pienet ja ennustettavat yhdistelmät, salasanan uudelleen käytön tai muut ongelmat, jotka liittyvät käyttäjän valitsemiin salasanoihin.

Samaan aikaan voimassa oleva salasana ei lähetä käyttäjälle sähköpostitse. Sähköpostissa ei siis ole tietoa nykyisestä MeldID-salasanasta.

Palautusprosessi ei myöskään paljasta vanhaa salasanaa, vaan mahdollistaa uuden luomisen.

Jos sähköposti kuitenkin vaarantuu, uusi uhka on toinen: henkilö, joka saa pääsyn sähköpostilaatikkoon, ei näe nykyistä MeldID-salasanaa, mutta voi yrittää käyttää palautusprosessia ja asettaa uuden.

Juuri tämä skenaario oli yksi syy muuttaa palautuslogiikkaa.

Salasana ei enää muutu heti

Normaalisti palautus tapahtuu lähes välittömästi: käyttäjä pyytää uutta salasanaa, saa viestin ja vahvistaa sen.

Tämä on kätevää, kun sähköposti on vain käyttäjän hallussa. Mutta jos joku toinen ehtii saada siihen pääsyn, välitön palautus antaa suoran reitin tilille.

MeldID:ssä uusi salasana ei vielä automaattisesti tule voimaan pyynnön tekemisen jälkeen. Sen sijaan pyynnöstä saatava muistutus ikään kuin varoittaa ja antaa odotusaikaa.

Tämän odotusajan pituus voi muuttua, mutta periaate pysyy samana: pyynnön ja uuden salasanan aktivoinnin välillä on aikaa arvioida tilannetta.

Silloin vanha salasana pysyy voimassa. Palautus ei siis vielä tarkoita sitä, että tilin hallinta siirtyy toiselle osapuolelle.

Jos sovellus ei ole käytettävissä

On tärkeää muistaa myös tällainen skenaario: käyttäjä voi palauttaa salasanaa, mutta ilman pääsyä MeldID-sovellukseen — vaikka puhelin olisi kadonnut, rikki, loppuun käytetty tai tilapäisesti poissa käytöstä.

Tällöin palautus silti onnistuu: odotetun ajan päätyttyä uusi salasana tulee voimaan automaattisesti. Normaali palautusprosessin ei edellytä mobiilisovellusta.

Jos käyttäjällä ei ole sovellusta saatavilla, hän voi silti tehdä uuden salasanan vahvistamisen. Tällöin ei tarvitse aloittaa prosessia uudelleen, vaan odottaa loppuun ja käyttää uutta salasanaa.

Jos sovellus on käytössä, mahdollisuudet lisääntyvät: käyttäjä voi välittömästi aktivoida uuden salasanan tai peruuttaa epäilyttävän pyynnön. Jos sovellusta ei ole, jatkuu normaali viivästetty palautus.

Käyttäjä päättää itse, mitä hän tekee

Jos palautus todella on tiliomistajan aloittama ja sovellus on käden ulottuvilla, hän voi avata MeldID:n ja aktivoida uuden salasanan heti, odottamatta odotusajan päättymistä.

Jos pyyntö yllättää, sen voi peruuttaa sovelluksessa. Tällöin uusi salasana ei tule voimaan, ja vanha jää käyttöön.

Oma mielestäni tämä on suuri muutos palautuslogiikassa: järjestelmä ei automaattisesti hyväksy jokaisen palautuspyynnön vain sähköpostin kautta, vaan antaa käyttäjälle mahdollisuuden puuttua ja tehdä päätös luotetusta laitteesta.

Kuvitellaan tilanne: käyttäjä saa ilmoituksen salasanan muutoksesta, vaikka hän ei ole pyytänyt sitä itse. Hän peruuttaa toimenpiteen sovelluksessa ja alkaa tarkistaa sähköpostin, laitteet ja epäilyttävän toiminnan.

MeldID ei voi palauttaa hallintaa kompromettoituneeseen sähköpostiin, mutta se ei myöskään salli heti tämän vuoksi uuden salasanan asettamista päätilille.

Hätätila peruuttaa aktiiviset pääsyt

Viivästetty salasanan vaihto antaa aikaa. Hätätila on tarkoitettu tilanteeseen, jossa tämä ei enää riitä ja käyttäjä haluaa heti lopettaa aiemmin annettujen pääsyoikeuksien toiminnan.

Käynnistetään sovelluksesta yhdellä toimenpiteellä.

Aktivoinnin jälkeen järjestelmä peruuttaa voimassa olevat tunnukset — avaimet, joita sovellukset ja sivustot käyttävät tunnistaakseen käyttäjän valtuutuksen. Samalla lopetetaan nykyisten istuntojen toiminta mobiililaitteilla ja verkkosivustoilla.

Tämä tarkoittaa, ettei vain nykyinen istunto puhelimella lopu, vaan myös toiset älypuhelimet, tabletit, selaimet ja sovellukset, joissa kirjautuminen on tehty, sammutetaan.

Hätätila kestää ennalta asetetun ajan. Sen kesto voi vaihdella, joten tärkeintä on periaate: olemassa olevat pääsyt estetään ja käyttäjälle annetaan suojaaikaa tilanteen tarkistamiseen.

Hätätila ei poista tietoja

Nimi saattaa kuulostaa jyrkältä, mutta tässä on tärkeää selittää, mitä se ei tee.

Hätätila ei poista TOTP-tallenteita, tallennettua profiilia, asetuksia tai muita käyttäjätietoja. Se ei tyhjennä sisältöä eikä tee tilistä tyhjäksi.

Se vain peruuttaa voimassa olevat pääsyt: nykyiset tunnukset poistetaan käytöstä ja istunnot katkaistaan. Palautuksen jälkeen tallennetut tiedot pysyvät paikallaan eikä niitä tarvitse uudelleen lisätä.

Tämä on ratkaiseva ero hätätilan ja tietojen tuhonnin välillä. Käyttäjä voi sulkea olemassa olevat yhteydet huoletta, ilman että hänen tallenteitaan tai asetuksiaan häviää samalla.

Mitä tapahtuu salasanan vaihdolle hätätilassa

Hätätila lopettaa myös kaikki kesken olevat salasanan vaihtopyynnöt.

Ei ole merkitystä, milloin uusi salasana oli pyydetty — ennen kuin hätätila asetettiin vai sen aikana. Tällainen pyyntö ei voi automaattisesti päättyä palautustilaan.

Hätätilan päätyttyä jatkuu edelleen salasana, joka oli voimassa ennen tilan aktivointia.

Tämä on tarkoituksella tehty.

Normaalisti palautus perustuu siihen, että käyttäjä näkee mahdollisen epäilyttävän pyynnön MeldID-sovelluksessa ja voi peruuttaa sen ennen kuin uusi salasana astuu voimaan.

Hätätilassa tähän ei enää voi luottaa.

Kuvitellaan, käyttäjä huomaa epäilyttävää toimintaa ja ottaa käyttöön hätätilan. Jos samalla sallitaan normaalin palautusajan jatkuminen, hyökkääjä voi pyytää uutta salasanaa hätätilan aikana. Jos odotusaika loppuu ennen kuin tila palautuu normaaliksi, uusi salasana ehtii voimaan ennen kuin tilin tilanne palaa ennalleen.

Tässä tulisi paradoksi: käyttäjä aktivoi vahvistetun suojauksen, mutta samana aikana järjestelmä sallii salasanan muuttamisen, eikä omistajalle jää mahdollisuutta peruuttaa sitä sovelluksesta.

Tästä johtuen hätätila ei pysäytä palautusprosessia odottamaan, vaan katkaisee sen lopullisesti.

Pyynnöt, jotka olivat olemassa ennen hätätilan aktivointia, eivät voi muuttaa salasanaa palautusajan päätyttyä. Sama koskee myös tilanteita, joissa pyynnöt ilmestyvät hätätilan aikana.

Ei siis siirry mitään kesken olevia palautusprosessit yli hätätilarajan.

Entä jos käyttäjä haluaa itse ensin muuttaa salasanan

Hätätila ei rajoita omistajan valinnanvapautta.

Jos käyttäjällä on MeldID-sovellus käytettävissä ja hän haluaa vaihtaa salasanan, hän voi ensin käynnistää salasanan vaihdon ja vahvistaa uuden sovelluksessa.

Myös tämä lopettaa salasanan vaihdon ennen hätätilan aktivointia.

Sitten hän aktivoi hätätilan uudella salasanalla — ja tämä salasana pysyy voimassa hätätilan päätyttyä.

Vaihtoehtoisesti voi ensin käynnistää hätätilan, selvittää epäilyttävän toiminnan syyt ja tarvittaessa aloittaa uuden salasananvaihdon sen jälkeen.

Ydin ei ole siinä, että käyttäjän tulisi toimia vain yhdessä tietyssä järjestyksessä. Tärkeintä on, että kesken jäänyt salasana-aktivointi ei voi elää yli hätätilan.

Hätätila antaa aikaa palauttaa hallinta sähköpostiin

On olemassa skenaario, jossa tämä mekanismi on erityisen tärkeä: käyttäjä uskoo ongelman olevan ei MeldID:ssä eikä edes puhelimessa, vaan sähköpostissa.

Sähköposti toimii nyt palautuskanavana, ja sen kompromettio on vaarallista, vaikka nykyinen salasana MeldID:ssä pysyy tuntemattomana.

Tällöin käyttäjä voi aktivoida hätätilan ja keskittyä itse sähköpostin hallintaan: palauttaa pääsyn sähköpostitiliin, vaihtaa salasanan, lopettaa epäilyttävät istunnot ja tarkistaa asetukset.

Hätätilan aikana MeldID ei salli palautusprosessin luoda uutta toimivaa salasanaa.

Jos joku on jo ehtinyt tehdä palautuspyynnön ennen hätätilan aktivointia, tämä pyyntö ei kestä hätätilan suojaa. Jos uusi pyyntö ilmestyy hätätilan aikana, tulos on sama.

Se antaa suojaavan hetkellisen ikkunan: nykyiset MeldID-käyttöoikeudet ovat peruutettuja, mahdollisesti kompromettoitu sähköposti ei voi enää auttaa uuden salasanan luomisessa, ja omistajalla on aikaa palauttaa sähköpostin hallinta.

Hätätilan päätyttyä edelleen voimassa oleva salasana on entinen MeldID-salasana. Jos sähköpostin hallinta palautuu ja muita ongelmia ei ole, käyttäjä voi taas käyttää tiliä normaalisti.

Jos hän haluaa muuttaa sitä tai muuta salasanaa, voi tehdä sen myös erikseen.

Miksi toimintaa hätätilassa kannattaa käynnistää

Eikä edellytä käyttäjältä todistaa ensin, että tili on hakkeroitu.

Puhelin on voinut joutua vääriin käsiin. Laite on voinut näyttää epäilyttäviä istuntoja. Käyttäjä voi saada odottamattoman ilmoituksen kirjautumisesta tai palautuksesta. Vähän epäilyttävää toimintaa ei aina tarvitse epäillä yhden tapahtuman vuoksi, vaan riittää, että koko joukko pieniä merkkejä viittaa mahdolliseen uhkaan.

Tällaisissa tilanteissa ei aina tarvitse tehdä heti tutkimuksia, vaan on usein järkevämpää ensiksi peruuttaa aktiiviset pääsyt ja tarkistaa tilanteen yksityiskohtaisesti myöhemmin.

MeldID:n logiikka on yksinkertainen: jos omistaja pitää tilannetta vaarallisena ja hänellä on pääsy luotettavaan sovellukseen, hän voi heti käynnistää suojelutoimenpiteen. Järjestelmä ei vaadi vielä allekirjoitettua hyökkäystä.

Miksi salasanan vaihtaminen yksin ei riitä

Salasana on vain yksi osa todennusta. Jos jossain on jo aktiivinen istunto tai annettu pääsytunnus, yhden salasanan muuttaminen ei ole sama asia kuin kaikkien aiempien pääsyoikeuksien peruuttaminen.

Siksi hätätila toimii laajemmin: se ei vain muuta yhtä parametria, vaan asettaa koko tilin eristystilaan.

Tiivistettynä, prosessi on seuraava:

1. nykyiset istunnot ja tunnukset peruutetaan;

2. keskeytyneet salasanan vaihto-/ostospyynnöt lopetetaan;

3. hätätilan aikana tehdyt palautuspyynnöt eivät voi muuttaa salasanaa päätyttyä;

4. käytössä on ennen hätätilaa ollut salasana;

5. käyttäjä saa aikaa tarkistaa sähköpostin, laitteet ja muut ongelma-alueet;

6. tilin normaali avautuminen tai uuden salasanan asettaminen tapahtuu vasta hätätilan päätyttyä.

Tämä ei korvaa normaaleja turvallisuustoimia, vaan on hätätilaskenaario, joka aktivoituu, kun luottamus tilin nykyiseen tilanteeseen on hetkellisesti menetetty.

Älypuhelin luotettuna hallintapisteenä

Uudet ominaisuudet ovat käytettävissä MeldID-sovelluksissa iPhonelle ja Androidille. Tässä arkkitehtuurissa puhelin ei ole enää vain järjestelmän toinen pääte, vaan luotettu hallintayksikkö tilin turvallisuudelle.

Sovelluksella voi:

• vahvistaa viivästetyn salasanan vaihdon;

• peruuttaa epäilyttävän pyynnön;

• käynnistää hätätilan;

• peruuttaa aktiiviset istunnot eri laitteissa;

• määritellä, mitä tiliin tapahtuu seuraavaksi.

Tämä ei kuitenkaan poista TOTP-tallenteita eikä korvaa muita suojauskeinoja. Se lisää erillisen hallintakanavan tilanteisiin, joissa tavallinen kirjautuminen ei enää riitä luottamuksen varmistamiseen.

Mistä MeldID:n suojausraja kulkee?

On tärkeää erottaa MeldID:n järjestelmän turvallisuus ja laitteen, jolla sitä käytetään, turvallisuus.

MeldID:n suunnittelu on siten, että palvelu ei luo normaalia kanavaa aktiivisen salasanan saamiseen. Salasana generoidaan järjestelmän toimesta, sitä ei valita käyttäjän eikä sitä lähetetä sähköpostitse. Palautus ei paljasta nykyistä salasanaa, vaan aloittaa uuden salasanan luomisen prosessin.

Kuitenkin käyttäjä voi edelleen paljastaa tunnistetietonsa itse, esimerkiksi luovuttamalla ne toiselle tai syöttämällä väärissä paikoissa.

Toinen taso on itse laitteen ja käyttöjärjestelmän turvallisuus. Mobiilisovellus toimii iOS:n ja Androidin suojausmekanismien sisällä eikä voi korvata koko laitetason turvallisuutta.

Siksi MeldID keskittyy niihin riskeihin, joita käyttäjän hallinnassa on: tietojen generointiin, todennukseen, tunnuksiin, istuntoihin, palautukseen ja mahdolliseen kanavan kompromissiin liittyviin uhkiin.

Viestistä reagoimiseen

Kun tutustuin MeldID:hen ensimmäistä kertaa, sitä voisi kuvata yhtenäisenä tunnistus- ja profiilin hallintajärjestelmänä. Uusien mobiilisovellusten ja suojausmekanismien myötä tämä kuvaus on kuitenkin käynyt liian suppeaksi.

Nykyään järjestelmä vastaa eivät vain kysymykseen "kuinka kirjaudun sisään?", vaan myös monimutkaisempiin kysymyksiin:

• mitä tehdä odottamattoman palautusyrityksen yhteydessä;

• kuinka palauttaa tili ilman sovellukseen pääsyä;

• miten saada aikaa tarkistaa ennen uuden salasanan käyttöönottoa;

• miten peruuttaa ei-omistajan aloittama palautus;

• miten peruuttaa aktiiviset istunnot;

• miten estää haavoittuneen sähköpostin muuttamasta salasanaa kriisitilanteessa;

• miten palauttaa hallinta ulkoisesta palautuskanavasta;

• miten säilyttää käyttäjätiedot, kun kaikki aktiiviset pääsyt on katkaistu;

• miten palata normaaliin tilaan tilanteen jälkeen.

Lopputuloksena syntyy kerroksittainen suojausmalli.

Voimassa oleva MeldID-salasana ei siirry palautuskanavan kautta. Pääsy sähköpostiin ei itsessään paljasta salasanaa, mutta voi sallia uuden salasanan luomisen. Palautus siis tapahtuu viiveellä ja voidaan peruuttaa luotetulla sovelluksella.

Jos tämä ei riitä, hätätila katkaisee aktiiviset istunnot, peruuttaa tunnukset eikä anna kesken jääneen palautuksen jatkua suojajakson yli.

Käyttäjä saa sitä, mikä on erityisen tärkeää tositilanteessa: ajan.

Ajan palauttaa hallinnan sähköpostiin, tarkistaa laitteet, selvittää tapauksen ja vasta tämän jälkeen avata normaalin pääsyn takaisin tilille.

Siksi MeldID:n hätätila ei ole vain "kirjaudu ulos kaikista" -painike. Se on erillinen reaktioskenaario tilanteeseen, jossa tavallinen kirjautuminen ei enää riitä ja luottamus tilin nykyiseen tilanteeseen on menetetty ensin.

Lisätietoja: meldid.de.