Hva er tofaktorautentisering? En enkel guide

Tofaktorautentisering (2FA) er en innlogging som krever to ulike typer bevis på at du er den du sier du er – typisk noe du kjenner, som et passord, pluss noe du har, som telefonen din eller en sikkerhetsnøkkel. Hvis en kriminell stjeler eller gjetter passordet ditt, kommer de fortsatt ikke inn uten den andre faktoren. Det er en av de enkleste måtene å beskytte kontoer som betyr noe.

Hvorfor det betyr noe når du bygger med AI

Når du ber en AI-byggeren om «innlogging», får du som regel e-post og passord. Det er en fin start, men passord blir gjenbrukt, lurt fra folk og lekket. Hvis appen din har noe verdifullt – kundeposter, fakturaer, admin-kontroller, betalingsinnstillinger – kan ett stjålet passord eksponere alt.

2FA påvirker også valg du kanskje ikke tenker på i starten:

• Hvem som må bruke den. Valgfritt for alle, påkrevd for administratorer, eller påkrevd for alle?
• Hvilke metoder du støtter. Koder fra en app, tekstmeldinger, passkeys, sikkerhetsnøkler.
• Hva som skjer når noen er utelåst. Mistede telefoner er den vanligste supporthenvendelsen for enhver app med 2FA.
• Hvor det håndheves. Sjekken må skje på serveren. En 2FA-skjerm som bare skjuler siden i nettleseren, kan omgås.

Du trenger ikke bygge kryptografien selv – veldokumenterte biblioteker og autentiseringstjenester tar seg av det. Men du må vite hva du skal be om.

En hverdagslig sammenligning

Tenk på et bankboksrom. For å åpne boksen trenger du legitimasjonen din (noe banken sjekker at du er eller kan) og den fysiske nøkkelen (noe du har). En tyv som kopierer signaturen din, har fortsatt ikke nøkkelen. En tyv som stjeler nøkkelen, kommer fortsatt ikke forbi legitimasjonssjekken.

2FA fungerer på samme måte. Passordet er signaturen; telefonen eller sikkerhetsnøkkelen er den fysiske nøkkelen. Hver for seg er ikke nok.

De tre typene faktorer

Sikkerhetsstandarder, som det amerikanske NIST sine retningslinjer for digital identitet, deler faktorer inn i tre typer:

Nøkkelordet er ulike. Et passord pluss et sikkerhetsspørsmål er to ting du kjenner, så det er ikke ekte tofaktorautentisering. Hvis ett lekkasje kan avsløre begge, teller det bare som én.

De vanlige 2FA-metodene sammenlignet

NIST sine retningslinjer behandler metoder der du skriver inn en kode (SMS, e-post, autentiseringsapper) som ikke motstandsdyktige mot phishing, og markerer sending av koder over mobilnettet som «begrenset». Passkeys og maskinvare-sikkerhetsnøkler, basert på WebAuthn/FIDO2-standardene, er de som regnes som motstandsdyktige mot phishing.

Et praktisk poeng: en autentiseringsapp er et sterkt og enkelt standardvalg for de fleste apper, og passkeys er verdt å tilby hvis brukerne er komfortable med dem.

Et praktisk eksempel: 2FA for et kundeportal

Anta at du har bygget et portal der et lite regnskapsbyrå deler skattedokumenter med kundene sine. Slik fungerer et fornuftig 2FA-oppsett, steg for steg.

Slå det på (registrering). Ingrid, en kunde, åpner Innstillinger og klikker «Slå på tofaktorautentisering». Appen lager en hemmelighet og viser den som en QR-kode. Hun skanner den med autentiseringsappen sin, som begynner å vise seksifrede koder. Hun skriver den gjeldende koden tilbake i portalen for å bevise at oppsettet fungerer. Appen viser ti gjenopprettingskoder og ber henne lagre dem et trygt sted.

Logge inn etterpå.

