MeldID har lagt till Panikläge: Vad händer när du inte längre kan lita på ditt konto
I MeldID har nya skyddsmekanismer för ovanliga situationer introducerats: schemalagd lösenordsbyta, automatisk avslutning av återställning utan mobilapp och panikläge, som spärra aktiva åtkomster, hindrar ofullständiga lösenordsbyten och behåller användardata oförändrade.
I den föregående artikeln om MeldID berättade jag hur systemet fungerar i vanligt läge: det lagrar en styrd profil, hjälper till att logga in på anslutna tjänster, synkroniserar TOTP-poster mellan enheter och möjliggör bekräftelse av nya autorisationer via mobilappen.
Men varje identifikationssystem har ett scenario som ofta glöms bort för sent: vad gör man om användaren inte längre litar på sitt nuvarande åtkomstande?
Det är inte nödvändigt att redan ha blivit hackad. Ibland räcker det med ett oväntat e-postmeddelande om återställning av lösenord, en okänd session eller ett inlogg från en enhet som ägaren inte känner igen.
För sådana situationer har MeldID introducerat två nya mekanismer: schemalagd lösenordsbyte och panikläge.
Först är det viktigt att förstå hur MeldID:s lösenord är uppbyggt
I MeldID skapar inte användaren ett eget lösenord — det genereras av systemet. Detta utesluter omedelbart svaga och förutsägbara kombinationer, återanvändning av vanliga lösenord och andra problem kopplade till egen valda lösenord.
Samtidigt skickas inte det aktuella lösenordet till användaren via e-post. E-postlådan är inte en plats där det existerande MeldID-lösenordet kan hämtas.
Återställningsproceduren visar inte heller det gamla lösenordet. Den tillåter endast att skapa ett nytt.
Därför utgör inte ett e-postövertagande samma hot; den som fått tillgång till e-postlådan kan inte se det aktuella meldID-lösenordet, men kan försöka använda återställningsproceduren för att skapa ett nytt.
Detta scenario var en av de primära orsakerna till att ändra logiken för återställning.
Lösenordet ändras inte längre omedelbart
I den vanliga återställningsproceduren sker allt nästan direkt. Användaren begär ett nytt lösenord, får ett meddelande och slutför processen.
Det är bekvämt så länge e-postkontot bara är under användarens kontroll. Men om någon annan får tillgång till det, kan en snabb återställning göra e-postlådan till en direkt väg till att ta kontroll över det kopplade kontot.
I MeldID blir förfrågan om nytt lösenord först en varning, inte en omedelbar ersättning av det gamla. Användaren får ett meddelande om att ett återställningsförsök har gjorts, och en väntetid inleds.
Varaktigheten av denna väntan kan ändras, men principen förblir densamma: mellan att förfrågan görs och det nya lösenordet aktiveras finns en tid för att bedöma situationen.
Det gamla lösenordet behåller sin giltighet under denna tid. Att en återställningsförfrågan har initierats betyder alltså inte att kontrollen över kontot automatiskt har förlorats.
Vad händer om appen inte är tillgänglig
Det finns ett viktigt scenario som lätt kan förbises. Användaren kan själv initiera en återställning, men saknar tillgång till MeldID-appen: telefonen är förlorad, trasig, urladdad eller tillfälligt otillgänglig.
I detta fall kan återhämtningen ändå slutföras. Efter den fastställda perioden träder det nya lösenordet i kraft automatiskt. Mobilappen är inte ett krav för den standardmässiga återställningsprocessen.
Så, för den som själv startade lösenordsbytet och inte kan öppna appen nu, behöver man inte börja om. Det räcker att vänta på att processen ska slutföras och därefter logga in med det nya lösenordet.
Om appen är tillgänglig finns fler möjligheter: användaren kan omedelbart aktivera det nya lösenordet eller avbryta en misstänkt förfrågan. Om appen inte är tillgänglig fortsätter den schemalagda återställningen att gälla.
Vill användaren bestämma vad som händer härnäst
Om återställningen verkligen initierades av kontots ägare och appen är tillgänglig kan denne öppna MeldID och direkt aktivera det nya lösenordet, utan att vänta på väntetidens slut.
Om förfrågan är oväntad kan den avbrytas i appen. Då blir inte det nya lösenordet aktivt, och det gamla förblir giltigt.
Detta är en viktig ändring i logiken för återställning. Systemet betraktar inte längre varje förfrågan som giltig bara för att den initierats via e-post; ägaren kan alltid ingripa och fatta beslut via den betrodda mobilenheten.
Föreställ dig en vanlig situation: användaren får ett meddelande om lösenordsbyte, trots att denne inte begärt det. Användaren avbryter i appen, skaffar sig åtkomst till e-posten, kontrollerar enheter och letar efter skäl till misstänkt aktivitet.
MeldID kan inte återställa kontrollen över ett komprometterat e-postkonto. Men det kan hindra en komprometterad e-post från att omedelbart användas för att skapa ett nytt huvudlösenord.
Panikläget inaktiverar aktiva åtkomster
Det schemalagda lösenordsbytet ger tid. Panikläget är avsett för situationer då detta inte är tillräckligt och användaren vill omedelbart stoppa alla tidigare åtkomster till kontot.
Det aktiveras enkelt via en knapp i mobilappen.
Vid aktivering spärras alla aktuella tokens — åtkomstnycklar som appar och webbplatser använder för att verifiera att användaren är inloggad. Samtidigt avslutas alla befintliga sessioner på mobila enheter och webbplatser kopplade till kontot.
Det betyder att inte bara den aktiva sessionen på telefonen avbryts. Även andra smartphones, surfplattor, webbläsare och appar där inloggning tidigare gjorts spärras.
Situationen är aktiv under en fastställd period. Den exakta längden kan variera, men principen är densamma: alla befintliga åtkomster avslutas, och användaren ges en tidsram för att bedöma situationen.
Panikläget raderar inte data
Namnet kan låta drastiskt, därför är det viktigt att förklara vad det inte gör.
Panikläget raderar inte TOTP-poster, sparade profiler, inställningar eller annan användardata. Det tar inte bort innehållet i kontot, det blir inte tomt.
Accessstatus ändras: giltiga tokens spärras, och pågående sessioner avslutas. När kontot återgår till normalt läge kvarstår all sparad data oförändrad och behöver inte läggas till igen.
Det är en grundläggande skillnad mellan att tillfälligt avbryta åtkomsten och att radera innehållet i kontot. Användaren kan stänga befintliga anslutningar utan att vara rädd att data eller inställningar försvinner samtidigt.
Vad händer med lösenordsbytet under panikläget?
Panikläget har en till till aspekt: det stoppar alla ofullständiga lösenordsbyten.
Det spelar ingen roll när förfrågan om ett nytt lösenord gjordes — före eller under aktiviteten. Sådana förfrågningar kan inte automatiskt avslutas när tillståndet återställs.
Efter panikläget är det lösenord som gällde innan aktiveringen fortfarande aktivt.
Det är gjort med avsikt.
Vanlig återställning antar att ägaren kan se en misstänkt förfrågan i MeldID-appen och avbryta den innan det nya lösenordet träder i kraft.
Under panikläget går detta inte längre att lita på.
Föreställ dig att användaren lagt märke till misstänkt aktivitet och aktiverat försvarsläge. Om det tillåts att den normala återställningstimer fortsätter, kan en angripare begära ett nytt lösenord under panikläget. Om väntetiden tar slut före tillståndets slut kan det nya lösenordet tillkomma innan kontot har återgått till normalt – en paradox.
Systemet förbjuder alltså att återställningar fortsätter under panikläget och avbryter den ofullständiga processen.
Förfrågningar som gjordes före aktivering kan inte ändra lösenord efter pansikten. Detsamma gäller för de som görs under panikläget.
Alltså matas ingen ofullständig återställning vidare över gränsen för panikläget.
Vad gör man om man själv vill först byta lösenord
Panikläget begränsar inte ägarens möjligheter att agera i egen takt.
Om användaren har tillgång till MeldID-appen och anser att lösenord också bör bytas, kan denne först initiera ett lösenordsbyte och därefter bekräfta det nya lösenordet direkt i appen.
I detta fall avslutas lösenordsbytet innan panikläget aktiveras.
Efter detta kan användaren aktivera panikläget med det nya aktiva lösenordet. Detta lösenord förblir aktivt efter att panikläget avslutats.
En annan möjlighet är att först aktivera panikläget, utreda orsaken till misstänkt aktivitet, och efter att det är åtgärdat, starta ett nytt lösenordsbyte om så behövs.
Huvudprincipen är att ett påbörjat lösenordsbyte inte ska överleva panikläget.
Panikläget ger tid att återfå kontroll över e-posten
Det finns ett scenario där detta mekanism är särskilt viktigt: användaren tror att problemet inte är MeldID eller telefonen, utan själva e-posten.
E-post används som en av återställningskanalerna. Därför är ett komprometterat e-postkonto en risk även när det aktuella lösenordet för MeldID förblir okänt för tredje part.
Genom att aktivera panikläget kan användaren fokusera på att åtgärda just detta — återställa tillgången till e-postkontot, ändra lösenord, avsluta okända sessioner och granska säkerhetsinställningar.
Under aktivt panikläge kan MeldID inte skapa ett nytt giltigt lösenord för kontot.
Om någon redan har begärt återställning före aktivering av panikläget, kommer detta inte att påverkas. Saknas en begäran under paniklägets tid, kan ny situation uppstå.
Det ger ett säkert temporärt window: aktiva åtkomster av MeldID är spärrade, den potentiellt komprometterade e-postadressen kan inte användas för att förbereda ett nytt lösenord, och ägaren har tid att återfå kontrollen över sitt e-postkonto.
När panikläget avslutas är det föregående lösenordet för MeldID giltigt igen. Om kontrollen över e-postkontot är återställd och inga andra problem finns kan kontot brukas normalt igen.
Om man vid kontrollen vill ändra meldID-lösenordet, kan detta göras separat.
Det finns många orsaker att aktivera panikläget
Det krävs inte att man först bevisar att man är hackad för att starta läget.
Telefonen kan ha hamnat i orätta händer. En okänd session kan ha dykt upp i listan över anslutna enheter. Användaren kan ha fått oväntade inloggnings- eller återställningsmeddelanden. Ofta grundas misstanken inte på en enskild händelse, utan på ett antal små tecken.
I sådana fall är det inte alltid motiverat att först utreda incidenten utan att först ha tillfälligt inaktiverat åtkomst. Då kan det vara klokare att skyndsamt dra tillbaka alla aktiva åtkomster och sedan granska närmare.
I detta perspektiv följer MeldID en enkel logik: om kontots ägare anser att situationen är riskabel och har tillgång till den betrodda appen, bör denne kunna aktivera skyddsprotokollet direkt. Systemet kräver inte att bevisa en attack först.
Varför en enda lösenordsändring inte räcker
Lösenordet är bara en del av auktorisationen. Om det redan finns en aktiv session eller ett issued token, är en förändring av det enbart inte samma sak som att återkalla all tidigare tillgång.
Det är därför panikläget är bredare. Det byter inte bara ett parameter, utan sätter hela kontot i ett särskilt skyddsläge.
Följande sker i sekvens:
Aktiva sessioner och tokens återkallas;
Ofullständiga lösenordsbyten som påbörjats före panikläget avbryts;
Begäran om återställning under panikläget kan inte ändra lösenord efter att det avslutats;
Det lösenord som användes innan panikläget förblir aktivt;
Användaren ges tid att kontrollera e-post, enheter och andra potentiella källor till problemet;
När säkerhetsläget avslutas återgår kontot till vanlig drift eller kan ändra lösenord separat.
Det är inte en ersättning för vanliga säkerhetsmekanismer, utan ett särskilt nödläge för situationer där förtroendet för den aktuella åtkomststatusen är förlorat tillfälligt.
Mobilappen som betrodd punkt
De nya funktionerna finns i MeldID-appen för iPhone och Android. Denna arkitektur gör telefonen till mer än en inloggningsenhet — den blir en betrodd kontrollpunkt för kontots säkerhet.
Via appen kan man:
bekräfta schemalagt lösenordsbyte;
avbryta misstänkt förfrågan;
aktivera panikläget;
avsluta befintliga sessioner på olika enheter;
bestämma hur kontot ska hanteras vidare.
Appen ändrar inte TOTP och ersätter inte andra skyddsmekanismer. Den tillför en separat kontrollkanal för situationer där vanlig inloggning inte längre är tillräckligt för att säkerställa kontots tillstånd.
Var går gränsen för MeldID:s skydd
Det är viktigt att skilja på själva Mekanismen MeldID och den miljö den används i.
MeldID är byggt för att själva tjänsten inte ska skapa ett normalt kanal för att få ut det aktuella lösenordet. Lösenordet genereras av systemet, väljs inte av användaren och skickas inte via e-post. Återställning visar inte heller det existerande lösenordet, utan initierar skapandet av ett nytt.
Men användaren kan fortfarande på egen hand avslöja sina inloggningsuppgifter, till exempel genom att lämna ut dem till någon annan eller skriva in dem där det inte är säkert.
En separat nivå är skyddet för själva enheten och dess operativsystem. Mobilappen fungerar inom de skyddsmekanismer som tillhandahålls av iOS och Android och kan inte ersätta eller undergräva plattformens säkerhet.
Således fokuserar MeldID på de risker som kan hanteras på dess egen sida: generering av inloggningsuppgifter, auktorisation, tokens, sessioner, återställning och att reagera på potentiella försök till intrusion.
Från inloggning till åtgärder
När jag först lärde känna MeldID kunde det beskrivas som ett system för enhetlig identifikation och profilhantering. Efter lanseringen av mobilappar och införandet av nya skyddsmekanismer är denna beskrivning för begränsad.
Nu svarar systemet inte bara på frågan "Hur loggar jag in?" utan också på mer komplexa frågor:
Vad gör jag vid oväntad återställningsförfrågan?
Hur återställer jag kontot utan tillgång till appen?
Hur får jag tid att verifiera innan ett nytt lösenord aktiveras?
Hur avbryter jag en återställning som inte initierats av ägaren?
Hur inaktiverar jag aktiva sessioner?
Hur förhindrar jag att komprometterad e-post ändrar lösenord under nödläget?
Hur återfår jag kontrollen över det externa återställningskanalet?
Hur behåller jag användardata när alla aktiva åtkomster avbryts?
Hur återgår jag till normal funktion efter situationens utvärdering?
Sammantaget utvecklas en sekventiell skyddsmodell.
Det aktuella meldID-lösenordet överförs inte via återställningskanalen. Att få tillgång till e-posten ger inte i sig tillgång till lösenordet, men kan tillåta att en ny lösenordsförfrågan initieras. Därför sker återställning med fördröjning och kan avbrytas via den betrodda appen.
Om detta inte räcker, bryter panikläget de aktiva sessionerna, återkallar tokens och förhindrar att ofullständiga återställningar kan fortsätta efter skyddstiden.
Användaren får den tid som är särskilt viktig vid ett verkligt incident: tid att återfå kontroll över e-post, verifiera enheter, utreda situationen och först därefter återansluta sig till kontot. Därför är panikläget i MeldID inte bara en “logga ut överallt”-knapp. Det är ett separat reageringsscenario för en nödsituation där det normala inloggningssättet inte räcker, och där förtroendet för kontots tillstånd först måste återställas.
.Vill du veta mer om projektet: meldid.de.