7.3 Kryptering og autentisering i praksis

Aldri lagre passord i klartekst

Kryptering og autentisering er grunnleggende byggesteiner i moderne IT-sikkerhet. Vi starter med den absolutte regelen: aldri lagre passord i klartekst. Når en bruker registrerer seg eller endrer passord, skal du hashe passordet før det lagres.

Her må vi skille to begreper som ofte blandes. Kryptering er toveis – data kan dekrypteres igjen med en nøkkel. Hashing er enveis – du kan ikke gjenskape det originale passordet fra hashen. For passord vil vi ha hashing, fordi vi aldri trenger å lese passordet tilbake; vi trenger bare å sjekke om et nytt innskrevet passord gir samme hash.

Men ikke all hashing er trygg. Algoritmer som MD5 og SHA-1 skal du ikke bruke til passord, og heller ikke SHA-256 uten salt. Grunnen er tredelt. De er for raske – en angriper kan teste milliarder av passord i sekundet. De er sårbare for rainbow tables – forhåndsgenererte tabeller som kobler hash til passord. Og uten salt får like passord lik hash, så angriperen kan knekke mange på en gang. Et salt er en tilfeldig verdi som legges til hvert passord før hashing, slik at to like passord får ulike hasher. Den anbefalte løsningen er bcrypt, en algoritme laget nettopp for passord, som legger til salt automatisk og har en justerbar cost-faktor – jo høyere, jo tregere og dermed sikrere mot gjettangrep.

HTTPS og transport-sikkerhet

Å beskytte passordet i databasen er ikke nok hvis det kan avlyttes på vei dit. Forskjellen mellom HTTP og HTTPS er avgjørende. HTTP sender kommunikasjon i klartekst, som hvem som helst på nettverket kan lese. HTTPS krypterer trafikken med TLS/SSL. Det beskytter mot tre ting: avlytting (ingen kan lese dataene underveis), manipulering (ingen kan endre dem), og identitetsforfalskning (du får bekreftet at du faktisk snakker med riktig server).

Hvordan virker HTTPS? Det skjer i fire steg. Først en handshake, der klient og server blir enige om krypteringsmetode. Så sertifikat-validering, der serveren beviser sin identitet med et digitalt sertifikat utstedt av en betrodd part. Deretter nøkkelutveksling, der de genererer symmetriske nøkler for økten. Og til slutt kryptert kommunikasjon, der all data krypteres med øktnøkkelen.

I praksis er HTTPS enkelt å aktivere. For utvikling kan Flask kjøre med et selvsignert sertifikat ved å sette ssl_context='adhoc'. I produksjon bruker man ekte sertifikater fra en sertifikatutsteder – verktøyet Certbot fra Let's Encrypt gjør dette gratis og automatisk. Lærdommen er enkel og ufravikelig: enhver side som håndterer passord eller sensitiv data, skal bruke HTTPS. Uten det er selv det best hashede passordet sårbart i det øyeblikket det sendes over nettet.

Tokens og OAuth

Når en bruker er logget inn, må serveren huske det på en sikker måte. Tradisjonelt brukes session-basert autentisering: serveren lagrer øktinformasjon, og en cookie med sesjons-ID sendes til klienten, slik at serveren slår opp dataene ved hver forespørsel. Den moderne tilnærmingen er token-basert: all nødvendig informasjon ligger i selve tokenet, så serveren slipper å lagre noe per økt. Det fungerer spesielt godt i distribuerte systemer og API-er. Det helt sentrale er at tokens må være kryptografisk sikre – i Python genererer du dem med secrets.token_urlsafe(32), som gir et uforutsigbart token på 256 bits. Du må aldri bruke vanlige tilfeldige tall til dette.

En elegant utvidelse er OAuth 2.0, standarden bak «Logg inn med Google» og «Logg inn med Facebook». Den lar en app få tilgang til brukerdata uten å dele passord. Flyten er slik: brukeren klikker «Logg inn med Google», din app omdirigerer til Google, brukeren logger inn og godkjenner tilgangen, Google sender brukeren tilbake til din app med en autorisasjonskode, din app bytter koden mot et access token, og bruker tokenet til å hente brukerinfo fra Google.

Fordelene er mange. Brukeren slipper å lage et nytt passord. Din app lagrer aldri passordet – et stort ansvar mindre. Brukeren kan tilbakekalle tilgangen når som helst. Og hele ansvaret for sikker passordhåndtering ligger hos Google, som har langt bedre forutsetninger for det. Et komplett autentiseringssystem kombinerer gjerne alle tre: bcrypt for passord, sikre tokens for økter, og HTTPS for transporten.

Oppsummering

Vi gikk fra teori til praktisk sikkerhet. Passord skal aldri lagres i klartekst, men hashes – en enveis operasjon – og helst med bcrypt, som legger til salt og har en justerbar cost-faktor. Unngå MD5 og SHA-1. HTTPS med TLS/SSL beskytter dataene i transit mot avlytting, manipulering og identitetsforfalskning, og bør brukes overalt der sensitiv data sendes – gjerne med gratis sertifikater fra Certbot.

For å huske innlogging brukes enten session-basert eller token-basert autentisering, der tokens må genereres kryptografisk sikkert med secrets. Og OAuth 2.0 lar brukere logge inn via tredjeparter som Google, slik at din app aldri håndterer passord selv. Sammen utgjør hashing, HTTPS og sikre tokens et komplett autentiseringssystem. I neste kapittel ser vi på personvern, GDPR og dataetikk.