MeldID tilføjede panikfunktion: Hvad sker der, når man mister tillid til kontoadgang

I den forrige artikel om MeldID skrev jeg om, hvordan systemet fungerer i normal tilstand: det gemmer et administrerbart profil, hjælper med at logge ind på tilknyttede tjenester, synkroniserer TOTP-oplysninger mellem enheder og tillader bekræftelse af nye autorisationer via mobilapp.

Men der findes et scenarie, som enhver identifikationssystem ellers kan støde på, men som normalt glemmes for sent: Hvad gør man, hvis brugeren ikke længere har tillid til den nuværende adgang til sin konto?

Det er ikke nødvendigt at vide på forhånd, at der er sket et indbrud. Nogle gange er en uventet e-mail om password-ændring, en ukendt session eller et login fra en ukendt enhed nok til at udløse en mistanke.

Netop for sådanne situationer har MeldID fået to nye mekanismer: udskudt password-ændring og paniktilstand.

Først er det vigtigt at forstå, hvordan MeldID's password er konstrueret

I MeldID opfindes password ikke af brugeren – det genereres af systemet. Dette eliminerer svage, forudsigelige kombinationer, genbrug af gamle passwords og andre problemer forbundet med selvvalgt password.

Samtidig sendes det aktive password ikke til brugeren via e-mail. En e-mailkonto er ikke stedet, hvor man kan få adgang til det nuværende MeldID-password.

Proceduren for genopretning afslører heller ikke det gamle password. Den giver kun mulighed for at starte oprettelsen af et nyt.

Derfor udgør hacking af e-mail en anden trussel: En person med adgang til e-mailen kan ikke se det nuværende MeldID-password, men kan forsøge at bruge genoprettelsesproceduren og få et nyt password sat i stedet.

Netop dette scenarie var en af årsagerne til, at man ændrede logikken bag genopretning.

Password ændres ikke længere øjeblikkeligt

I det normale genopretning scenarie sker alt næsten med det samme. Bruger anmoder om et nyt password, modtager en e-mail og afslutter processen.

Det er bekvemt, så længe e-mailen kun er under brugerens kontrol. Men hvis en anden får adgang til den, kan en øjeblikkelig genopretning blive en direkte vej til at overtage kontoen.

I MeldID bliver anmodningen om nyt password først en advarsel – ikke en øjeblikkelig erstatning for det gamle. Brugeren modtager en meddelelse om forsøg på genopretning, og herefter starter en venteperiode.

Varigheden af denne periode kan variere, men princippet er det samme: Der er et tidspunkt mellem anmodning og den faktiske aktivering af det nye password, hvor man kan vurdere situationen.

Det gamle password forbliver aktivt i denne periode. Derfor betyder en start på genopretning ikke automatisk, at kontrollen over kontoen er overgået til en anden.

Hvad hvis appen ikke er tilgængelig?

Der er en vigtig scenarie, man nemt kan overse: Brugeren kan selv genoprette password, men uden adgang til MeldID-appen – for eksempel hvis telefonen er tabt, ødelagt, da-ladet eller midlertidigt utilgængelig.

I dette tilfælde kan genopretningen stadig gennemføres. Når ventetiden er udløbet, træder det nye password automatisk i kraft. Mobile apps er ikke et krav for den standard genoprettelsesprocedure.

Det betyder, at en person, som har startet password-ændringen men ikke kan åbne appen, ikke skal gentage processen. Det er nok at vente på, at den afsluttes, og logge ind med det nye password.

Hvis appen er tilgængelig, er der flere muligheder: brugeren kan straks aktivere det nye password eller annullere mistænkelige forespørgsler. Hvis adgang til appen ikke er tilgængelig, fortsætter den udskudte genopretning som normalt.

Brugeren bestemmer selv, hvad der skal ske videre

Hvis genopretningen faktisk blev initieret af kontoejeren, og appen er i hånden, kan vedkommende åbne MeldID og straks aktivere det nye password uden at vente.

Hvis anmodningen var overraskende, kan den også annulleres direkte fra appen. Det nye password bliver ikke aktivt, og det gamle forbliver.

