Två lösenordsfrågor är inte MFA: vad en VPN-inloggning verifierar

Inloggningssidan frågar efter ett lösenord och sedan efter en hemlighet till, och genast beskrivs driftsättningen som multifaktor. Ibland är den det. Ofta är det en enda faktor som samlas in två gånger, eftersom båda värdena är kunskap som samma person skrivit in från samma minne eller samma anteckning. Ett starkt tunnelchiffer ändrar inte det, och inte heller ordet »säker« i produktnamnet.

Att skilja påståendet från mekanismen kräver en enda fråga: vad bevisar varje steg, och för vem?

En faktor är ett bevis, inte ett fält

Multifaktorautentisering betyder att mer än en distinkt sorts bevis verifieras för samma konto: något användaren vet, något användaren har, något användaren är. Två fält som båda samlar in en ihågkommen sträng är en sorts bevis som efterfrågas två gånger. Det kan vara en användbar kontroll, eftersom två oberoende hemligheter är svårare att gissa än en, men det är inte det som termen beskriver och det bör inte räknas som sådant i en riskbedömning.

Verifieringssidan är lika viktig som insamlingssidan. En kod som genereras på en enhet bevisar bara kontrollen över den enheten om servern kontrollerar den mot en hemlighet som är bunden till detta konto och avvisar upprepningar. En delad kod som fungerar för alla, en kod utan hastighetsbegränsning eller en förfrågan som godkänns på en enhet som aldrig visar vad som godkänns är alla svagare än etiketten antyder.

Så när någon frågar om VPN:en har MFA, fråga vad det andra steget bevisar och hur servern binder det. Om svaret är »ett andra lösenord från samma katalog« har du en faktor och ett policysamtal, inte en andra faktor.

Certifikatfallet kräver läsning, inte antaganden

Ett klientcertifikat plus ett lösenord ser ut som två faktorer, och det kan det vara: certifikatet finns i ett lager eller på en token, och lösenordet är ihågkommet. Det kan också vara en, om certifikatfilen ligger oskyddad i samma profilmapp som det sparade lösenordet, eller om certifikatet utfärdades till en enhet som flera personer delar utan individuellt ansvar.

Frågan att avgöra är vem eller vad certifikatet identifierar. Ett enhetscertifikat bevisar att en hanterad maskin finns på plats. Ett användarcertifikat bevisar en identitet. Om driftsättningen utfärdar ett certifikat per bärbar dator och sedan behandlar dess närvaro som bevis för personen, har den andra faktorn tyst blivit en egenskap hos hårdvara som alla som håller i datorn ärver.

Inget av det gör certifikat till en dålig idé. Det gör skillnaden mellan enhetstrygghet och användartrygghet värd att skriva ner, eftersom de två besvarar olika frågor och ett compliance-kalkylblad som räknar dem som en kommer att överdriva vad som skyddas.

Gatewaytillit och användartillit är separata problem

En andra faktor gör det inte säkert att skriva in uppgifter i en slutpunkt som du inte har verifierat. Klienten måste känna igen den avsedda gatewayen, och det är vad servercertifikatet och klientens förtroendekonfiguration är till för. Nätfiske fungerar genom att flytta inloggningen till en server som angriparen kontrollerar, och en korrekt engångskod som skrivs in där vidarebefordras helt enkelt till den riktiga tjänsten i realtid.

Det är därför metodvalet förändrar utfallet mer än formuleringen av förfrågan. Koder som en person skriver kan vidarebefordras av vem som helst som kan visa en övertygande sida, medan kryptografiska metoder som binder autentiseringen till den specifika ursprunget och sessionen motstår den vidarebefordran genom sin design. Vilken av dem du har är en egenskap hos metoden, inte hos antalet steg i dialogen.

Följ leverantörens stödda registrering och klientflöde i stället för att skruva på en extra förfrågan på ett lösenordsfält. Ett hemmagjort andra steg hamnar oftast någonstans mellan de två och lägger till friktion utan den bindning som gör faktorn meningsfull.

Återställning är den andra huvudingången

Varje stark inloggning har en väg tillbaka när autentiseraren är förlorad, och den vägen är där designen oftast är svagast. Om en supportagent kan återställa den andra faktorn efter ett samtal till ett nummer som finns registrerat, är angriparens billigaste rutt helpdesken, inte inloggningssidan.

Fråga hur utbyte fungerar, vem som godkänner det och vilka bevis som krävs. Kontrollera sedan att återställningsmaterial som reservkoder förvaras separat från den primära inloggningsuppgiften, så att en enda kompromiss inte lämnar ut båda. NIST:s vägledning för digital identitet behandlar verifierarbindning och autentiserarens livscykel som en del av kravet snarare än en operativ eftertanke.

Vad du ska skriva i bedömningen

Beskriv faktorerna efter sort, namnge vad var och en bevisar och ange hur den är bunden till kontot. Notera om metoden motstår vidarebefordran, och beskriv återställningsvägen med samma omsorg som inloggningen.

Säg sedan rakt ut om driftsättningen är multifaktor enligt den definitionen. »Två lösenord och ett maskincertifikat« är en ärlig mening, och den berättar mycket mer för en läsare än en kryssruta som säger ja.