Slik legger du til tofaktorautentisering i appen

For å legge til tofaktorautentisering (2FA) i appen din lar du brukere koble til en autentiseringsapp ved å skanne en QR-kode. Du ber om seks-sifferkoden den viser etter passordet, og oppretter først en full sesjon på serveren når koden stemmer. Gi hver bruker engangs-gjenopprettingskoder når de slår på 2FA, begrens hvor mange koder noen kan gjette, og krev både passord og en gjeldende kode før 2FA kan slås av. Hvis du bruker en hostet autentiseringsleverandør, slår du på dens innebygde flerfaktoralternativ i stedet for å bygge eget.

Denne guiden går gjennom valgene, den nøyaktige flyten, ledetekster du kan gi en KI-bygger, og feilene som får 2FA til å se ut som om den finnes, men som ikke gjør noe. Hvis konseptet er nytt for deg, start med hva tofaktorautentisering er.

Før du starter: du trenger en fungerende innlogging

2FA legger seg oppå en eksisterende pålogging. Du trenger én av disse først:

• Din egen innlogging, med brukere og hashede passord lagret i appens database.
• En hostet autentiseringsleverandør som administrerer brukere for deg.

Hvis du ikke har noen av dem ennå, start med slik legger du til innlogging i appen din. Resten av denne guiden forutsetter at et passordsteg allerede fungerer.

Velg din andre faktor

TOTP står for time-based one-time password, standarden (RFC 6238) som autentiseringsapper bruker. Serveren din og brukerens telefon deler en hemmelighet. Begge lager samme korte kode ut fra hemmeligheten og gjeldende tid, og koden endrer seg vanligvis hvert 30. sekund. Det kreves ingen nettverksforbindelse eller SMS-leverandør.

Passnøkler erstatter eller supplerer passord med en kryptografisk nøkkel som lagres på brukerens enhet. De er sterkere, men mer arbeid å bygge selv, så mange apper starter med TOTP og legger til passnøkler senere, eller henter dem fra en autentiseringsleverandør.

Bygge det selv eller slå det på?

Sjekk leverandørens gjeldende dokumentasjon for hvilke faktorer den støtter og på hvilke abonnementer. Uansett bør du aldri skrive kodegenereringsmatematikken selv. Bruk et mye brukt bibliotek.

Bestem policyen først

Svar på disse før du skriver ledetekster, fordi de endrer designet:

1. Hvem må bruke det? Valgfritt for alle, påkrevd for administratorer og ansatte, eller påkrevd for alle. Det er vanlig å kreve det for alle med adminrettigheter. Se rollebasert tilgangskontroll.
2. Hvor ofte må brukere skrive inn en kode på nytt? Ved hver innlogging, eller én gang per enhet i 30 dager («husk denne enheten»).
3. Hvilke handlinger krever en ny kontroll? Å endre e-post, utbetalingsopplysninger eller å slå av 2FA er gode kandidater. Dette kalles step-up-autentisering.
4. Hva er prosessen ved tapt telefon? Gjenopprettingskoder, pluss en manuell reserve du er villig til å kjøre.

Steg for steg: TOTP-2FA på din egen innlogging

1. Lagre de riktige feltene

Hver bruker trenger: om 2FA er aktivert, TOTP-hemmeligheten (kryptert i hvile, ikke i klartekst), tidspunktet den ble aktivert, og en liste med gjenopprettingskoder lagret hashet, slik passord lagres. Legg også til et sted der du teller mislykkede forsøk.

2. Registrering

1. Brukeren åpner innstillingene og klikker Slå på tofaktorautentisering.
2. Serveren genererer en ny hemmelighet og returnerer den som en QR-kode, pluss tekstversjonen for folk som ikke kan skanne.
3. Brukeren skanner den i en autentiseringsapp og skriver inn gjeldende kode.
4. Serveren sjekker koden. Først når den er riktig, lagrer den hemmeligheten og markerer 2FA som aktivert.
5. Appen viser 8–10 gjenopprettingskoder én gang, og ber brukeren lagre dem.

Steg 4 er viktig: å slå på 2FA før koden er bekreftet låser ute alle hvis skanning mislyktes.

3. Innlogging med et andre steg

1. Brukeren sender inn e-post og passord. Serveren sjekker dem.
2. Hvis 2FA er aktivert, oppretter serveren ikke en full sesjon. Den oppretter i stedet en kortvarig tilstand «andre faktor venter».
3. Appen viser kodeskjermen. Serveren sjekker koden og tillater et lite tidsvindu for klokkedrift.
4. Først nå utsteder serveren den ekte sesjonen.

Hver beskyttet rute og API-endepunkt må avvise den ventende tilstanden. En 2FA-skjerm som bare skjuler sider i nettleseren kan omgås ved å kalle API-et direkte.

4. Grenser og varsler

