Twee wachtwoordvragen zijn geen MFA: wat een VPN-aanmelding verifieert

De aanmeldpagina vraagt om een wachtwoord en dan om een tweede geheim, en meteen wordt de implementatie multifactor genoemd. Soms is dat zo. Vaak is het één factor die twee keer wordt opgehaald, want beide waarden zijn kennis die dezelfde persoon uit hetzelfde geheugen of dezelfde notitie heeft getypt. Een sterk tunnelcijfer verandert dat niet, en het woord 'veilig' in de productnaam al evenmin.

Het onderscheiden van de bewering en het mechanisme kost één vraag: wat bewijst elke stap, en aan wie?

Een factor is een bewijs, geen veld

Multifactor-authenticatie betekent dat meer dan één verschillende soort bewijs voor hetzelfde account wordt geverifieerd: iets wat de gebruiker weet, iets wat hij bezit, iets wat hij is. Twee velden die beide een onthouden tekenreeks opvragen, zijn één soort bewijs dat twee keer wordt gevraagd. Dat kan een nuttige controle zijn, want twee onafhankelijke geheimen zijn moeilijker te raden dan één, maar het is niet wat de term beschrijft en het moet in een risicobeoordeling niet als zodanig worden geteld.

De verificatiekant is net zo belangrijk als de verzamelkant. Een op een apparaat gegenereerde code bewijst alleen de controle over dat apparaat als de server hem controleert tegen een geheim dat aan dit account is gebonden en herhalingen weigert. Een gedeelde code die voor iedereen werkt, een code zonder snelheidslimiet of een prompt die op een apparaat wordt goedgekeurd dat nooit toont wat er wordt goedgekeurd, zijn allemaal zwakker dan het etiket suggereert.

Dus als iemand vraagt of de VPN MFA heeft, vraag dan wat de tweede stap bewijst en hoe de server hem bindt. Als het antwoord 'een tweede wachtwoord uit dezelfde directory' is, heb je één factor en een beleidsgesprek, geen tweede factor.

Het certificaatgeval moet je lezen, niet aannemen

Een clientcertificaat plus een wachtwoord ziet eruit als twee factoren, en dat kan het zijn: het certificaat staat in een opslag of op een token, en het wachtwoord wordt onthouden. Het kan er ook één zijn, als het certificaatbestand onbeschermd in dezelfde profielmap staat als het opgeslagen wachtwoord, of als het certificaat is uitgegeven voor een apparaat dat meerdere mensen delen zonder individuele verantwoording.

De vraag die je moet beslechten is wie of wat het certificaat identificeert. Een apparaatcertificaat bewijst dat er een beheerde machine aanwezig is. Een gebruikerscertificaat bewijst een identiteit. Als de implementatie één certificaat per laptop uitgeeft en de aanwezigheid ervan vervolgens als bewijs van de persoon behandelt, is de tweede factor stilletjes een eigenschap geworden van hardware die iedereen die de laptop vasthoudt erft.

Niets daarvan maakt certificaten een slecht idee. Het maakt het onderscheid tussen apparaatzekerheid en gebruikerszekerheid de moeite van het opschrijven waard, omdat de twee verschillende vragen beantwoorden en een compliance-spreadsheet die ze als één telt, zal overdrijven wat er is beschermd.

Gatewayvertrouwen en gebruikersvertrouwen zijn aparte problemen

Een tweede factor maakt het niet veilig om inloggegevens te typen in een eindpunt dat je niet hebt geverifieerd. De client moet de bedoelde gateway herkennen, en daarvoor zijn het servercertificaat en de vertrouwensconfiguratie van de client er. Phishing werkt door de login te verplaatsen naar een server die de aanvaller beheert, en een daar ingevoerd correct eenmalig wachtwoord wordt gewoon in realtime doorgegeven aan de echte dienst.

Daarom verandert de methodkeuze de uitkomst meer dan de formulering van de prompt. Door een persoon getypte codes kunnen worden doorgegeven door iedereen die een overtuigende pagina kan tonen, terwijl cryptografische methoden die de authenticatie aan de specifieke oorsprong en sessie binden, dat doorgeven door hun ontwerp weerstaan. Welke van de twee je hebt, is een eigenschap van de methode, niet van het aantal stappen in de dialoog.

Volg de ondersteunde inschrijvings- en clientflow van de leverancier in plaats van een extra prompt aan een wachtwoordveld te schroeven. Een zelfgemaakte tweede stap belandt meestal ergens tussen die twee en voegt wrijving toe zonder de binding die de factor betekenisvol maakt.

Herstel is de tweede voordeur

Elke sterke login heeft een weg terug wanneer de authenticator verloren gaat, en dat pad is waar het ontwerp meestal het zwakst is. Als een supportmedewerker de tweede factor kan resetten na een telefoontje naar een nummer in het dossier, is de goedkoopste route van de aanvaller de helpdesk, niet de aanmeldpagina.

Vraag hoe vervanging werkt, wie die goedkeurt en welk bewijs daarvoor nodig is. Controleer dan dat herstelmateriaal zoals back-upcodes apart van de primaire inloggegevens wordt bewaard, zodat één compromis niet beide weggeeft. De richtlijn voor digitale identiteit van NIST behandelt verifierbinding en de levenscyclus van authenticatoren als onderdeel van de eis en niet als operationele bijzaak.

Wat je in de beoordeling schrijft

Beschrijf de factoren per soort, benoem wat elk bewijst en vermeld hoe het aan het account is gebonden. Noteer of de methode doorgeven weerstaat, en beschrijf het herstelpad met dezelfde zorg als de login.

Zeg dan ronduit of de implementatie volgens die definitie multifactor is. 'Twee wachtwoorden en een machinecertificaat' is een eerlijke zin, en die vertelt een lezer veel meer dan een vinkje dat ja zegt.