1. Ingrid skriver inn e-post og passord. Serveren sjekker dem.
2. I stedet for å logge henne rett inn, markerer serveren økten som «passord OK, andre faktor venter» og viser kodeskjermen.
3. Hun skriver koden fra appen sin. Serveren sjekker den mot den lagrede hemmeligheten, med en liten toleranse for klokkeavvik.
4. Først da lager serveren en full økt og lar henne se dokumentene.

Hva en angriper ser. Hvis Ingrids passord ble lekket fra en annen side, står angriperen fast i steg 3. Hvert mislykket kodeforsøk telles, og etter flere feil forsøk låses kontoen midlertidig, og Ingrid får en e-post.

Mister telefonen. Ingrid bruker en av gjenopprettingskodene sine for å logge inn, slår 2FA av og på igjen med den nye telefonen og får nye gjenopprettingskoder. En brukt kode kan aldri brukes igjen.

For ansatte. Regnskapsførerne i byrået kan se alle klientenes filer, så portalen krever 2FA for ansattkontoer; de kommer ikke til dashbordet før de har registrert seg.

Vanlige begreper forklart

Vanlige feil og misforståelser

• «2FA gjør en konto uhackbar.» Den gjør den mye vanskeligere. Phishing-sider kan fortsatt fange opp skrevne koder i sanntid, og derfor finnes passkeys.
• Å sjekke koden bare i nettleseren. Hvis serveren gir full økt etter passordet, er kodeskjermen bare pynt. Serveren må nekte tilgang til den andre faktoren er bestått.
• Ingen grense for kodegjetting. En seksifret kode har en million muligheter. Uten hastighetsbegrensning og utlåsing kan en angriper bare fortsette å gjette.
• Å glemme gjenoppretting. Uten gjenopprettingskoder blir hver tapt telefon en supportsak, eller en utelåst kunde.
• Å lagre TOTP-hemmeligheten uforsiktig. Den delte hemmeligheten bør krypteres i databasen, og aldri vises igjen etter oppsett.
• La brukere slå av 2FA uten ny kontroll. Å deaktivere 2FA eller endre e-posten bør kreve passordet og en gjeldende kode.
• Passord pluss sikkerhetsspørsmål teller som 2FA. Det gjør det ikke – begge er ting du kjenner.

Hva du bør be AI-byggeren om

• «Legg til valgfri tofaktorautentisering med en autentiseringsapp (TOTP), med QR-kode for oppsett og en bekreftelseskode før den slås på.»
• «Vis ti engangs gjenopprettingskoder når 2FA er aktivert. Lagre dem hashet, som passord.»
• «Håndhev 2FA på serveren: ingen full økt før den andre faktoren er bestått.»
• «Begrens kodeforsøk og lås innloggingen i 15 minutter etter gjentatte feil. Send brukeren e-post når det skjer.»
• «Krev 2FA for administratorkontoer.»
• «Be om passordet og en gjeldende kode før 2FA deaktiveres eller kontoens e-post endres.»
• «Bruk et velkjent bibliotek eller den innebygde 2FA-funksjonen til autentiseringsleverandøren vår – ikke skriv kryptografien selv.»
• «Forklar hvilken metode du brukte, og hvor hemmelighetene lagres.»

Hvis du bruker en hostet autentiseringsleverandør, sjekk om den allerede tilbyr 2FA eller passkeys; å slå på en innebygd funksjon er vanligvis tryggere enn egendesignet kode. Den trinnvise versjonen finner du i slik legger du til tofaktorautentisering, og hva autentisering er dekker grunnlaget for innlogging under den.

Tofaktorautentisering i Mythex

Mythex inkluderer ikke et innebygd innloggingssystem for appens brukere, så 2FA er en del av den autentiseringsløsningen du velger – din egen innlogging med e-post og passord, støttet av prosjektets database, eller en hostet leverandør som tilbyr 2FA. Du ber agenten om å legge det til i chatten, og eventuelle leverandørnøkler legges i prosjektets hemmeligheter, ikke i selve chatten. Oppskriften i dokumentasjonen om å legge til innlogging i appen din har en startprompt å tilpasse, og sikkerhet for apper du bygger dekker vanene rundt nøkler. Før lansering, gå gjennom sikkerhetssjekklisten for AI-bygde apper.

Spørsmål