Meerfactorauthenticatie ontbreekt

Zolang een account alleen met een wachtwoord is beveiligd, is de beveiliging zo sterk als het geheim dat uw gebruiker misschien ook elders heeft gebruikt. Dat is de kern van het probleem: u beveiligt uw applicatie met een gegeven waarover u geen controle hebt. Hieronder leest u wat een tweede factor daaraan verandert en waarom de keuze voor de juiste vorm het verschil maakt tussen een echte drempel en een schijnbare.

Wat is meerfactorauthenticatie?

Meerfactorauthenticatie (MFA) betekent dat een gebruiker zijn identiteit aantoont met bewijzen uit meer dan één categorie: iets wat hij weet (een wachtwoord), iets wat hij heeft (een sleutel of telefoon) en iets wat hij is (een vingerafdruk of gezichtsscan). Het gaat om de combinatie van categorieën, niet om het aantal stappen, twee wachtwoorden achter elkaar is geen MFA.

Het onderliggende idee is dat het aannemelijk is dat één bewijs in verkeerde handen valt, en onwaarschijnlijk dat dat voor twee tegelijk geldt. Een wachtwoord lekt via een datalek bij een andere dienst, wordt geraden of wordt via een nagemaakte inlogpagina afgegeven. Een fysieke sleutel of een gekoppelde telefoon volgt niet vanzelf mee.

Bij een bankkluis werkt het net zo. Daar zijn twee sleutels tegelijk nodig: die van de klant en die van de bankmedewerker. Niet omdat één sleutel slecht is, maar omdat het risico dat beide tegelijk bij dezelfde persoon terechtkomen wezenlijk kleiner is.

Welke vormen bieden werkelijk bescherming?

Niet elke tweede factor is even sterk, en het verschil zit vooral in de bestendigheid tegen phishing.

Kwetsbaar:

// Eén factor, en daarmee is de toegang rond
app.post('/inloggen', async (req, res) => {
  const gebruiker = await gebruikers.zoekOpEmail(req.body.email);
  if (!gebruiker || !await argon2.verify(gebruiker.hash, req.body.wachtwoord)) {
    return res.status(401).send('Onjuiste gegevens');
  }

  req.session.userId = gebruiker.id;
  res.send('Welkom');            // volledige toegang
});

Wie het wachtwoord heeft, is binnen. Bovendien dat wachtwoord komt in de praktijk uit een van drie bronnen: een datalek bij een andere dienst waar de gebruiker hetzelfde wachtwoord gebruikte, een geslaagde raadpoging, of een phishingpagina waar hij het zelf heeft ingevoerd.

Veilig:

app.post('/inloggen', async (req, res) => {
  const gebruiker = await gebruikers.zoekOpEmail(req.body.email);
  if (!gebruiker || !await argon2.verify(gebruiker.hash, req.body.wachtwoord)) {
    return res.status(401).send('Onjuiste gegevens');
  }

  // Nog géén sessie: alleen een kortlevende, beperkte tussentoestand
  req.session.tweedeFactorVoor = gebruiker.id;
  req.session.verlooptOp = Date.now() + 5 * 60 * 1000;
  res.redirect('/inloggen/verificatie');
});

app.post('/inloggen/verificatie', async (req, res) => {
  const id = req.session.tweedeFactorVoor;
  if (!id || Date.now() > req.session.verlooptOp) {
    return res.status(401).send('Verificatie verlopen');
  }
  if (!await verificatieKlopt(id, req.body)) {          // passkey of TOTP
    await registreerMislukt(id);
    return res.status(401).send('Verificatie mislukt');
  }

  req.session.regenerate(() => {
    req.session.userId = id;                            // pas nu een echte sessie
    res.redirect('/');
  });
});

Het cruciale detail is dat er ná het wachtwoord nog geen bruikbare sessie bestaat. De tussentoestand geeft alleen recht op het afronden van de verificatie, is kortlevend en verleent geen enkele toegang tot gegevens. Een veelgemaakte fout is om de sessie meteen aan te maken en de tweede factor alleen in de interface af te dwingen, die is dan met een rechtstreeks verzoek te omzeilen.

