To adgangskodeforespørgsler er ikke MFA: hvad et VPN-login verificerer

Loginsiden beder om en adgangskode og derefter om en hemmelighed mere, og straks bliver opsætningen beskrevet som multifaktor. Nogle gange er den det. Ofte er det én faktor, der indsamles to gange, fordi begge værdier er viden, som den samme person har skrevet fra den samme hukommelse eller de samme noter. En stærk tunnelkryptering ændrer ikke på det, og ordet »sikker« i produktnavnet gør heller ikke.

At skille påstanden fra mekanismen kræver kun ét spørgsmål: hvad beviser hvert trin, og over for hvem?

En faktor er et bevis, ikke et felt

Multifaktor-autentificering betyder, at mere end én forskellig slags bevis verificeres for den samme konto: noget brugeren ved, noget brugeren har, noget brugeren er. To felter, der begge indsamler en husket streng, er én slags bevis, der spørges om to gange. Det kan være en nyttig kontrol, fordi to uafhængige hemmeligheder er sværere at gætte end én, men det er ikke det, udtrykket beskriver, og det bør ikke tælles som sådan i en risikovurdering.

Verifikationssiden er lige så vigtig som indsamlingssiden. En kode, der genereres på en enhed, beviser kun kontrollen over den enhed, hvis serveren kontrollerer den mod en hemmelighed, der er bundet til denne konto, og afviser gentagelser. En delt kode, der virker for alle, en kode uden hastighedsbegrænsning eller en forespørgsel, der godkendes på en enhed, som aldrig viser, hvad der godkendes, er alle svagere, end etiketten antyder.

Så når nogen spørger, om VPN'en har MFA, så spørg, hvad det andet trin beviser, og hvordan serveren binder det. Hvis svaret er »en ekstra adgangskode fra samme mappe«, har du én faktor og en politikdrøftelse, ikke en anden faktor.

Certifikattilfældet skal læses, ikke antages

Et klientcertifikat plus en adgangskode ligner to faktorer, og det kan det være: certifikatet ligger i et lager eller på et token, og adgangskoden huskes. Det kan også være én, hvis certifikatfilen ligger ubeskyttet i samme profilmappe som den gemte adgangskode, eller hvis certifikatet blev udstedt til en enhed, som flere personer deler uden individuel ansvarlighed.

Spørgsmålet, der skal afklares, er, hvem eller hvad certifikatet identificerer. Et enhedscertifikat beviser, at en administreret maskine er til stede. Et brugercertifikat beviser en identitet. Hvis opsætningen udsteder ét certifikat per bærbar og derefter behandler dets tilstedeværelse som bevis for personen, er den anden faktor stille blevet en egenskab ved hardware, som enhver, der holder den bærbare, arver.

Intet af det gør certifikater til en dårlig idé. Det gør forskellen mellem enhedssikkerhed og brugersikkerhed værd at skrive ned, fordi de to besvarer forskellige spørgsmål, og et compliance-regneark, der tæller dem som ét, vil overdrive, hvad der er beskyttet.

Gatewaytillid og brugertillid er separate problemer

En anden faktor gør det ikke sikkert at skrive legitimationsoplysninger ind i et endepunkt, du ikke har verificeret. Klienten skal genkende den tilsigtede gateway, og det er servercertifikatet og klientens tillidskonfiguration til. Phishing virker ved at flytte login til en server, angriberen kontrollerer, og en korrekt engangskode, der tastes der, bliver blot videresendt til den rigtige tjeneste i realtid.

Derfor ændrer metodevalget resultatet mere, end formuleringen af forespørgslen gør. Koder, som en person taster, kan videresendes af enhver, der kan vise en overbevisende side, mens kryptografiske metoder, der binder autentificeringen til den specifikke oprindelse og session, modstår den videresendelse ved design. Hvilken af dem du har, er en egenskab ved metoden, ikke ved antallet af trin i dialogen.

Følg leverandørens understøttede tilmelding og klientflow i stedet for at skrue en ekstra forespørgsel på et adgangskodefelt. Et hjemmelavet andet trin lander som regel et sted imellem de to og tilføjer friktion uden den binding, der gør faktoren meningsfuld.

Gendannelse er den anden hoveddør

Ethvert stærkt login har en vej tilbage, når autentificeringen er tabt, og den vej er der, hvor designet normalt er svagest. Hvis en supportmedarbejder kan nulstille den anden faktor efter et opkald til et nummer på filen, er angriberens billigste rute helpdesken, ikke loginsiden.

Spørg, hvordan udskiftning fungerer, hvem der godkender den, og hvilket bevis der kræves. Kontroller derefter, at gendannelsesmateriale som backupkoder opbevares adskilt fra den primære legitimationsoplysning, så ét kompromis ikke udleverer begge. NIST's vejledning om digital identitet behandler verifier-binding og autentificeringens livscyklus som en del af kravet frem for en operationel eftertanke.

Hvad du skal skrive i vurderingen

Beskriv faktorerne efter slags, navngiv hvad hver især beviser, og angiv, hvordan den er bundet til kontoen. Notér, om metoden modstår videresendelse, og beskriv gendannelsesvejen med samme omhu som login.

Sig derefter ligeud, om opsætningen er multifaktor efter den definition. »To adgangskoder og et maskincertifikat« er en ærlig sætning, og den fortæller en læser langt mere end et afkrydsningsfelt, der siger ja.