Hvad er tofaktorautentificering? En letforståelig guide

Tofaktorautentificering (2FA) er et log ind, der kræver to forskellige slags bevis for, at du er den, du siger, du er — typisk noget, du kender, som en adgangskode, plus noget, du har, som din telefon eller en sikkerhedsnøgle. Hvis en kriminel stjæler eller gætter din adgangskode, kommer de stadig ikke ind uden den anden faktor. Det er en af de enkleste måder at beskytte konti, der betyder noget.

Hvorfor det betyder noget, når du bygger med AI

Når du beder en AI-builder om »login«, får du typisk e-mail og adgangskode. Det er et fint udgangspunkt, men adgangskoder genbruges, phishes og lækkes. Hvis din app rummer noget værdifuldt — kunderegistreringer, fakturaer, admin-kontrol, betalingsindstillinger — kan en enkelt stjålet adgangskode afsløre det hele.

2FA påvirker også beslutninger, du måske ikke tænker på fra start:

• Hvem skal bruge det. Valgfrit for alle, påkrævet for administratorer, eller påkrævet for alle?
• Hvilke metoder du understøtter. Koder fra en app, sms, passkeys, sikkerhedsnøgler.
• Hvad der sker, når nogen er låst ude. Mistede telefoner er den hyppigste supportanmodning for enhver app med 2FA.
• Hvor det håndhæves. Tjekket skal ske på serveren. En 2FA-skærm, der kun skjuler siden i browseren, kan omgås.

Du behøver ikke selv bygge kryptografien — veltestede biblioteker og auth-udbydere klarer det. Men du skal vide, hvad du skal bede om.

En hverdagsanalogi

Tænk på et bankboksrum. For at åbne et skrin skal du bruge dit ID (noget banken tjekker, at du er eller kender) og den fysiske nøgle (noget, du har). En tyv, der kopierer din underskrift, har stadig ikke nøglen. En tyv, der stjæler nøglen, kommer stadig ikke forbi ID-kontrollen.

2FA fungerer på samme måde. Adgangskoden er underskriften; telefonen eller sikkerhedsnøglen er den fysiske nøgle. Hver for sig er ingen af dem nok.

De tre slags faktorer

Sikkerhedsstandarder, fx det amerikanske National Institute of Standards and Technology's retningslinjer for digital identitet, inddeler faktorer i tre slags:

Nøgleordet er forskellig. En adgangskode plus et sikkerhedsspørgsmål er to ting, du kender, så det er ikke ægte tofaktorautentificering. Hvis ét datalæk kan afsløre begge, tæller det kun som én.

De almindelige 2FA-metoder sammenlignet

NIST's vejledning betragter metoder, hvor du indtaster en kode (sms, e-mail, autentificeringsapps), som ikke phishing-resistente og markerer afsendelse af koder over telefonnettet som »begrænset«. Passkeys og fysiske sikkerhedsnøgler, baseret på WebAuthn/FIDO2-standarderne, er dem, den regner som phishing-resistente.

En praktisk konklusion: en autentificeringsapp er en stærk og nem standard for de fleste apps, og passkeys er værd at tilbyde, hvis dine brugere er trygge ved dem.

Et praktisk eksempel: 2FA til en kundeportal

Sig, at du har bygget en portal, hvor et lille revisionsfirma deler skattedokumenter med deres kunder. Sådan ser en fornuftig 2FA-opsætning ud, trin for trin.

Aktivering (tilmelding). Priya, en kunde, åbner Indstillinger og klikker »Slå tofaktorautentificering til«. Appen genererer en hemmelighed og viser den som en QR-kode. Hun scanner den med sin autentificeringsapp, som begynder at vise seks-cifrede koder. Hun skriver den aktuelle kode tilbage i portalen for at bevise, at opsætningen virker. Appen viser ti gendannelseskoder og beder hende gemme dem et sikkert sted.

Log ind bagefter.

1. Priya indtaster sin e-mail og adgangskode. Serveren tjekker dem.
2. I stedet for at logge hende direkte ind markerer serveren sessionen som »adgangskode OK, anden faktor afventer« og viser kodeskærmen.
3. Hun indtaster koden fra sin app. Serveren tjekker den mod hendes gemte hemmelighed og tillader lidt tidsforskydning.
4. Først nu opretter serveren en fuld session og lader hende se dokumenterne.

