MeldID heeft de paniekmodus toegevoegd: wat gebeurt er wanneer je geen vertrouwen meer hebt in de toegang tot je account
MeldID introduceert nieuwe beveiligingsmechanismen voor ongebruikelijke situaties: uitgestelde wachtwoordwijziging, automatische beëindiging van herstel zonder mobiele app en een paniekmodus die actieve toegangen intrekt, onvoltooide wachtwoordwijzigingen blokkeert en gebruiksgegevens bewaart.
In het vorige artikel over MeldID heb ik beschreven hoe het systeem in normale modus werkt: beheert een profil, helpt bij het toegang krijgen tot verbonden diensten, synchroniseert TOTP-gegevens tussen apparaten en bevestigt nieuwe autorisaties via de mobiele app.
Maar elk identificatiesysteem kent scenario's die meestal te laat worden herinnerd: wat te doen als de gebruiker niet langer vertrouwt op de huidige toegangssituatie van zijn account?
Het is niet nodig dat er al een hack heeft plaatsgevonden. Soms is een onverwachte wachtwoordherstelmail, een onbekende sessie of inloggen vanaf een onbekend apparaat voldoende om alarm te slaan.
Voor zulke situaties introduceerde MeldID twee nieuwe mechanismen: uitgestelde wachtwoordwijziging en paniekmodus.
Eerst begrijpen hoe het MeldID-wachtwoord is opgebouwd
In MeldID bedenkt de gebruiker geen wachtwoord zelf, het wordt door het systeem gegenereerd. Dit voorkomt zwakke en voorspelbare combinaties, hergebruik van vertrouwd wachtwoord en andere problemen die samenhangen met zelf kiezen.
Het actieve wachtwoord wordt niet per e-mail naar de gebruiker gestuurd. De e-mailbox is geen plek waar het bestaande MeldID-wachtwoord te achterhalen is.
Herstelprocedures onthullen ook niet het oude wachtwoord. Ze maken het mogelijk een nieuwe aan te maken.
Dus wordt de compromittering van e-mail een andere bedreiging: iemand met toegang tot de mailbox krijgt het actieve MeldID-wachtwoord niet te zien, maar kan proberen via herstelprocedures een nieuw wachtwoord in te stellen.
Dit scenario was een van de redenen om de herstellogica te wijzigen.
Het wachtwoord wordt nu niet onmiddellijk gewijzigd
In de normale herstelprocedure gebeurt bijna alles meteen. De gebruiker vraagt een nieuw wachtwoord aan, ontvangt een mail en voltooit de procedure.
Dit is handig zolang de e-mail alleen onder controle van de eigenaar staat. Maar als iemand anders toegang heeft tot de e-mail, wordt het onmiddellijke herstel een directe weg naar de accountgegevens.
In MeldID wordt de wachtwoordaanvraag eerst een waarschuwing, geen directe vervanging van het oude wachtwoord. De gebruiker krijgt een melding van de herstelpoging en er start een wachtperiode.
De duur van deze wachtperiode kan variëren, maar het principe blijft hetzelfde: er is een tijdspanne tussen het aanvragen van een wachtwoord en de daadwerkelijke activatie van dat nieuwe wachtwoord om de situatie te kunnen controleren.
Het oude wachtwoord blijft op dat moment geldig. Het feit dat herstel is aangevraagd, betekent dus niet automatisch dat de controle over het account is overgedragen aan iemand anders.
Als de app niet toegankelijk is
Een belangrijk scenario dat gemakkelijk over het hoofd wordt gezien: de gebruiker kan zelf een wachtwoord hergevingen, maar heeft geen toegang tot de MeldID-app: telefoon verloren, kapot, leeg of tijdelijk niet bereikbaar.
Herstel kan alsnog worden voltooid. Na de ingestelde wachtperiode wordt het nieuwe wachtwoord automatisch actief. De mobiele app is geen vereiste voor de standaard herstelprocedure.
Dus als iemand zelf de wachtwoordwijziging heeft gestart en nu de app niet kan openen, hoeft hij het proces niet opnieuw te starten. Het voltooien van de wachtperiode volstaat, waarna kan worden ingelogd met het nieuwe wachtwoord.
Als de app wel bereikbaar is, zijn er meer opties: de gebruiker kan het nieuwe wachtwoord onmiddellijk activeren of een verdacht verzoek annuleren. Zonder toegang tot de app blijft de uitgestelde herstelprocedure gewoon actief.
De gebruiker beslist zelf wat hij daarna doet
Als de herstelprocedure daadwerkelijk door de eigenaar van het account is gestart en de app toegankelijk is, kan hij MeldID openen en het nieuwe wachtwoord meteen activeren, zonder te wachten op het einde van de wachtperiode.
Als het verzoek onverwacht was, kan het worden geannuleerd in de app. Het nieuwe wachtwoord wordt dan niet actief en het oude wachtwoord blijft geldig.
Dit is een belangrijke wijziging in de herstelstrategie. Het systeem beschouwt niet elk aanvraag automatisch als legitiem alleen omdat het via e-mail is gedaan. Het laat de eigenaar van het account toe in te grijpen en een beslissing te nemen via een vertrouwd apparaat.
Stel je voor: iemand ontvangt een melding over een wachtwoordwijziging die hij niet heeft aangevraagd. Hij annuleert het in de app en neemt daarna de e-mail, apparaten en verdachte activiteiten onder de loep.
MeldID kan de controle over een gecompromitteerde mailbox niet herstellen. Maar het kan voorkomen dat het compromis van de mailbox meteen leidt tot het instellen van een nieuw wachtwoord voor het hoofdkonto.
De paniekmodus trekt actieve toegangssessies in
Uitgestelde wachtwoordwijziging geeft tijd. De paniekmodus is bedoeld voor situaties waarin dat niet meer genoeg is en de gebruiker onmiddellijk eerder verleende toegang tot het account wil intrekken.
Het wordt via een enkele actie vanuit de mobiele app geactiveerd.
Na activering trekt het systeem alle geldige tokens in — toegangssleutels die apps en sites gebruiken om te bevestigen dat de gebruiker is ingelogd. Gelijktijdig worden alle actieve sessies op mobiele apparaten en verbonden webdiensten beëindigd.
Dit betekent niet alleen de huidige sessie op de telefoon, maar ook alle andere smartphones, tablets, browsers en gekoppelde applicaties waarin eerder is ingelogd.
De modus duurt een vooraf bepaalde periode. De duur kan verschillen, maar het principe blijft hetzelfde: bestaande toegang wordt beëindigd en de gebruiker krijgt een veilige tijd om de situatie te beoordelen.
De paniekmodus verwijdert geen gegevens
De naam kan dramatisch klinken, daarom is het belangrijk om te verduidelijken wat het niet doet.
De paniekmodus wist geen TOTP-records, profielgegevens, instellingen of andere gebruikersdata. Het verwijdert geen inhoud van het account en maakt het niet leeg.
Wat verandert, is de toegangssituatie: actieve tokens worden ingetrokken, open sessies worden afgesloten. Na terugkeer in normale modus blijven de opgeslagen gegevens op hun plaats en hoeven niet opnieuw te worden toegevoegd.
Het verschil tussen het plots beëindigen van toegang en het verwijderen van inhoud is cruciaal. De gebruiker kan bestaande verbindingen sluiten zonder bang te hoeven zijn dat hierbij gegevens of instellingen verdwijnen.
Wat gebeurt er met het wachtwoord tijdens paniek
De paniekmodus heeft nog een belangrijke regel: hij beëindigt alle onvoltooide wachtwoordwijzigingen.
Het maakt niet uit wanneer de nieuwe vraag is gedaan — vóór het activeren van de paniekmodus of er tijdens. Zo'n aanvraag kan niet automatisch worden afgerond zodra de modus is beëindigd.
Na afloop blijft het wachtwoord dat voor de paniek was actief, geldig.
Dit is opzettelijk zo gedaan.
De normale herstelprocedure gaat ervan uit dat de eigenaar een verdachte aanvraag in MeldID kan zien en kan annuleren voordat het nieuwe wachtwoord actief wordt. Tijdens paniek is dat niet meer mogelijk.
Stel dat een gebruiker verdacht gedrag opmerkt en de beschermingsmodus activeert. Als men de standaard hersteltimer zou laten doorgaan, kan een aanvaller tijdens de paniekperiode alsnog een nieuw wachtwoord aanvragen. Als de wachttijd eerder afloopt dan de terminatie van de modus, treedt het nieuwe wachtwoord al in werking voordat de account weer normaal wordt.
Het zou een paradox opleveren: de gebruiker heeft de extra bescherming ingeschakeld, maar precies in die periode kon het systeem het wachtwoord wijzigen zonder dat de eigenaar via de app kon ingrijpen.
Daarom stopt de paniekmodus het herstelproces en onderbreekt onvoltooide aanvragen.
Alle wachtwoordwijzigingen die vóór het activeren van de modus waren gestart, kunnen na de afloop niet meer de wachtwoordstatus wijzigen. Dit geldt ook voor nieuwe aanvragen tijdens de beschermingsperiode.
Zo wordt voorkomen dat onvoltooide herstelpogingen doorgaan onder de paniekmodus.
Wat als de gebruiker zelf eerst het wachtwoord wil wijzigen
De paniekmodus beperkt de eigenaar niet in de volgorde van acties.
Als de gebruiker toegang heeft tot MeldID en het wachtwoord wil wijzigen, kan hij eerst de wachtwoordwijziging starten en meteen bevestigen via de app.
In dat geval wordt de wijziging voltooid vóór de activering van de paniekmodus.
Na dat moment activeert de gebruiker de beschermingsmodus met het nieuwe, actieve wachtwoord. Dit wachtwoord blijft na de paniek actueel.
Een andere mogelijkheid is: eerst de paniekmodus inschakelen en daarna de oorzaak van ongebruikelijke activiteit aanpakken. Na afronding kan opnieuw een wachtwoordwijziging worden aangevraagd.
Het mechanisme is niet bedoeld om de gebruiker een vaste volgorde op te leggen. Het hoofdprincipe is dat onvoltooide wachtwoordwijzigingen niet de paniekmodus overleven.
De paniekmodus geeft de tijd om de controle over de mailbox terug te krijgen
Een scenario waarin dit mechanisme bijzonder belangrijk is: als de gebruiker vermoedt dat het probleem niet in MeldID ligt, maar in het e-mailaccount.
Omdat e-mail een van de herstelkanalen vormt, is de compromittering ervan gevaarlijk, ook als het actieve MeldID-wachtwoord niet bekend is bij de aanvaller.
In zo'n geval kan de gebruiker de paniekmodus inschakelen en zich richten op het bronprobleem: toegang herstellen tot de mailbox, wachtwoord wijzigen, ongebruikte sessies beëindigen en beveiligingsinstellingen controleren.
Tijdens de paniekperiode wordt het herstelproces via MeldID niet toegestaan om een nieuw actief wachtwoord te creëren.
Als iemand reeds een herstelverzoek heeft gedaan voordat de modus werd geactiveerd, wordt dat niet door de beschermingsmodus beïnvloed. Een nieuw verzoek tijdens de paniek zal hetzelfde resultaat geven.
Zo ontstaat een beschermend tijdelijk venster: actuele MeldID-toegang wordt ingetrokken, en de mailbox die mogelijk is gecompromitteerd niet gebruikt kan worden om een nieuw wachtwoord voor het account te plannen, tot de paniekperiode voorbij is. De eigenaar krijgt zo de tijd het eigen e-mailaccount onder controle te krijgen.
Na afloop van de beschermingsmodus blijft het oorspronkelijke MeldID-wachtwoord actief. Als de controle over de mailbox is hersteld en er verder geen tekenen van problemen zijn, kan het account weer normaal worden gebruikt.
Indien de gebruiker vervolgens besluit het MeldID-wachtwoord te wijzigen, kan dat later apart worden gedaan.
Veel redenen om de paniekmodus te activeren
Het activeren van de modus vereist niet eerst een aangetoonde inbraak.
Telefoon kan in handen van een onbekende zijn gevallen. Een onbekende sessie kan op de lijst staan. De gebruiker kan onverwacht een loginmelding of herstelverzoek ontvangen. Soms ontstaat het vermoeden niet door een enkele gebeurtenis, maar door meerdere kleine tekenen samen.
In dergelijke situaties is het niet altijd nodig eerst een onderzoek uit te voeren. Soms is het verstandiger om tijdelijk alle actieve toegangen in te trekken en daarna de details te bekijken.
MeldID hanteert hierbij een eenvoudige logica: als de eigenaar het gevaar ziet en toegang heeft tot een vertrouwde app, moet hij direct de beschermende actie kunnen activeren. Het systeem vereist niet dat eerst de aanval wordt bewezen.
Waarom vaak één wachtwoordwijziging niet genoeg is
Een wachtwoord is slechts één element van de autorisatie. Als er al een actieve sessie of een toegangs-token bestaat, is alleen het wijzigen van het wachtwoord niet hetzelfde als het intrekken van alle reeds uitgereikte toegangsmiddelen.
Daarom werkt de paniekmodus uitgebreider. Het wijzigt niet alleen één instelling, maar plaatst het hele account in een beschermde, geïsoleerde staat.
De volgorde is als volgt:
actieve sessies en tokens worden ingetrokken;
onvoltooide wachtwoordwijzigingen voor de modus worden afgebroken;
herstelverzoeken tijdens de modus kunnen niet meer het wachtwoord veranderen na afloop;
het wachtwoord waarmee het account de modus inging, blijft actief;
de gebruiker krijgt de tijd om mailbox, apparaten en andere bronnen te controleren;
na het beëindigen van de beschermingsmodus keert hij terug naar normaal gebruik of kan hij een nieuwe wachtwoordwijziging starten.
Dit is geen vervanging van standaard beveiligingsmechanismen, maar een speciale noodgevalprocedure voor situaties waarin het vertrouwen in de huidige toegang tijdelijk verloren is.
De mobiele app als vertrouwde controlepunt
De nieuwe functies zijn beschikbaar in MeldID-apps voor iPhone en Android. In deze architectuur wordt de smartphone niet alleen een extra inlogapparaat, maar een vertrouwd controlepunt voor de accountbeveiliging.
Via de app kan men:
uitgestelde wachtwoordwijzigingen bevestigen;
verdachte verzoeken annuleren;
de paniekmodus activeren;
actieve sessies op verschillende apparaten beëindigen;
beslissen wat daarna met het account gebeurt.
De app beëindigt niet de TOTP en vervangt geen andere beveiligingsmethoden. Het biedt een apart communicatiekanaal voor situaties waarin standaard autorisatie niet voldoende is om het account veilig te stellen.
Waar ligt de grens van MeldID-beveiliging
Het is belangrijk om de beveiliging van het MeldID-mechanisme zelf te onderscheiden van de beveiliging van de omgeving waarin het wordt gebruikt.
MeldID is zo ontworpen dat de service zelf geen standaardkanaal biedt voor het verkrijgen van het actieve wachtwoord. Het wachtwoord wordt door het systeem gegenereerd, niet door de gebruiker gekozen en niet via e-mail verzonden. Herstel onthult ook niet het bestaande wachtwoord, maar start een nieuwproces.
De gebruiker kan echter nog steeds zelf gegevens bekendmaken, bijvoorbeeld door deze door te geven aan anderen of op plekken waar het niet zou moeten.
Een extra beveiligingslaag betreft de veiligheid van het apparaat en het besturingssysteem zelf. De MeldID-app werkt binnen de beveiligingsmechanismen van iOS en Android en kan dergelijke platformbeveiliging niet ondermijnen.
Daarom richt MeldID zich op risico's die onder zijn controle liggen: het genereren van accountgegevens, autorisatie, tokens, sessies, herstelprocedures en het reageren op kwetsbaarheden in de herstelsystemen.
Van inloggen tot reactie
Toen ik begon met MeldID, zou je de system kunnen beschrijven als een uniek identificatie- en profielbeheerplatform. Met de komst van mobiele apps en nieuwe beveiligingen is die omschrijving te beperkt geworden.
De systeemantwoord gaat nu niet alleen over 'hoe in te loggen?', maar ook over complexere vragen:
wat te doen bij een onverwachte herstelpoging;
hoe een account te herstellen zonder toegang tot de app;
hoe tijd te krijgen voor controle voordat een nieuw wachtwoord wordt geactiveerd;
hoe een herstelpoging te annuleren die niet door de eigenaar is gestart;
hoe actieve sessies in te trekken;
hoe te voorkomen dat een gecompromitteerde mailbox wachtwoordverandering kan forceren tijdens een noodgeval;
hoe de controle over het herstelkanaal terug te krijgen;
hoe gebruikersgegevens te behouden na het beëindigen van alle actieve toegangen;
hoe terug te keren naar normaal gebruik na een situatiecontrole.
Uiteindelijk ontstaat zo een gelaagde beveiligingsaanpak.
Het actieve MeldID-wachtwoord wordt niet via het herstelkanaal overgedragen. Toegang tot e-mail wordt op zich niet automatisch onthuld, maar kan wel een nieuw wachtwoordproces triggeren. Daarom verloopt herstel met vertraging en kan het worden geannuleerd via een vertrouwd apparaat.
Is dat niet genoeg, dan onderbreekt de paniekmodus alle actieve sessies, trekt tokens in en voorkomt dat onvoltooide herstelverzoeken de beschermingsperiode overleven.
De gebruiker krijgt de tijd om de controle over de mailbox te herwinnen, apparaten te controleren en de situatie te analyseren, voordat hij weer normaal kan werken.
De paniekmodus in MeldID is dus geen simpele 'uit-zoekt-alles' knop, maar een aparte reactie op situaties waarin reguliere autorisatie niet meer voldoende is en het eerst vertrouwen moet worden hersteld voordat weer normale toegang mogelijk is.
Voor meer informatie over het project: meldid.de.