Faktorerne skal kunne autentificere hvem brugeren er, dvs. sikre at det er den rette bruger, som logger ind.
Brugernavn, kundenummer, personnummer (CPR-nr.), mv. kan ikke betragtes som en faktor, hvis andre end brugeren kender eller har adgang til disse oplysninger. Desuden er det oplysninger, der har samme karakter, og indtastes på samme måde som adgangskoden, hvorfor de er udsat for samme trusler (fx afluring via malware eller fysisk overvågning). Dermed mindsker det ikke risici væsentligt, at man skal indtaste både brugernavn og adgangskode – heller ikke hvis begge dele udelukkende var kendt af brugeren selv.
Faktorerne vælges fra forskellige kategorier af følgende:
- Noget brugeren ved: Typisk en personlig adgangskode. Det skal være noget, som kun brugeren kender, og som brugeren kan nøjes med at have i hukommelsen. Derfor er det normalt også noget, som brugeren selv har valgt. Faktoren må ikke på noget tidspunkt have været tilgængelig eller blive tilgængelig for andre personer, hvorfor den skal opbevares envejskrypteret (hashed). Brugeren skal kunne udskifte denne faktor, hvis der er mistanke om, at andre har fået kendskab til den.
- Noget brugeren har: Eksempelvis et personligt kort med unikke engangskoder. Faktoren kan også blive genereret af noget unikt software, som ligger i noget hardware, fx engangskoder fra en hardkey/nøgleviser. Det skal være noget, som brugeren kan have i sin fysiske besiddelse, og som brugeren kan holde helt for sig selv. Det må ikke være noget, som skal deles med andre. Brugeren skal kunne udskifte denne faktor, hvis der opstår mistanke om, at andre har mulighed for at anvende en kopi af hardwaren/softwaren.
- Noget brugeren er: Typisk biometri, som fingeraftryk, irisscan, ansigtsgenkendelse, stemmegenkendelse, osv. Til sammenligning med kategori A og B, har kategori C en indbygget svaghed, nemlig at brugeren sjældent kan holde faktoren for sig selv eller udskifte den.
Flerfaktorautentifikation har sin styrke i, at det kan minimere konkrete risici. Først afdækkes alle de trusler, som et konkret login kan blive udsat for, og derefter vælges faktorerne ud fra en vurdering af, om de i tilstrækkelig grad påvirker (nedbringer) de konkrete risici. Eksempel:
- En medarbejder skal anvende adgangskoder indtastet via pc/smartphone. Dette kan blive udført af medarbejderen på offentlige steder. En primær trussel er, at adgangskoden kan blive opsnappet af ondsindet software eller hackere, som har kompromitteret den anvendte pc/smartphone. Adgangskoden er endvidere udsat for afluring ved ”kik over skulderen” eller via overvågningskameraer på et offentligt sted.
- Hvis den anden faktor er en engangskode fra en elektronisk kodeviser, så kan denne også blive opsnappet på samme måde, og den er dermed udsat for samme trusler som adgangskoden. Hvis koden vist på kodeviseren derimod kun kan anvendes én gang og indenfor meget kort tid – og brugeren må antages at ville anvende den straks – så er denne faktor ikke udsat i samme grad.
- Kodeviseren kan blive stjålet (trussel om fysisk tyveri), men adgangskoden er ikke udsat på samme måde, hvis den udelukkende kendes af brugeren. Brugeren må derfor ikke skrive koden på en papirlap, der kan blive stjålet sammen med kodeviseren. Derfor suppleres med en organisatorisk foranstaltning i form at retningslinjer til brugerne om håndtering af adgangskoden og hurtig rapportering af tyveri, med henblik på spærring af kodeviser og evt. login.
Det kan også betragtes som to faktorer, hvis der først skal forceres en fysisk barriere ind i en aflåst bygning med en personligt elektronisk nøglekort ("noget man har"), kombineret med et login til it-systemet med adgangskode ("noget man ved"). I dette eksempel er det dog lidt svært at vurdere risici, fordi de to faktorer er meget adskilt og administreres måske vidt forskelligt.
Den enkelte faktor beskyttes imod misbrug, så den er vanskeligere at omgå. Login-funktioner, der anvender faktoren ”adgangskode”, sikres fx beskyttelse imod 'brute force-angreb' og ordbogsangreb, hvorigennem man forsøger at gætte/prøve sig frem til faktoren. Yderligere beskyttelse kan etableres via organisatoriske foranstaltninger i form af instruktioner til medarbejdere, fx krav til valg og håndtering af adgangskoder.
Beskyttelse imod angreb, hvor brugeren snydes til at udlevere de adgangsgivende faktorer, kaldes Phishing-Resistant MFA. Læs mere om dette her.
Faktorer beskyttes yderligere ved at undlade transmittering af faktorer via e-mail og SMS, fordi de her er udsat for at blive afluret. Faktorer kan i stedet genereres lokalt på en enhed.
Endeligt sikres det, at der ikke er omveje til login, som reelt underminerer flerfaktorautentifikationsløsningen. Det kunne fx være en hjælpe-løsning til brugere der har glemt deres adgangskode, som i praksis giver mulighed for login med kun én faktor.
Se også Center for Cybersikkerheds vejledning om passwordsikkerhed, der ligeledes omtaler flerfaktorautentifikation.