Hvad en angriber ser. Hvis Priyas adgangskode lækkede fra et andet site, sidder angriberen fast i trin 3. Hvert forkert kodeforsøg tælles, og efter flere forkerte forsøg låses kontoen midlertidigt, og Priya får en e-mail.

Mister hun sin telefon. Priya bruger en af sine gendannelseskoder til at logge ind, slår 2FA fra og til igen med sin nye telefon og får friske gendannelseskoder. Den brugte kode kan aldrig bruges igen.

For medarbejdere. Firmaets revisorer kan se alle kunders filer, så portalen kræver 2FA for medarbejderkonti; de kan ikke nå dashboardet, før de har tilmeldt sig.

Almindelige termer forklaret

Almindelige fejl og misforståelser

• »2FA gør en konto uhackbar.« Det gør den meget sværere at hacke. Phishing-sider kan stadig fange indtastede koder i realtid, og det er grunden til, at passkeys findes.
• At tjekke koden kun i browseren. Hvis serveren udsteder en fuld session efter adgangskoden, er kodeskærmen blot pynt. Serveren skal afvise adgang, indtil den anden faktor er godkendt.
• Ingen grænse for kodegæt. En seks-cifret kode har en million mulige værdier. Uden hastighedsbegrænsning og låsning kan en angriber blot blive ved med at gætte.
• At glemme gendannelse. Uden gendannelseskoder bliver hver mistet telefon en supportsag eller en låst kunde.
• At gemme TOTP-hemmeligheden uforsigtigt. Den delte hemmelighed bør krypteres i databasen og aldrig vises igen efter opsætningen.
• At lade brugere slå 2FA fra uden nyt tjek. Deaktivering af 2FA eller ændring af konto-e-mailen bør kræve adgangskoden og en aktuel kode.
• At adgangskode plus sikkerhedsspørgsmål tæller som 2FA. Det gør det ikke — begge dele er ting, du kender.

Hvad du beder din AI-builder om

• »Tilføj valgfri tofaktorautentificering med en autentificeringsapp (TOTP), med en QR-kode til opsætning og en bekræftelseskode, før den slås til.«
• »Vis ti engangs-gendannelseskoder, når 2FA er slået til. Gem dem hashede, ligesom adgangskoder.«
• »Håndhæv 2FA på serveren: ingen fuld session, før den anden faktor er godkendt.«
• »Begræns antallet af kodeforsøg, og lås login i 15 minutter efter gentagne fejl. Send brugeren en e-mail, når det sker.«
• »Kræv 2FA for administratorkonti.«
• »Bed om adgangskoden og en aktuel kode, før 2FA slås fra, eller konto-e-mailen ændres.«
• »Brug et velkendt bibliotek eller vores auth-udbyders indbyggede 2FA — skriv ikke selv kryptografien.«
• »Forklar hvilken metode du brugte, og hvor hemmelighederne gemmes.«

Hvis du bruger en hostet auth-udbyder, så tjek, om den allerede tilbyder 2FA eller passkeys; at slå en indbygget funktion til er normalt sikrere end egen kode. Den trin-for-trin-version findes i sådan tilføjer du tofaktorautentificering, og hvad autentificering er dækker login-grundlaget under den.

Tofaktorautentificering i Mythex

Mythex indeholder ikke et indbygget login-system til din apps brugere, så 2FA er en del af den autentificeringsløsning, du vælger — dit eget e-mail-og-adgangskode-login bygget oven på projektets database, eller en hostet udbyder, der tilbyder 2FA. Du beder agenten tilføje det i chatten, og eventuelle udbydernøgler lægges i projektets hemmeligheder og ikke i selve chatten. Dokumentationens opskrift på tilføjelse af login til din app har en startprompt, du kan tilpasse, og sikkerhed for apps, du bygger dækker vanerne omkring nøgler. Før lancering kan du gennemgå sikkerhedstjeklisten for AI-byggede apps.

Spørgsmål