Dette er en vigtig ændring i genopretningslogikken. Systemet ikke automatisk acceptere enhver anmodning blot fordi den er sendt via e-mail. Det lader kontoejeren tage stilling og beslutte gennem det betroede mobile enhed.

Forestil dig en normal situation: en bruger modtager en meddelelse om password-ændring, uden har anmodet om det. Brugeren annullerer operationen i appen, checkker sin e-mail, gennemgår enheder og søger efter årsagen til mistænkelig aktivitet.

MeldID kan ikke genvinde kontrollen over en kompromitteret e-mailkonto. Men det kan forhindre, at kompromittering af mailen straks fører til ændring af hovedpasswordet.

Paniktilstand tilbagekalder aktive adgangstilladelser

Udskudt password-ændring hjælper med at vinde tid. Paniktilstand er designet til situationer, hvor dette ikke er nok, og brugeren ønsker at øjeblikkeligt afbryde tidligere udstedte adgangstilladelser.

Den aktiveres med ét tryk i mobilappen.

Ved aktivering tilbagekaldes alle aktive tokens – adgangsnøgler, som apps og hjemmesider bruger til at bekræfte, at brugeren er logget ind. Samtidig lukker sessioner på mobilklienter og websteder, der er tilknyttet kontoen.

Det betyder, at ikke bare den nuværende session på telefonen lukkes. Tilbagekaldelsen gælder også andre smartphones, tablets, browsere og tilknyttede applikationer, hvor der tidligere er logget ind.

Tilstanden gælder i en fastsat periode. Dens varighed kan variere, men princippet er det samme: nuværende adgangstilladelser trækkes tilbage, og brugeren får beskyttet tid til at vurdere situationen.

Paniktilstand sletter ikke data

Navnet kan lyde drastisk, men her er det vigtigt at forklare, hvad det ikke gør.

Paniktilstand sletter ikke TOTP-optegnelser, gemt profil, indstillinger eller brugerdata. Den fjerner ikke indholdet af kontoen, og den gør den ikke tom.

Adgangen til kontoen ændres: de aktive tokens tilbagekaldes, og sessioner lukkes. Når kontoen vender tilbage til normal, ligger de gemte data stadig, og kræver ikke at blive genindlæst.

Det er en principiel forskel på akut adgangsblokade og sletning af indhold. Brugeren kan nemt lukke eksisterende forbindelser uden frygt for, at det vil slette data eller indstillinger.

Hvad sker der med password under panik

En anden vigtig regel er, at paniktilstand opkasserer alle ufuldstændige password-ændringsforsøg.

Det spiller ingen rolle, hvornår password-anmodningen blev foretaget – før eller under panik. Den kan ikke automatisk fuldføres, når tilstanden er ophævet.

Efter panik ophører passwordet, der blev sat før, stadig med at være aktivt.

Det er bevidst.

Normal genopretning bygger på, at kontoejeren kan se mistænkelige anmodninger i MeldID-appen og afvise dem, inden det nye password træder i kraft.

I paniktilstand kan man ikke stole på denne metode længere.

Forestil dig en bruger, der opdager mistænkelig aktivitet og tænder for beskyttelsesmodus. Hvis den almindelige timer for genopretning fortsætter, kan en ondsindet person anmode om et nyt password under panik. Hvis ventetiden udløber, før tilstanden er ophævet, kan det nye password blive aktivt, inden kontoen er vendt tilbage til normal.

Det ville skabe en paradoksal situation: brugeren har aktiveret sit øgede beskyttelseslag, men systemet tillader at ændre password netop i dette tidsrum uden brugerens mulighed for at afbryde det via appen.

Derfor sætter panik ikke genopretning i venteposition for at fortsætte senere. Den afbryder den ufuldstændige proces.

Anmodninger, der fandt sted inden panik, kan ikke ændre password efter dens ophør. Det gælder også forespørgsler lavet under panikken.

På den måde overføres intet af den ufuldstændige genopretning gennem panikgrænsen.

Hvis brugeren selv vil ændre password først

Paniktilstand begrænser ikke ejerens evne til at handle i den rækkefølge, de ønsker.

