To passordspørsmål er ikke MFA: hva en VPN-innlogging verifiserer

Innloggingssiden ber om et passord og deretter om en hemmelighet til, og med en gang blir utrullingen beskrevet som multifaktor. Noen ganger er den det. Ofte er det én enkelt faktor som samles inn to ganger, fordi begge verdiene er kunnskap som den samme personen har skrevet inn fra samme hukommelse eller samme notat. En sterk tunnelchiffer endrer ikke det, og ikke ordet »sikker« i produktnavnet heller.

Å skille påstanden fra mekanismen krever ett eneste spørsmål: hva beviser hvert steg, og for hvem?

En faktor er et bevis, ikke et felt

Multifaktorautentisering betyr at mer enn én ulik type bevis verifiseres for samme konto: noe brukeren vet, noe brukeren har, noe brukeren er. To felt som begge samler inn en husket streng, er én type bevis som spørres om to ganger. Det kan være en nyttig kontroll, siden to uavhengige hemmeligheter er vanskeligere å gjette enn én, men det er ikke det begrepet beskriver, og det bør ikke telles som sådan i en risikovurdering.

Verifiseringssiden er like viktig som innsamlingssiden. En kode som genereres på en enhet, beviser bare kontrollen over den enheten hvis serveren kontrollerer den mot en hemmelighet som er bundet til denne kontoen og avviser gjentakelser. En delt kode som virker for alle, en kode uten hastighetsbegrensning eller en forespørsel som godkjennes på en enhet som aldri viser hva som godkjennes, er alle svakere enn etiketten antyder.

Så når noen spør om VPN-en har MFA, spør hva det andre steget beviser og hvordan serveren binder det. Hvis svaret er »et andre passord fra samme katalog«, har du én faktor og en policediskusjon, ikke en andre faktor.

Sertifikattilfellet må leses, ikke antas

Et klientsertifikat pluss et passord ser ut som to faktorer, og det kan det være: sertifikatet ligger i et lager eller på et token, og passordet huskes. Det kan også være én, hvis sertifikatfilen ligger ubeskyttet i samme profilmappe som det lagrede passordet, eller hvis sertifikatet ble utstedt til en enhet som flere personer deler uten individuelt ansvar.

Spørsmålet som må avklares, er hvem eller hva sertifikatet identifiserer. Et enhetssertifikat beviser at en administrert maskin er til stede. Et brukersertifikat beviser en identitet. Hvis utrullingen utsteder ett sertifikat per bærbar datamaskin og deretter behandler tilstedeværelsen som bevis for personen, har den andre faktoren stille blitt en egenskap ved maskinvare som alle som holder den bærbare datamaskinen arver.

Ingenting av dette gjør sertifikater til en dårlig idé. Det gjør skillet mellom enhetssikkerhet og brukersikkerhet verdt å skrive ned, fordi de to svarer på forskjellige spørsmål, og et samsvarsregneark som teller dem som ett, vil overdrive hva som er beskyttet.

Gatewaytillit og brukertillit er separate problemer

En andre faktor gjør det ikke trygt å skrive inn påloggingsinformasjon i et endepunkt du ikke har verifisert. Klienten må gjenkjenne den tiltenkte gatewayen, og det er det serversertifikatet og klientens tillitskonfigurasjon er til for. Nettfiske fungerer ved å flytte innloggingen til en server angriperen kontrollerer, og en korrekt engangskode som skrives inn der, blir ganske enkelt videresendt til den ekte tjenesten i sanntid.

Det er derfor metodevalget endrer utfallet mer enn formuleringen av forespørselen. Koder som en person skriver inn, kan videresendes av hvem som helst som kan vise en overbevisende side, mens kryptografiske metoder som binder autentiseringen til den spesifikke opprinnelsen og økten, motstår den videresendingen ved design. Hvilken av dem du har, er en egenskap ved metoden, ikke ved antall steg i dialogen.

Følg leverandørens støttede registrering og klientflyt i stedet for å skru en ekstra forespørsel på et passordfelt. Et hjemmelaget andre steg havner vanligvis et sted mellom de to og legger til friksjon uten bindingen som gjør faktoren meningsfull.

Gjenoppretting er den andre hoveddøren

Hver sterk innlogging har en vei tilbake når autentiseringen er tapt, og den veien er der designet vanligvis er svakest. Hvis en støttemedarbeider kan tilbakestille den andre faktoren etter en telefon til et nummer som ligger i saken, er angriperens billigste rute helpdesken, ikke innloggingssiden.

Spør hvordan erstatning fungerer, hvem som godkjenner den og hvilke bevis som kreves. Kontroller deretter at gjenopprettingsmateriale som reservekoder oppbevares atskilt fra den primære påloggingsinformasjonen, slik at ett kompromiss ikke gir fra seg begge. NISTs veiledning for digital identitet behandler verifisererbinding og autentisererens livssyklus som en del av kravet snarere enn en operativ ettertanke.

Hva du skal skrive i vurderingen

Beskriv faktorene etter type, navngi hva hver av dem beviser, og oppgi hvordan den er bundet til kontoen. Noter om metoden motstår videresending, og beskriv gjenopprettingsveien med samme omhu som innloggingen.

Si deretter rett ut om utrullingen er multifaktor etter den definisjonen. »To passord og et maskinsertifikat« er en ærlig setning, og den forteller en leser langt mer enn en avkrysningsboks som sier ja.