Iemand vervangt de telefoon, wist het apparaat of verwijdert tijdens het opruimen per ongeluk de authenticator-app. Het wachtwoord werkt nog, maar de tweede factor is verdwenen en de gebruiker kan niet meer bij de mail. Een 2FA-blokkering in webmail is een van de meest voorkomende supportverzoeken in elke organisatie die beveiliging serieus neemt. Bovendien is het probleem volledig voorspelbaar.
In dit artikel lees je hoe je zo'n blokkering oplost, waarom het herstel bewust en niet automatisch moet verlopen en met welke kleine voorbereidingen je er een taak van twee minuten in plaats van een hele middag van maakt.
Waarom dit zo vaak gebeurt
Tweefactorauthenticatie wordt één keer op één apparaat ingesteld, op een moment dat de gebruiker vooral toegang tot de mail wil en niet nadenkt over wat er gebeurt als het apparaat verdwijnt.
Herstelcodes worden aangeboden en meestal genegeerd, omdat ze op dat moment als extra huiswerk voelen. Telefoons worden vervolgens ongeveer elke drie jaar vervangen. Tenzij er bewust een back-up van de authenticator-app is gemaakt of deze is gemigreerd, gaan de codes niet mee. Een 2FA-blokkering in webmail betekent dus niet dat iemand iets verkeerd heeft gedaan. Het is een voorspelbaar gevolg van de levenscyclus van een apparaat.
Dat is goed om te onthouden wanneer het gebeurt, want de buitengesloten gebruiker voelt zich meestal onterecht dom.
De twee manieren om weer binnen te komen
Er zijn er precies twee, en alleen de eerste kan de gebruiker zelf uitvoeren.
Een herstelcode. Deze codes worden bij de registratie verstrekt en vormen de selfserviceroute. De gebruiker meldt zich aan met het wachtwoord, voert een herstelcode in plaats van een appcode in en kan vervolgens in de webmailinstellingen de oude tweede factor verwijderen en een nieuw apparaat registreren. Er is op geen enkel moment een beheerder bij betrokken.
Contact met ons opnemen. Als ook de herstelcodes verloren zijn gegaan, moeten wij de tweede factor wissen. Dit is een handeling van support en geen functie in je dashboard. Dat is bewust geen selfservice. Een accounteigenaar die ongemerkt 2FA van elk postvak kan verwijderen, zou voor een aanvaller een aantrekkelijker doelwit zijn dan het postvak zelf.
Het is belangrijk duidelijk te maken wat het klantendashboard hier wel en niet kan, want de oplossing lijkt daar thuis te horen. De beveiligingspagina van het postvak toont of tweefactorauthenticatie actief is en wanneer ze is bevestigd, en kan het wachtwoord van het postvak wijzigen. De tweede factor kan er niet worden gewist. Het wachtwoord wijzigen lost een 2FA-blokkering in webmail niet op, want het wachtwoord was nooit de reden dat de gebruiker niet binnenkwam.
Op welke manier de factor ook wordt gewist, de gebruiker moet deze direct opnieuw instellen en niet "later". Een postvak dat net een 2FA-blokkering heeft doorgemaakt en nu alleen op een wachtwoord draait, is bij uitstek het postvak dat je niet zo wilt achterlaten.
Controleer met wie je spreekt
Voordat je namens iemand een 2FA-blokkering in webmail naar support doorzet, moet je controleren of het verzoek echt is. Dit is de stap die mensen overslaan en juist degene die ertoe doet.
Vanuit het perspectief van een aanvaller is een collega zover krijgen dat die vraagt om de tweede factor van iemand te verwijderen een van de nuttigste resultaten. Het verzoek komt binnen via e-mail of chat, klinkt alledaags en wordt doorgestuurd omdat de aanvrager leek te weten waarover die sprak.
Controleer daarom via een ander kanaal. Kwam het verzoek per e-mail, bel de persoon dan. Kwam het via chat, stel dan een vraag waarop een bedrieger het antwoord niet kent of vraag het persoonlijk na. De controle kost een minuut. Dat de uiteindelijke handeling bij support ligt, is een tweede beveiligingslaag en geen reden om de eerste over te slaan.
Wees extra voorzichtig als het verzoek dringend, verontschuldigend en enigszins gehaast klinkt. Zo voelt een echte 2FA-blokkering, maar zo wordt ook een poging tot social engineering opgezet. Urgentie onderdrukt immers de neiging om iets te verifiëren.
Voorbereidingen die het eenvoudig maken
Drie kleine maatregelen veranderen dit van een incident in een eenvoudig klusje.
Maak herstelcodes onderdeel van de registratie. Behandel ze niet achteraf als een optionele extra stap, maar bespreek ze meteen en wijs een concrete plek aan om ze te bewaren. Een wachtwoordmanager ligt het meest voor de hand, maar afdrukken is ook een volkomen redelijke keuze.
Moedig waar zinvol een tweede geregistreerd apparaat aan. Met een tablet of tweede telefoon wordt het verlies van een apparaat een ongemak in plaats van een blokkering.
Leg de escalatieroute vast. Bij een 2FA-blokkering in webmail moet de gebruiker weten wie er moet worden ingelicht, en die persoon moet weten dat de oplossing via support loopt en niet via het dashboard. Als je dat midden in het incident moet uitzoeken, kost het een middag.
Geen van deze maatregelen voorkomt blokkeringen, en dat is ook niet de bedoeling. Ze maken het herstel goedkoop. Herstelcodes zijn het enige hulpmiddel dat een supportticket verandert in een selfserviceoplossing van twee minuten. Daarom verdienen ze meer nadruk dan ze doorgaans krijgen.
Twee situaties die alleen op een blokkering lijken
Twee situaties zien er voor de gebruiker hetzelfde uit, maar vragen om een totaal andere aanpak.
Codes worden geweigerd terwijl de app nog werkt. Dit komt meestal door een afwijkende apparaatklok. Tijdgebonden TOTP-codes volgens RFC 6238 zijn afhankelijk van een klok die ongeveer gelijkloopt. Een telefoon waarvan de tijd meer dan een minuut afwijkt, produceert ongeldige codes. Automatische tijdsynchronisatie inschakelen lost dit op zonder dat er iets hoeft te worden hersteld.
Het verkeerde account. Mensen met meerdere adressen registreren soms het ene en proberen zich bij het andere aan te melden, of kiezen de verkeerde vermelding in hun authenticator. Controleer dit voordat je iets opnieuw instelt.
Het komt ook voor dat de gebruiker zich op de verkeerde plek probeert aan te melden. Gebruikers van postvakken melden zich aan via de webmailpagina en niet via het accountdashboard. Een wachtwoord dat op de ene plek werkt, werkt niet op de andere. Dat ziet eruit als een onverklaarbare storing in plaats van een duidelijke vergissing.
Of je 2FA überhaupt moet verplichten
Aangezien blokkeringen de prijs van deze beveiliging zijn, is het redelijk om te vragen of het voordeel opweegt tegen de kosten.
Voor elk postvak dat berichten voor wachtwoordherstel van andere diensten ontvangt, en dat zijn ze bijna allemaal, is het antwoord zonder meer ja. Een e-mailaccount is de herstelroute voor al het andere en verdient daarom de beste bescherming. Een 2FA-blokkering die met een herstelcode wordt opgelost, is een kleine prijs vergeleken met een gehackt postvak.
Waar het werkelijk lastig wordt, zijn gedeelde operationele adressen die meerdere mensen gebruiken. De betere oplossing is niet om de tweede factor over te slaan, maar om helemaal geen gedeelde aanmelding te gebruiken. Kies een gedeeld postvak met leden, zodat iedereen zich met het eigen account aanmeldt.
Hetzelfde principe ligt ten grondslag aan registratie in het algemeen: de inloggegevens moeten bij één persoon horen. Daarom kunnen gebruikers via uitnodigingen hun eigen wachtwoord instellen en hoeven beheerders dit nooit te kennen, zoals uitgelegd in postvakken instellen zonder wachtwoorden te delen.