Hvis MeldID-appen er tilgængelig, og brugeren mener, at password også bør ændres, kan vedkommende starte password-ændring først og bekræfte det nye password med appen.

I så fald afsluttes password-ændringen, inden panikken aktiveres.

Efterfølgende kan brugeren aktivere paniktilstand med det nye aktive password. Det password vil forblive aktivt efter panikken.

En anden mulighed er at aktivere panikken først, undersøge den mistænkelige aktivitet og derefter, om nødvendigt, starte en ny password-ændring efter panikken.

Pointen er, at mekanismen ikke skal tvinge brugeren til kun at handle i en bestemt rækkefølge. Det vigtigste er, at en ufuldstændig password-ændring ikke overlever paniktilstanden.

Panik giver tid til at genvinde kontrol over e-mail

Der er et scenario, hvor dette mekanisme er specielt vigtigt: Bruger mener, at problemet ikke ligger i MeldID eller i telefonen, men i e-mailen.

Det er nemlig e-mailen, der bruges som en af genvejskanalerne til genopretning. Derfor kan kompromittering af e-mail udgøre en risiko, selvom det nuværende MeldID-password er ubekendt for uvedkommende.

I en sådan situation kan brugeren tænde paniktilstand og tage fat på selve problemet: gendanne adgangen til e-mailkontoen, ændre password, afslutte ukendte sessioner og tjekke sikkerhedsindstillinger.

Mens panikken er aktiv, kan MeldID-proceduren ikke generere et nyt aktivt password.

Hvis nogen allerede har anmodet om genopretning før panikkens start, vil denne forsøg ikke overleve under beskyttelsesforløbet. Hvis en ny anmodning kommer ind under panik, vil det få samme resultat.

Det skaber et beskyttet midlertidigt vindue: MeldID-adgange er allerede tilbagekaldt, den potentielt kompromitterede e-mail kan ikke bruges til at oprette det nye password før panikken er ovre, og ejeren har tid til at genvinde kontrol over e-mailkontakten selv.

Efter paniktilstanden er den tidligere MeldID-password stadig aktiv. Hvis e-mailen er genvundet, og der ikke er andre tegn på problemet, kan brugeren igen anvende kontoen normalt.

Hvis brugeren ønsker at ændre MeldID-password efterfølgende, kan det gøres separat.

Årsager til at aktivere panik kan være mange

Der kræves ikke, at der først skal bevises, at der er sket et indbrud, for at starte tilstanden.

Telefonen kan være blevet i andres hænder. Ukendte sessioner kan vises i enhedslisten. Brugeren kan have modtaget uventede login- eller genoprettelsesmeddelelser. Nogle gange opstår mistanke ikke ud fra et tydeligt hændelsesforløb, men ud fra en kombination af mindre tegn.

I sådanne situationer behøver man ikke altid undersøge først. Det kan i stedet være klogest først at tilbagekalde aktive adgangstilladelser midlertidigt og derefter undersøge detaljer.

MeldID følger enkel logik: Hvis kontoejeren vurderer situationen som farlig, og har adgang til en betroet app, skal han have mulighed for straks at aktivere beskyttelsen. Systemet kræver ikke først bevis for et angreb.

Hvorfor én password-ændring ikke altid er nok

Password er kun én del af login-processen. Hvis der allerede er en aktiv session eller et udstedt token, er ændring af password alene ikke det samme som at tilbagekalde alle tidligere tildelte adgangstilladelser.

Derfor virker paniktilstanden bredere. Den ændrer ikke blot en enkelt kontoindstilling, men sætter hele kontoen i en separat beskyttelsestilstand.

1. Aktive sessioner og tokens tilbagekaldes;
2. Ufuldstændige password-ændringer, der er startet før paniken, afsluttes;
3. Anmodninger om genopretning, lavet under panik, kan ikke ændre password efter dens ophør;
4. Det password, som kontoen var logget ind med under panikken, forbliver aktivt;
5. Brugeren får tid til at tjekke mail, enheder og andre mulige problemkilder;
6. Efter at være vendt tilbage til normal tilstand, kan brugeren afslutte, opdatere eller ændre password separat.

