Brugerautentificeringsforløb · Mindmaps
Brugerautentificeringsforløb. Et redigerbart mindmap med farvede grene, underemner og forbindelser. Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.
Et brugerautentificeringsforløb er vejen fra, at nogen opretter en konto, til at hver senere forespørgsel bliver betroet: loginoplysninger hashes før lagring, verificeres ved login, og derefter træder et sessionstoken i stedet for adgangskoden.
Brugerautentificeringsforløb · Mindmaps
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
Sådan læser du mindmappet
- Begynd ved emnet i midten, og følg en farvet gren til de tilhørende idéer.
- Buede linjer viser sammenhænge; pile bruges, når retningen har betydning.
Register
Denne gren samler “User creates an account”, “The password is salted and hashed before it is ever stored — the service cannot recover the plaintext, and a leaked database does not leak credentials.”, “Hashed credential is stored in the database”, “Client sends email and password”.
Sign in
Denne gren samler “User signs in with credentials”, “Client forwards them to the auth service”, “Hash matches the stored one?”.
Session
Denne gren samler “Auth service creates a session”, “Client stores the session token”.
Protected requests
Denne gren samler “The token proves the session without re-entering the password. Multi-factor authentication inserts a second check at sign-in when the risk profile demands it.”, “Access granted for the session”.
Failure path
Denne gren samler “Sign-in denied”.
Forbindelser på tværs
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.
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
Tilpas emnet i midten
Giv emnet et navn, der passer til dit projekt eller din undervisning.
Udbyg grenene
Rediger idéerne, og tilføj eksempler eller noter.
Forbind beslægtede idéer
Tegn forbindelser på tværs af grene; brug kun pile, når retningen betyder noget.
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.
Rediger dette mindmap i QueryChart
Åbn mindmappet på et redigerbart lærred. Flyt idéer, tilføj grene, og tegn forbindelser.