To passordspørsmål er ikkje MFA: kva ein VPN-innlogging stadfester

Innloggingssida ber om eit passord og deretter om ein hemmelegheit til, og utrullinga blir skildra som multifaktor med ein gong. Nokre gonger er ho det. Ofte er det éin faktor som blir samla inn to gonger, fordi begge verdiane er kunnskap som same personen har skrive inn frå same minnet eller same notatet. Ein sterk tunnelchiffer endrar ikkje det, og ikkje ordet «sikkert» i produktnamnet heller.

Å skilje påstanden frå mekanismen krev eitt einaste spørsmål: kva provar kvart steg, og for kven?

Ein faktor er eit prov, ikkje eit felt

Multifaktorautentisering tyder at meir enn éin ulik type prov blir stadfesta for same kontoen: noko brukaren veit, noko brukaren har, noko brukaren er. To felt som begge samlar inn ein hugsa streng, er éin type prov som blir spurt om to gonger. Det kan vere ei nyttig kontroll, sidan to uavhengige hemmelegheiter er vanskelegare å gjette enn éi, men det er ikkje det omgrepet skildrar, og det bør ikkje teljast som slikt i ei risikovurdering.

Stadfestingssida er like viktig som innsamlingssida. Ein kode som blir generert på ein eining, provar berre kontrollen over den eininga dersom tenaren sjekkar han mot ein hemmelegheit som er bunden til denne kontoen, og avviser gjentakingar. Ein delt kode som verkar for alle, ein kode utan grense, eller ei førespurnad som blir godkjend på ei eining som aldri viser kva som blir godkjend, er alle svakare enn etiketten antyder.

Så når nokon spør om VPN-en har MFA, spør kva det andre steget provar og korleis tenaren bind det. Viss svaret er «eit andre passord frå same katalogen», har du éin faktor og ein samtale om policy, ikkje ein andre faktor.

Sertifikattilfellet må lesast, ikkje takast for gitt

Eit klient sertifikat pluss eit passord ser ut som to faktorar, og det kan det vere: sertifikatet blir halde i eit lager eller på eit token, og passordet blir hugsa. Det kan òg vere éin, dersom sertifikatfila ligg uverna i same profilmappa som det lagra passordet, eller dersom sertifikatet vart gjeve ut til ei eining som fleire deler utan individuelt ansvar.

Spørsmålet som må avgjerast, er kven eller kva sertifikatet identifiserer. Eit einingssertifikat provar at ein administrert maskin er til stades. Eit brukarsertifikat provar ein identitet. Viss utrullinga gjev ut eitt sertifikat per berbar datamaskin og deretter handsamar tilstadeværet som prov for personen, har den andre faktoren stille blitt ein eigenskap ved maskinvare som alle som held den berbare datamaskina arvar.

Ingenting av dette gjer sertifikat til ein dårleg idé. Det gjer skiljet mellom einingsgaranti og brukargaranti verdt å skrive ned, fordi dei to svarar på ulike spørsmål, og eit samsvarsark som tel dei som éin, vil overdrive kva som er verna.

Tillit til porten og tillit til brukaren er separate problem

Ein andre faktor gjer det ikkje trygt å skrive inn påloggingsinformasjon i eit endepunkt du ikkje har stadfesta. Klienten må kjenne att den tiltenkte porten, og det er det tenarsertifikatet og tillitskonfigurasjonen til klienten er til for. Nettfiske verkar ved å flytte innlogginga til ein tenar angriparen kontrollerer, og ein korrekt eingongskode som blir skriven inn der, blir berre vidaresend til den ekte tenesta i sanntid.

Det er derfor metodevalet endrar utfallet meir enn formuleringa av førespurnaden. Koder som ein person skriv inn, kan vidaresendast av kven som helst som kan vise ei overtydande side, medan kryptografiske metodar som bind autentiseringa til den spesifikke opphavet og økta, står imot den vidaresendinga ved design. Kva av dei du har, er ein eigenskap ved metoden, ikkje talet på steg i dialogen.

Følg den støtta registreringa og klientflyten til leverandøren i staden for å skru ein ekstra førespurnad på eit passordfelt. Eit heimelaga andre steg landar oftast ein stad i mellom, legg til friksjon utan bindinga som gjer faktoren meiningsfull.

Attvinning er den andre hovuddøra

Kvar sterk innlogging har ein veg tilbake når autentikatoren er tapt, og den vegen er der designet oftast er svakast. Viss ein støttemedarbeidar kan nullstille den andre faktoren etter ein telefon til eit nummer i saka, er den billegaste ruta for angriparen hjelpebordet, ikkje innloggingssida.

Spør korleis erstatninga verkar, kven som godkjenner ho og kva prov som blir kravde. Sjekk deretter at attvinningsmateriell som reservekoder blir oppbevart åtskilt frå den primære påloggingsinformasjonen, slik at eitt kompromiss ikkje gjev frå seg begge. Rettleiinga til NIST om digital identitet handsamar bindinga av stadfestaren og livssyklusen til autentikatoren som ein del av kravet, ikkje som ein operativ ettertanke.

Kva som skal skrivast i vurderinga

Skildre faktorane etter type, nemn kva kvar av dei provar, og opplys korleis han er bunden til kontoen. Noter om metoden står imot vidaresending, og skildre attvinningsvegen med same omhug som innlogginga.

Sei så rett ut om utrullinga er multifaktor etter den definisjonen. «To passord og eit maskinseritifikat» er ei ærleg setning, og ho fortel ein lesar langt meir enn ein avkryssingsboks som seier ja.