Gå til indhold
atlas

To-faktorautentificering

Også kendt som: 2FA, tofaktorgodkendelse, totrinsbekræftelse

Den mest udbredte form for MFA, hvor et login kræver præcis to uafhængige beviser, typisk en adgangskode og en engangskode.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

En form for multifaktorgodkendelse begrænset til præcis to faktorer fra forskellige kategorier, oftest en adgangskode kombineret med en kode eller godkendelse fra en enhed, brugeren har.

Forklaret enkelt

Som en dør med to forskellige låse - den ene åbnes med noget, du husker, den anden med noget, du har i lommen.

I praksis

En rådgiver i en pensionskasse, der arbejder hjemmefra, logger ind på sin arbejdscomputer med sin adgangskode og taster derefter den korte kode, som en kode-app på hendes telefon viser, før sessionen åbner.

Hvorfor det betyder noget

Det er det trin, de fleste tjenester faktisk tilbyder, så det er her, de fleste først får beskyttelse ud over en adgangskode - men to beviser af samme slags, fx to adgangskoder, tæller ikke.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Lav en liste over de vigtigste konti, først e-mail, fordi den kan nulstille andre adgangskoder, derefter netbank, regnskab, cloudlager, sociale medier og virksomhedens domæne og webhotel.
  2. Slå to-faktor login, også kaldet totrinsbekræftelse, til i sikkerhedsindstillingerne på hver af tjenesterne.
  3. Vælg den stærkeste anden faktor, tjenesten tilbyder, først en passkey eller sikkerhedsnøgle, derefter en autentifikator-app og kun sms, hvis intet andet findes.
  4. Gem gendannelseskoderne ved tilmelding, opbevar dem offline eller i en password manager, og registrér en reservefaktor som en ekstra nøgle eller en anden enhed.
  5. Giv hver medarbejder sin egen konto i stedet for fælles logins, og hvor en fælles konto ikke kan undgås, så læg dens anden faktor i en password manager eller på en enhed, virksomheden styrer, og ikke på én medarbejders telefon.
  6. Brug MitID Erhverv, når medarbejdere handler på virksomhedens vegne i offentlig selvbetjening, og lad administratoren fjerne deres adgang, når de stopper.
  7. Lær alle at afvise login-anmodninger, de ikke selv har startet, aldrig at læse en kode op for nogen, der ringer, og straks at skifte adgangskode, hvis en uventet anmodning dukker op.
  8. Tjek mindst én gang om året, og når nogen stopper, at to-faktor login stadig er slået til på alle vigtige konti, og at telefonnumre og adresser til gendannelse er opdaterede.

Typiske faldgruber

  • At miste adgangen, når telefonen udskiftes, fordi gendannelseskoderne aldrig blev gemt.
  • At lade gendannelse via sms eller e-mail stå til som reserve, hvilket ophæver en stærk anden faktor.
  • At godkende en anmodning eller læse en kode op for en, der ringer og udgiver sig for at være fra banken eller IT-supporten.

Gode vejledninger

Teknisk uddybning

Tofaktorautentificering er MFA med præcis to faktorer, i praksis næsten altid en memoreret hemmelighed plus en besiddelsesfaktor. Betegnelserne "2FA" og "totrinsbekræftelse" (Googles navn, da funktionen blev åbnet for alle konti i 2011) bruges ofte i flæng, men er ikke helt ens: to trin er ikke to faktorer, hvis begge tilhører samme kategori, og en kode sendt til en mailboks, der kan nås med den samme adgangskode, tilføjer et trin uden at tilføje en uafhængig faktor. Standarderne undgår de løse begreber. NIST SP 800-63B taler om multifaktorautentificering på AAL2, og PSD2-reglerne om stærk kundeautentifikation kræver to uafhængige elementer fra forskellige kategorier.

De udbredte andenfaktorer er meget forskellige i styrke. Sms- og opkaldskoder afhænger af telefonnettet og er udsat for SIM-swap-svindel, nummerflytning og SS7-aflytning; NIST klassificerer dem som "restricted". TOTP-apps (RFC 6238) fjerner afhængigheden af telefonnettet, men giver stadig en kode, som et menneske kan lokkes til at taste ind på en phishingside. Push-godkendelser er bekvemme, men inviterer til prompt bombing, medmindre number matching håndhæves. En FIDO U2F- eller FIDO2-sikkerhedsnøgle brugt som anden faktor efter adgangskoden er phishing-resistent, fordi det signerede svar er bundet til sitets origin. En passkey med brugerverifikation (pinkode eller biometri på enheden) er i sig selv to faktorer i ét trin, og derfor beskrives login med passkeys ofte som en erstatning for mønstret adgangskode-plus-kode snarere end en tilføjelse til det.

Det svageste led er som regel ikke den primære andenfaktor, men reservevejen. Tjenester, der tilbyder sms som backup til en sikkerhedsnøgle, kontogendannelse via mail eller nulstilling hos servicedesken på baggrund af kontrolspørgsmål, reducerer den reelle styrke til den svageste aktiverede vej; angribere går efter netop de veje, fordi hovedfaktoren er stærk. Gendannelseskoder - en kort liste af engangshemmeligheder udstedt ved tilmelding - er en bedre reserve, hvis de opbevares offline.

2FA beskytter heller ikke det, der sker efter login. Sessionscookies og refresh tokens opsnappet af adversary-in-the-middle-proxyer, malware der stjæler browsercookies, og ældre protokoller, der kun kræver adgangskode, omgår alle den anden faktor. Organisationer håndhæver derfor 2FA via central politik (betinget adgang i identitetsudbyderen) frem for frivilligt tilvalg pr. applikation, slår ældre autentificering fra og overvåger registrering af nye enheder, som er et typisk persistenstrin efter en kontoovertagelse. I Danmark leverer MitID (til borgere) og MitID Erhverv (til virksomheder og organisationer) det nationale multifaktorlogin, baseret på et bruger-ID og et identifikationsmiddel som MitID-appen, en kodeviser, en kodelæser eller en MitID-chip.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Digital identitet
  2. →Adgangskode
  3. →Loginoplysning (credential)
  4. →Autentificering
  5. →Autentificeringsfaktor
  6. →To-faktorautentificering

Relationer

Afbøder
Phishing

Kilder og videre læsning

Standarder og officielle tekster

  • NIST SP 800-63B - Digital Identity Guidelines, Authentication · NIST

Kursusmateriale

  • Cyber Security Fast Track - Ordliste

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.