At virksomheden har indført tofaktor, siger ikke, at tofaktor gælder overalt. Spørgsmålet i en penetrationstest er derfor sjældent, om tofaktor findes, men hvor reglen gælder, hvor den ikke gør, og om de steder, hvor den ikke gør, er bevidste valg.
Bestillingen skal derfor rumme tre ting: en beskrivelse af, hvor virksomheden mener tofaktor er krævet, de undtagelser, virksomheden kender, og de funktioner omkring tofaktor, som også kan bruges til at komme ind, især gendannelse og skift af faktor. Uden de tre oplysninger kan testeren finde huller, men ikke vurdere, om de er tilsigtede.
En regel med undtagelser
Tofaktor betyder, at brugeren skal vise noget mere end en adgangskode for at logge ind, eksempelvis en kode fra en app eller en godkendelse på telefonen. Formålet er, at en stjålet adgangskode ikke alene er nok.
I praksis er tofaktor en regel, som sættes op i et eller flere systemer, og regler har undtagelser. Nogle er bevidste: en servicekonto, der ikke kan bruge en telefon, eller et ældre system, der ikke understøtter det. Andre er glemt: en gammel loginside, en adgang for leverandøren eller en fælles postkasse. Testen kan bidrage med at gøre forskellen synlig. Det er en af de mest konkrete ting, en bestilling om tofaktor kan bede om.
Login som testområde i bredere forstand er beskrevet i → Login og adgangskoder. Her er fokus på det, der er særligt for tofaktor.
Kortlæg, hvor tofaktor gælder
Før testen bør virksomheden lave en oversigt over sine indgange og angive for hver, om tofaktor er krævet. Oversigten er nyttig i sig selv, også uden en test. Giv hver indgang en ejer, så det er klart, hvem der kan svare på spørgsmål om opsætningen, hvis testeren finder noget uventet.
- Fjernadgang · VPN og andre adgange udefra til kontornettet.
- Mail og samarbejde · webmail og cloudtjenester, som medarbejderne bruger.
- Administration · adgange til at styre systemer, hjemmeside og webshop.
- Kunder · login i kundeportalen eller webshoppen, hvis kunderne har tofaktor.
- Leverandører · de adgange, som driftsleverandøren og andre partnere bruger.
Fjernadgang og leverandøradgange er ofte de mest følsomme, fordi de fører direkte ind i nettet. De har deres egne opslag. → Fjernadgang og VPN i penetrationstesten · → Leverandørers fjernadgang
Hvis flere systemer bruger fælles login, kan tofaktor være sat op ét sted og gælde mange. Det gør det centrale sted vigtigt, men det gør også systemer, der ligger uden for det fælles login, til mulige undtagelser. → Fælles login (single sign-on) i testen
Undtagelserne er ofte det vigtigste
En test, der kun bekræfter, at tofaktor virker på den indgang, alle bruger, har begrænset værdi. Det mere brugbare spørgsmål er, om der findes veje uden om. Det kan være en ældre loginform, som stadig accepterer adgangskode alene, en programadgang, der ikke kræver ekstra faktor, eller en konto, der er undtaget af praktiske grunde og glemt igen.
Skriv de kendte undtagelser ind i bestillingen med begrundelse. Så kan testeren skelne mellem det, virksomheden har valgt, og det, virksomheden ikke vidste. Bed om, at rapporten holder de to grupper adskilt. Et fund om en bevidst undtagelse kan stadig være relevant, men det kalder på en anden beslutning end et fund om en glemt.
Hvis mailen er hostet i cloud, styres tofaktor ofte i udbyderens administration. Testen kan se på virksomhedens egen opsætning, ikke på udbyderens platform. → Mailtjenester og penetrationstest · → Microsoft 365 og testen
Gendannelse og skift af faktor
Brugere mister telefoner og skifter udstyr. Derfor har ethvert tofaktorsystem en måde at nulstille eller skifte faktor på. Den funktion er en indgang i sig selv. Hvis den kan bruges af andre end den rette person, er tofaktoren ikke stærkere end gendannelsen.
Gendannelse sker ofte gennem en henvendelse til IT eller driftsleverandørens support. Køberens spørgsmål kan være, hvad supporten kræver for at nulstille en brugers faktor, og om det er beskrevet. En teknisk test kan undersøge de automatiske funktioner. Om supportens procedure skal afprøves ved at nogen ringer og udgiver sig for at være en medarbejder, er en form for social engineering, som kræver egne aftaler og samtykke. → Social engineering i en sikkerhedstest
Beskriv i bestillingen, hvilke gendannelsesveje der findes, og om de skal med. Nævn også, hvordan nye medarbejdere får registreret deres første faktor. Perioden mellem oprettelse af kontoen og registreringen kan være en undtagelse, som ingen har tænkt over, og den hører naturligt med i det samme spørgsmål.
Testkonti med tofaktor
For at teste indgange med tofaktor skal testeren normalt have testkonti, der er sat op som almindelige brugere, også med en faktor. Det kræver, at nogen i virksomheden opretter kontiene og registrerer en faktor, som testeren kan bruge. Det kan virke bøvlet, men alternativet er at undtage testkontiene fra tofaktor, og så tester testen ikke det, den skal.
Aftal, hvem der opretter kontiene, hvilke roller de har, og hvordan de lukkes efter testen. Registrerede faktorer skal fjernes igen. → Testkonti og testdata
Overvej også, om testen skal undersøge, hvad der sker, hvis tofaktor allerede er omgået. Det kan være relevant at vide, hvad en bruger med en gyldig session kan nå. Det er et andet spørgsmål end selve indgangen og bør stå for sig i opgaven.
Det skal I lade være med
- At skrive, at I har tofaktor, og stoppe der. Beskriv, hvor reglen gælder, og hvor den ikke gør.
- At undtage testkontiene fra tofaktor. Så tester testen en anden situation end den rigtige.
- At glemme gendannelsen. Nulstilling af faktor er en indgang på linje med login.
- At skjule kendte undtagelser. Testeren skal kunne skelne valgte fra glemte.
- At teste supportens procedure uden aftale. Det er social engineering og kræver samtykke.
Hvad kan og ikke kan konkluderes
En test kan vise, om tofaktor blev krævet på de indgange, der indgik, og om testeren fandt veje uden om på de steder, opgaven omfattede. Den kan ikke vise, at tofaktor gælder alle steder i virksomheden, hvis ikke alle indgange var med.
Den kan heller ikke sige, at en bruger, der godkender en forespørgsel uden at tænke, er beskyttet. Tofaktor beskytter mod en stjålet adgangskode, men ikke mod alt. Rapportens resultat skal læses sammen med listen over indgange og de undtagelser, der var kendt på forhånd.
Tjekliste til tofaktor i bestillingen
- ☐ Er alle indgange listet med angivelse af, om tofaktor kræves?
- ☐ Er kendte undtagelser beskrevet med begrundelse?
- ☐ Er gendannelse og skift af faktor beskrevet?
- ☐ Er det besluttet, om supportens procedure skal afprøves særskilt?
- ☐ Er testkonti oprettet med faktor som almindelige brugere?
- ☐ Er det aftalt, hvordan konti og faktorer fjernes bagefter?
- ☐ Skal rapporten skelne mellem valgte og glemte undtagelser?
Kilder
- OWASP Web Security Testing Guide: autentifikation, herunder flere faktorer og gendannelse, som testområde.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Test med og uden login · Spørgsmål og svar
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT