Brugerautentificeringsforløb — fra oprettelse til valideret session

Brugerautentificeringsforløb — fra oprettelse til valideret session

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs de tre kolonner fra venstre mod højre: Oprettelse, Login, Session.
• De fire baner er aktørerne, og adgangskoden forlader aldrig de tre øverste — kun hashes når frem til »Database«-banen.
• Beslutningen »Matcher hashen den gemte?« deler loginet op i sessionsvejen og afvisningen »Login nægtet«.

Oprettelse

»Brugeren opretter en konto« og »Klienten sender e-mail og adgangskode« fører ind i »Autentificeringstjenesten hasher adgangskoden« — det øjeblik, hvor adgangskoden holder op med at kunne gendannes. »Den hashede loginoplysning gemmes i databasen« er enden på oprettelsen: databasen rummer nu en saltet hash, og bemærkningen til trinnet forklarer, at tjenesten ikke kan gendanne klarteksten, hvilket er hele pointen med hashing.

Login

»Brugeren logger ind med sine loginoplysninger« og »Klienten sender dem videre til autentificeringstjenesten« gentager den første halvdel af rejsen, og »Matcher hashen den gemte?« er verifikationen: den indkomne adgangskode hashes på samme måde og sammenlignes. »Nej«-grenen ender i »Login nægtet«; »Ja«-grenen fortsætter til oprettelsen af sessionen.

Session

»Autentificeringstjenesten opretter en session« udsteder det token, der erstatter adgangskoden, »Klienten gemmer sessionstokenet« flytter det over til klienten, og »Beskyttede forespørgsler bærer tokenet; serveren validerer det« er systemets normaltilstand — hver beskyttet forespørgsel beviser sig selv med tokenet. »Adgang givet for sessionen« lukker forløbet: brugeren er autentificeret, så længe sessionen lever, ikke kun for en enkelt forespørgsel.

Key relationships and takeaways

• Adgangskoder hashes før lagring — databasen rummer en saltet envejshash, aldrig klarteksten.
• Loginet sammenligner hashes, så selv autentificeringstjenesten kan ikke gendanne den gemte adgangskode.
• Sessionstokenet erstatter adgangskoden ved de efterfølgende forespørgsler, og det er dét, der gør autentificering praktisk mulig i stor skala.
• Lagring og verifikation er adskilte hensyn i hver sin bane, så de kan beskyttes hver for sig.
• Forløbet har samme form, uanset om tokenet er en serverside-session eller et JWT — se den visuelle forklaring om JWT for tokenets mekanik.

When to use this visual

• At lære et nyt team den sikre form på autentificering, før de designer deres første login.
• At gennemgå et autentificeringsforløb for de klassiske fejl — at gemme klartekst, at sammenligne klartekst, at stole på klienten.
• At give en samtale om tofaktorautentificering et fælles grundlag og vise, hvor den kobles ind i forløbet.

Sådan fungerer det

1. Omdøb aktørerne til jeres eget system

   Erstat »Klientapp« og »Autentificeringstjeneste« med jeres reelle komponenter — jeres webapp, jeres identitetsudbyder — og tilføj dem, det generiske diagram mangler.

2. Tilføj tofaktorautentificering

   Indsæt et MFA-trin ved login, mellem hash-tjekket og oprettelsen af sessionen, med en gren til verifikation af den anden faktor.

3. Vis vejen til nulstilling af adgangskode

   Tilføj en nulstillingsgren ud fra beslutningen ved login — glemt adgangskode, nulstillingstoken, sæt ny adgangskode — hver med sin egen eksplicitte sluttilstand.

4. Notér tokenets livscyklus

   Skriv på sessionsboksen jeres regler for tokenets udløb, tilbagekaldelse og fornyelse, og henvis til den visuelle forklaring om JWT, hvis I udsteder JWT'er.

Ofte stillede spørgsmål

Hvad er den sikre måde at gemme adgangskoder på?

Gem aldrig selve adgangskoden. Gem en saltet hash — en envejsfunktion anvendt på adgangskoden plus et tilfældigt salt — og kassér klarteksten. Ved login hasher du den indkomne adgangskode på samme måde og sammenligner de to hashes. Lækker databasen, får angriberen hashes, der ikke kan vendes om, og det er præcis den egenskab, diagrammets hashing-bokse findes for at vise.

Hvad er forskellen på hashing og kryptering?

Kryptering kan vendes om — med nøglen kan du gendanne den oprindelige værdi. Hashing er envejs — der er ingen nøgle og ingen vej tilbage. Til adgangskoder vil du have hashing, for du får aldrig brug for klarteksten igen, kun for at kunne verificere. Det er derfor, diagrammet siger »hasher« og ikke »krypterer«; at kryptere adgangskoder er en almindelig og farlig forveksling.

Hvordan erstatter et sessionstoken adgangskoden?

Efter et vellykket login opretter autentificeringstjenesten en session og giver klienten et token — en tilfældig værdi eller et signeret JWT — der står for den autentificerede bruger. Beskyttede forespørgsler bærer tokenet, og serveren validerer det i stedet for at bede om adgangskoden igen. Det er dét, der gør autentificering praktisk mulig ved gentagne forespørgsler, og derfor er tokenets udløb den reelle sikkerhedsgrænse.

Hvor passer tofaktorautentificering ind i forløbet?

MFA er et ekstra tjek ved login, efter at adgangskoden er verificeret, og før sessionen oprettes: brugeren leverer en anden faktor — en engangskode, en authenticator-app, en hardwarenøgle. Diagrammets login-kolonne er der, hvor det trin kobles ind. MFA ændrer hverken hashing eller sessionens mekanik; den hæver barren for den ene beslutning, »Matcher hashen den gemte?«, ved at lægge et ekstra bevis oveni.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det autentificeringslærred, du ser her, som dit eget diagram, omdøb aktørerne til jeres eget system, og tilføj jeres reelle kontroller.

Redigér dette diagram i QueryChart (FlowJam)