Voor de verificatie zelf loopt de sterkte sterk uiteen. Passkeys en hardwaresleutels volgens de WebAuthn-standaard zijn phishingbestendig doordat de sleutel aan uw domein is gebonden. Een authenticator-app met eenmalige codes is een goede middenweg. Sms is de zwakste vorm, omdat de code eenvoudig op een nagemaakte pagina kan worden opgevraagd en direct doorgespeeld.

Wat is de impact van ontbrekende MFA?

De ernst is middelzwaar tot hoog, afhankelijk van wat er achter de applicatie zit en of het om beheerderstoegang gaat. Wat deze bevinding onderscheidt, is dat de aanval niet in uw applicatie hoeft te beginnen.

Bij credential stuffing worden combinaties uit eerdere datalekken geautomatiseerd uitgeprobeerd. Omdat wachtwoordhergebruik wijdverbreid is, levert dat betrouwbaar een percentage geslaagde inlogpogingen op, zonder dat er iets mis is met uw beveiliging. Bij phishing geeft de gebruiker zijn wachtwoord vrijwillig af op een nagemaakte pagina. In beide gevallen is er geen kwetsbaarheid in uw code; er is alleen niets dat het gestolen wachtwoord tegenhoudt.

De gevolgen zijn navenant. Bij een gewoon gebruikersaccount gaat het om toegang tot persoonsgegevens en de mogelijkheid handelingen uit te voeren namens die persoon. Bij een beheerdersaccount gaat het om het hele systeem. Ook omdat de aanvaller met geldige inloggegevens binnenkomt, ziet zijn activiteit er in de logbestanden uit als normaal gebruik, wat detectie aanzienlijk bemoeilijkt.

Hoe spoor je ontbrekende MFA op?

De eerste vaststelling is eenvoudig: biedt de applicatie een tweede factor aan, en zo ja, welke vormen? Daarna begint het onderzoek dat werkelijk iets zegt.

Een tester controleert of de tweede factor aan serverzijde wordt afgedwongen door het verificatiescherm over te slaan en rechtstreeks een beschermde route te benaderen met de sessie die na de wachtwoordstap is ontstaan. Werkt dat, dan is de MFA cosmetisch. Verder wordt gekeken of de tussentoestand kortlevend is, of het aantal verificatiepogingen wordt beperkt, en of eenmalige codes daadwerkelijk maar één keer bruikbaar zijn. Ook de omwegen krijgen aandacht: de wachtwoordherstelfunctie, herstelcodes, en API-endpoints of oudere protocollen die alleen om een wachtwoord vragen. Dat laatste is een klassieke bevinding: een applicatie met keurige MFA in de webinterface waarvan de API dezelfde inloggegevens zonder tweede factor accepteert. AssistSec toetst die routes expliciet, omdat de zwakste ingang bepaalt hoe sterk de authenticatie werkelijk is.

Hoe voorkom je ontbrekende MFA?

• Bied meerfactorauthenticatie aan voor alle accounts en maak het verplicht voor beheerders en gevoelige rollen.
• Kies bij voorkeur passkeys of hardwaresleutels volgens WebAuthn; die zijn bestand tegen phishing.
• Gebruik een authenticator-app met tijdgebonden codes als alternatief, en sms alleen als laatste optie.
• Maak pas een volwaardige sessie aan nádat de tweede factor is geverifieerd, niet ervoor.
• Dwing de verificatie af aan serverzijde op elke route, inclusief API’s en oudere protocollen.
• Beperk het aantal verificatiepogingen en maak eenmalige codes na gebruik direct ongeldig.
• Beveilig de herstelroute even sterk als de inlogroute; anders verplaatst u het probleem alleen.
• Gebruik nummerherkenning bij pushmeldingen om MFA-moeheid tegen te gaan.
• Vraag opnieuw om de tweede factor bij gevoelige handelingen en bij een onbekend apparaat of een afwijkende locatie.