Meerfactorauthenticatie uitschakelen zonder verificatie

Een tweede factor is bedoeld om te blijven werken op het moment dat er iets misgaat met het wachtwoord of de sessie. Kan die factor met een enkele klik worden uitgezet, dan werkt hij precies dan niet meer. Hieronder leest u waarom het uitschakelen dezelfde bescherming verdient als de functie zelf.

Wat gaat er mis bij het uitschakelen?

Meerfactorauthenticatie wordt beoordeeld op hoe goed hij het inloggen beschermt. Wat daarbij regelmatig buiten beeld blijft, is de vraag hoe hij kan worden uitgezet. Uitschakelen zonder verificatie betekent dat een ingelogde gebruiker de tweede factor kan verwijderen zonder opnieuw aan te tonen wie hij is.

Het gevolg is dat de bescherming precies zo sterk is als de sessie. En sessies zijn nu juist wat een tweede factor moet compenseren: ze kunnen worden gekaapt via een gedeelde computer, een gestolen cookie, cross-site scripting of een onbeheerde werkplek. In al die gevallen is de tweede factor de laag die overblijft, tenzij die met één verzoek kan worden opgeheven.

Hetzelfde geldt voor de omwegen eromheen. Herstelcodes zijn een volwaardig alternatief voor de tweede factor; zijn ze zonder bevestiging opnieuw op te vragen, dan is dat dezelfde deur onder een andere naam. Dat maakt het slot op de kluis vergelijkbaar met een slot waarvan de sleutel ernaast hangt.

Hoe schakelt een aanvaller uw MFA uit?

Kwetsbaar:

// Alleen een geldige sessie is nodig
app.post('/account/mfa/uitschakelen', vereistLogin, async (req, res) => {
  await gebruikers.zetMfaUit(req.gebruiker.id);
  res.send('Tweefactorauthenticatie uitgeschakeld');
});

// En de herstelcodes zijn zomaar opnieuw op te halen
app.get('/account/mfa/herstelcodes', vereistLogin, async (req, res) => {
  res.json(await gebruikers.herstelcodes(req.gebruiker.id));
});

Een aanvaller die op enige manier een sessie bemachtigt, hoeft de tweede factor niet te omzeilen; hij zet hem uit. Daarna wijzigt hij het wachtwoord, en het account is van hem, met de bescherming die de gebruiker juist had ingeschakeld als eerste slachtoffer.

Het tweede endpoint is nog stiller. De aanvaller laat de tweede factor gewoon aan staan, haalt de herstelcodes op en gebruikt er later een. De gebruiker merkt niets: zijn authenticator werkt nog, er is niets uitgeschakeld, en er is geen melding geweest.

Veilig:

app.post('/account/mfa/uitschakelen', vereistLogin, async (req, res) => {
  const gebruiker = await gebruikers.zoek(req.gebruiker.id);

  // Wachtwoord én de factor zelf: aantonen dat u hem bezit
  const wachtwoordKlopt = await argon2.verify(gebruiker.hash, req.body.wachtwoord ?? '');
  const factorKlopt = await controleerMfa(gebruiker, req.body.code ?? '');

  if (!wachtwoordKlopt || !factorKlopt) {
    await registreerMislukt(gebruiker.id, 'mfa-uitschakelen');
    return res.status(403).send('Bevestiging mislukt');
  }

  await gebruikers.zetMfaUit(gebruiker.id);
  await gebruikers.verwijderHerstelcodes(gebruiker.id);
  await sessies.verwijderOverigeVoor(gebruiker.id, req.sessionID);

  await mail.stuur(gebruiker.email,
    'Tweefactorauthenticatie is uitgeschakeld voor uw account. ' +
    'Was u dit niet? Herstel dit direct via: ...');
  await auditlog.schrijf('mfa uitgeschakeld', { gebruiker: gebruiker.id, ip: req.ip });

  res.send('Tweefactorauthenticatie uitgeschakeld');
});

De handeling vraagt nu om het wachtwoord én om de tweede factor zelf. Dat laatste is het bepalende punt: de gebruiker toont aan dat hij de factor bezit, niet alleen dat hij een sessie heeft. Daarnaast worden de herstelcodes ongeldig gemaakt, worden andere sessies beëindigd en krijgt de gebruiker een melding met een weg terug.

Wat is de impact van MFA die zonder verificatie uit kan?

De ernst is middelzwaar tot hoog. Kenmerkend is dat de bevinding de waarde wegneemt van een maatregel die de organisatie als geregeld beschouwt, en dat maakt het risico onzichtbaar in de eigen rapportage.

Het scenario is steeds hetzelfde: een aanvaller heeft een sessie of een wachtwoord, maar niet de tweede factor. Dat is precies de situatie waarvoor die factor bestaat. Kan hij vanuit die positie de factor uitzetten of de herstelcodes ophalen, dan is de barrière er niet meer en is de overname compleet.

Bij accounts met veel rechten weegt dat zwaarder. Een beheerder voor wie een tweede factor verplicht is gesteld, maar die hem zelf zonder bevestiging kan uitzetten, biedt in de praktijk niet meer bescherming dan een beheerder zonder verplichting. Daarnaast omdat het uitschakelen vaak niet wordt gelogd of gemeld, blijft het lang onopgemerkt.

Hoe spoor je MFA die zonder verificatie uit kan op?

Een tester schakelt een tweede factor in en probeert daarna alle wegen om hem weer kwijt te raken. Kan hij worden uitgezet met alleen de bestaande sessie? Wordt er om het wachtwoord gevraagd, en zo ja, wordt dat aan serverzijde gecontroleerd? Wordt er om de factor zelf gevraagd?

Vervolgens worden de omwegen bekeken. Zijn herstelcodes opnieuw op te vragen zonder bevestiging? Kan een nieuwe factor worden geregistreerd naast de bestaande, zonder de oude te bevestigen, waarmee de aanvaller zijn eigen apparaat toevoegt zonder dat er iets wordt uitgeschakeld? Werkt het herstelproces bij verlies via een enkele e-mailbevestiging? En stelt de API dezelfde eisen als de webinterface? Ook wordt gekeken of de gebruiker een melding krijgt en of de handeling in een auditlog belandt. AssistSec toetst die routes afzonderlijk, omdat de bescherming wordt bepaald door de zwakste ervan en die zelden de hoofdroute is.

Hoe voorkom je MFA die zonder verificatie uit kan?

• Vraag bij het uitschakelen van de tweede factor om het huidige wachtwoord én om de factor zelf.
• Stel dezelfde eisen bij het toevoegen of vervangen van een factor, niet alleen bij het verwijderen.
• Bescherm herstelcodes even goed: toon ze eenmalig en vraag om herauthenticatie voor een nieuwe reeks.
• Maak herstelcodes ongeldig zodra de tweede factor wordt uitgeschakeld of opnieuw ingesteld.
• Laat het herstelproces bij verlies lopen via een geverifieerd tweede kanaal of via uw helpdesk met identiteitscontrole.
• Stuur direct een melding naar het bekende adres, met een mogelijkheid om in te grijpen.
• Beëindig andere sessies wanneer de authenticatie-instellingen wijzigen.
• Leg elke wijziging aan de tweede factor vast in een auditlog.
• Stel dezelfde eisen aan de API als aan de webinterface.