En seks-sifferkode har en million kombinasjoner, som er mulig å gjette uten grenser. Begrens forsøkene, lås det andre steget i en periode etter gjentatte feil, og send brukeren en e-post når det skjer. Se hastighetsbegrensning og slik sender du e-post fra appen din.

5. Gjenoppretting og avslåing

• En gjenopprettingskode virker én gang, og slettes deretter.
• Å slå av 2FA krever passordet og en gjeldende kode eller gjenopprettingskode.
• Å generere nye gjenopprettingskoder ugyldiggjør det gamle settet.
• Send brukeren en e-post hver gang 2FA slås på eller av.

Ledetekster til KI-byggeren

Start med kjerneflyten:

Legg til valgfri tofaktorautentisering med autentiseringsapper (TOTP) til vår eksisterende innlogging med e-post og passord. Bruk et veletablert TOTP-bibliotek, ikke skriv algoritmen selv. I Innstillinger viser du en QR-kode og tekst-hemmeligheten, og aktiverer 2FA først etter at brukeren har skrevet inn en gyldig kode. Lagre hemmeligheten kryptert og vis den aldri igjen etter oppsett. Vis 10 engangs-gjenopprettingskoder én gang, og lagre dem hashet.

Deretter håndhevelsen, der generert kode oftest kommer til kort:

Håndhev 2FA på serveren. Etter et riktig passord får brukere med 2FA aktivert en kortvarig venstetilstand, ikke en full sesjon. Hver beskyttede side og API-rute må avvise venstetilstanden. Begrens kodeforsøk til 5, lås deretter det andre steget i 15 minutter, og send brukeren en e-post.

Deretter policy:

Krev 2FA for administratorkontoer: en admin uten 2FA sendes til oppsett og kommer ikke til dashbordet før det er gjort. Krev passord og en gjeldende kode for å slå av 2FA eller endre kontoens e-post. Send brukeren en e-post når 2FA aktiveres eller deaktiveres.

Til slutt ber du agenten forklare hva den har bygget:

List opp hver rute som sjekker at et andre steg er fullført, hvor TOTP-hemmeligheten og gjenopprettingskodene lagres, og hvordan de er beskyttet.

Vanlige feil

• Sesjon utstedt etter passordet. Den alvorligste feilen. Hvis den fulle sesjonen finnes før koden er sjekket, er 2FA bare pynt. Test ved å kalle en beskyttet API etter bare passordsteget.
• Ingen grense for forsøk. Ubegrensede gjetninger gjør koden mulig å knekke med brute force.
• Hemmeligheter eller gjenopprettingskoder i klartekst. Et databaselekkasje gir da bort alles andre faktor.
• Aktivere før bekreftelse. Brukere som skannet feil blir låst ute ved neste innlogging.
• Ingen gjenopprettingsvei. Hver tapt telefon blir en støttesak eller en tapt kunde.
• Enkel avslåing. Hvis en stjålet sesjon kan slå av 2FA uten kode, er beskyttelsen borte.
• Koder i logger. Sørg for at koder og hemmeligheter aldri dukker opp i serverlogger eller feilmeldinger.
• Sjekker bare på innloggingssiden. Tilbakestilling av passord, innlogging med «magisk lenke» og eventuell sosial pålogging må også respektere 2FA, ellers blir de en omgåelse.

Testsjekkliste

• Registrering fullføres først etter en gyldig kode
• Innlogging med riktig passord men uten kode gir ingen tilgang til noen beskyttet side eller API
• En feil kode avvises; gjentatte feil kode utløser låsingen og en e-post
• En kode fra noen minutter siden avvises
• Hver gjenopprettingskode virker nøyaktig én gang
• Å slå av 2FA krever passord og en gjeldende kode
• Tilbakestilling av passord omgår ikke 2FA
• Administratorer uten 2FA kommer ikke til administrasjonssider (hvis det kreves)
• Hemmeligheter og gjenopprettingskoder er kryptert eller hashet i databasen
• Ingen koder eller hemmeligheter dukker opp i logger

Kjør hele sikkerhetssjekklisten for KI-bygde apper før lansering også.

Legge til 2FA i Mythex

Mythex inkluderer ikke et innebygd innloggingssystem for sluttbrukerne av appen din. 2FA er derfor en del av den autentiseringsløsningen du velger: din egen innlogging med e-post og passord og prosjektets database, eller en hostet leverandør med flerfaktorstøtte. Du beskriver det du vil ha i chatten med ledetekster som de over. Nøkler til leverandøren legges i prosjekthemmeligheter (via /secrets, prosjektinnstillingene eller hemmelighetskortet agenten viser), ikke i meldingsfeltet. Oppskriften Legg til innlogging i appen din i dokumentasjonen har en startledetekst, og Sikkerhet for apper du bygger dekker vanene rundt nøkler og tillatelser. Etter at agenten er ferdig, test hvert punkt på sjekklisten i forhåndsvisningen før du publiserer.

Spørsmål