Dette er ikke en erstatning for normale sikkerhedsforanstaltninger, men et nødscenarie til situationer, hvor tillid til adgangsstatus er midlertidigt tabt.

Mobilappen som betroet kontrolpunkt

De nye funktioner er tilgængelige i MeldID-appen til iOS og Android. Her bliver telefonen ikke bare et neutralt login-device, men et betroet kontrolpunkt for kontosikkerhed.

Gennem appen kan man:

• Bekræfte udskudt password-ændring;
• Annullere mistænkelig anmodning;
• Aktivere paniktilstand;
• Afbryde aktive sessioner på forskellige enheder;
• Fastlægge, hvordan kontoen skal håndteres fremover.

Appen sletter ikke TOTP-optegnelser, ændrer ikke sikkerhedskonfigurationer, og erstatter ikke andre beskyttelsesmetoder. Den introducerer en separat kontrolkanal til de situationer, hvor normal login ikke er tilstrækkeligt til at sikre tillid.

Hvor grænsen for MeldID's beskyttelse går

Det er vigtigt at adskille sikkerheden i selve MeldID-mekanismen og sikkerheden i det miljø, den bruges i.

MeldID er designet således, at tjenesten ikke opretter en fast kanal til at få adgang til det aktive password. Password genereres af systemet, vælges ikke af brugeren, og sendes ikke via e-mail. Gendannelsesproceduren afslører heller ikke det eksisterende password, men udløser en proces til at oprette et nyt.

Brugeren kan stadig selv afsløre sine legitimationsoplysninger, fx ved at overdrage dem til andre eller indtaste dem på en ikke-betroet måde.

Et andet lag er sikkerheden på selve enheden og operativsystemet. Mobilappen arbejder inden for iOS' og Androids beskyttelsesmekanismer og kan ikke erstatte plattformens sikkerhed.

Derfor fokuserer MeldID på risici, der kan styres fra systemets side: generering af legitimacy, logon, tokens, sessioner, genopretning og reaktion på potentielt kompromitteret gendannelseskanal.

Fra login til respons

Da jeg første gang stiftede bekendtskab med MeldID, kunne det bedst beskrives som et enkelt system til identifikation og profilstyring. Efter lancering af mobilapps og nye beskyttelsesmekanismer er denne beskrivelse blevet for snæver.

Nu handler systemet ikke kun om "hvordan logger man ind?" men også om mere komplekse spørgsmål:

• Hvad gør man ved et uventet genoprettelsesforsøg?
• Hvordan genopretter man kontoen uden adgang til appen?
• Hvordan får man tid til at vurdere, før man aktiverer et nyt password?
• Hvordan annullerer man en genopretning startet af en anden?
• Hvordan tilbagekalder man aktive sessioner?
• Hvordan forhindrer man, at kompromitteret mail ændrer password under en nødtilstand?
• Hvordan genvinder man kontrollen over en ekstern genoprettelseskanal?
• Hvordan bevarer man brugerdata ved afslutning af alle adgangsforbindelser?
• Hvordan vender man tilbage til normal drift efter vurdering?

Resultatet er en sekventiel beskyttelsesmodel.

Det aktive password i MeldID overføres ikke via gendannelseskanalen. Adgang til e-mail alene afslører det ikke, men kan give mulighed for at starte en ny password-tilmelding. Derfor er genopretning forsinket og kan annulleres via den betroede app.

Hvis dette ikke er nok, afbryder paniktilstand aktive sessioner, tilbagekalder tokens og forhindrer, at ufuldstændige genoprettelser overlever beskyttelsesperioden.

Brugeren får det, der er særligt vigtigt i en kritisk situation: tid.

Den tid, der er nødvendig til at genvinde kontrol over e-mailen, tjekke enheder, undersøge hændelsesforløbet og først derefter genoptage normal adgang.

Netop derfor er paniktilstand i MeldID ikke blot en "log ud overalt"-knap. Det er et separat respons scenarie, når den almindelige login ikke er tilstrækkelig, og der først skal genoprettes tillid til kontomiljøet.

Læs mere om projektet: meldid.de .