3.6 Autentisering, tilgangskontroll og passord

Å bekrefte at noen er den de utgir seg for å være.

Det skjer ved at brukeren legger fram ett eller flere bevis: et passord, en kode fra telefonen, et fingeravtrykk.

Målet autentisering tjener, er autentisitet — og indirekte konfidensialitet, siden feil person ikke slipper inn.

Den faste feilslutningen: å tro at autentisering gir tilgang. Den svarer bare på spørsmålet hvem. Hva du så får lov til, avgjøres av autorisasjonen, og det er et helt eget spørsmål.

Tilgangskontroll er mekanismen som håndhever avgjørelsen i praksis.

Rekkefølgen er alltid den samme: først autentisering, så autorisasjon. Systemet må vite hvem du er før det kan vite hva du skal få lov til.

Bærende prinsipp: minste privilegium — hver bruker får akkurat de rettighetene oppgaven krever. Da blir skaden mindre både ved feil og ved en overtatt konto.

Den faste feilslutningen: å behandle de to som ett. En sykepleier og en regnskapsfører kan autentiseres på nøyaktig samme måte og likevel ha helt ulike rettigheter.

En tilfeldig verdi som legges til passordet før hashing, og som er unik for hver bruker.

Saltet er ikke hemmelig — det lagres åpent ved siden av hash-verdien. Det er heller ikke poenget at det skal være hemmelig.

De to tingene saltet gjør:

1. Ferdiglagde oppslagstabeller blir ubrukelige. En tabell over hash-verdier for vanlige passord passer ikke lenger, fordi hver bruker har sitt eget salt. Angriperen må regne på nytt for hver enkelt bruker.
2. To like passord får ulik lagret verdi. Uten salt ville to brukere med samme passord hatt identiske hash-verdier i basen — og det avslører både hvem som deler passord, og hvilke passord som er vanlige.

Hva saltet ikke gjør: det gjør ikke et svakt passord sterkt. Har du valgt et passord som står på de tusen vanligste listene, kan en angriper fortsatt prøve seg gjennom dem — bare for én bruker om gangen.

Den faste feilslutningen: å tro at salt er et alternativ til hashing. De to gjør ulike jobber, og begge trengs.

Autorisasjon: «hva får du lov til?» — å tildele rettigheter.

Rekkefølgen er alltid autentisering først: systemet må vite hvem du er før det kan slå opp hva du skal få lov til.

Kontrollspørsmålet ved en hendelse: var det feil person, eller feil rettigheter? Feil person er autentisering; feil rettigheter er autorisasjon.

Mekanismen som håndhever autorisasjonen i praksis: hvem får lese, skrive, slette eller administrere hva.

Det er et tiltak, ikke et mål. Målet den tjener, er først og fremst konfidensialitet, og også integritet — den som ikke får skrive, kan ikke endre.

Bærende prinsipp: minste privilegium. Hver bruker får akkurat de rettighetene oppgaven krever.

De to bevisene må være av ulik type.

Et brukernavn er en identifikator — det sier hvem du påstår å være, ikke at du er det.

I de fleste systemer er brukernavn dessuten offentlig kjent eller lett å gjette: fornavn.etternavn, en e-postadresse, et studentnummer.

Derfor er «brukernavn og passord» enfaktor-autentisering. Bare passordet er et bevis.

1. Lekkede passord. Et passord fra en lekkasje er ikke nok alene.
2. Gjetting og uttømmende søk. Et riktig gjettet passord åpner ingenting.
3. Phishing. Den falske siden fanger passordet, men ikke den fysiske faktoren.

Det ærlige forbeholdet: tofaktor demper phishing, den fjerner den ikke. En angriper som lurer deg til å taste engangskoden i samme øyeblikk, kan bruke den videre. Koder som er bundet til en bestemt nettadresse, er derfor sterkere enn koder du skriver av manuelt.

Den ufravikelige regelen. Et system som kan sende deg passordet ditt, lagrer det i lesbar form — og det er en alvorlig svakhet.

Et riktig bygd system tilbyr tilbakestilling, ikke gjenutsending: du får en lenke som lar deg sette et nytt passord, fordi systemet ikke kan hente fram det gamle.

Dette er den enkleste praktiske testen på om en tjeneste håndterer passord forsvarlig.

REGISTRERING:
  1. lag et tilfeldig SALT, unikt for brukeren
  2. regn ut hash(passord + salt)
  3. lagre SALT og HASH-VERDI

INNLOGGING:
  1. hent brukerens lagrede SALT
  2. regn ut hash(passord + salt) på nytt
  3. sammenlign med den lagrede verdien

Systemet kan altså kontrollere passordet uten noen gang å ha lagret det. Det er enveisegenskapen til hash-funksjonen som gjør dette mulig.

1. Gjør ferdiglagde oppslagstabeller ubrukelige. Angriperen må regne på nytt for hver enkelt bruker, siden hvert salt er ulikt.
2. Skjuler at to brukere har samme passord. Uten salt ville identiske passord gitt identiske verdier i basen.

Saltet er ikke hemmelig — det lagres åpent ved siden av hash-verdien. Poenget er unikhet, ikke hemmelighold.

Og det gjør ikke et svakt passord sterkt: styrken må komme fra passordet selv.

En ferdig utregnet liste over hash-verdier for millioner av vanlige passord.

Uten salt kan en angriper slå opp en stjålet hash-verdi direkte i tabellen og finne passordet på et øyeblikk — og gjøre det for alle brukere samtidig.

Med salt passer tabellen ikke lenger. Angriperen må regne ut verdiene på nytt for hver bruker, og arbeidet vokser med antall brukere i stedet for å være likt for alle.

Har en base med salt og hash-verdier lekket, er ikke passordene lest — men de kan gjettes, én bruker om gangen.

Det som må skje: alle brukere bytter passord. Og de må bytte det i alle andre tjenester der de har gjenbrukt det.

Det som ikke hjelper: å bytte saltene. Saltet var aldri hemmelig, og et nytt salt beskytter ikke et passord som allerede er gjettet.

Dette er hovedgrunnen til at passord ikke skal gjenbrukes: en lekkasje ett sted blir en lekkasje overalt.

Å prøve kandidatpassord til ett gir riktig hash-verdi.

Arbeidsmengden avhenger av passordets lengde og variasjon, ikke av hvor god hash-funksjonen er. Et kort passord av vanlige ord faller uansett; et langt, unikt passord er praktisk umulig å treffe.

Derfor er lengde det viktigste enkeltrådet: hvert ekstra tegn ganger antall muligheter opp, på samme måte som hvert ekstra bit dobler en nøkkels mulighetsrom (kap. 3.3).

Angrep der offeret lures til å oppgi opplysninger selv — typisk via en e-post eller melding som leder til en falsk innloggingsside.

Mål som brytes: autentisitet (siden utgir seg for å være en annen) og konfidensialitet (passordet lekker).

Mottiltakene er todelte: tofaktor, som gjør det stjålne passordet utilstrekkelig, og opplæring, som gjør at folk kjenner igjen mønsteret. Ingen teknisk løsning fjerner behovet for det siste.

Hver bruker og hvert program får akkurat de rettighetene oppgaven krever — ikke flere.

Gevinsten er dobbel: skaden blir mindre både når noen gjør en feil, og når en konto blir overtatt.

En praktisk følge: ingen bør arbeide daglig med en konto som har fulle administratorrettigheter. Klikker den kontoen på noe skadelig, har skadevaren de samme rettighetene.

At rettigheter tildeles roller — sykepleier, saksbehandler, regnskapsfører — i stedet for til hver enkelt person.

Brukeren får rettighetene som følger av rollen, og bytter man jobb, bytter man rolle.

Gevinsten er at rettighetene blir mulige å holde oversikt over. Den vanligste svikten i praksis er at gamle roller ikke fjernes: en ansatt som har byttet oppgaver flere ganger, ender med å ha samlet opp alt.

Rutinen for å fjerne rettigheter når et arbeidsforhold eller oppdrag opphører.

Svikter den, står kontoer aktive lenge etter at de skulle vært stengt — og en slik konto er attraktiv nettopp fordi ingen følger med på den.

Dette er en autorisasjonssvikt, ikke en autentiseringssvikt: personen er den hen utgir seg for, men skulle ikke lenger hatt noen rettigheter.

Bruker du samme passord i flere tjenester, blir én lekkasje til mange innbrudd.

Angriperen som har gjettet passordet ditt fra en lekket base, prøver det samme passordet i e-post, nettbank og sosiale medier — automatisk, og for millioner av brukere samtidig.

Mottiltakene er unike passord per tjeneste (i praksis med en passordbehandler) og tofaktor, som gjør det gjenbrukte passordet utilstrekkelig alene.

Uforutsigbarhet er det nest viktigste. Et passord som står på en liste over vanlige passord, faller uansett hvor komplisert det ser ut.

Unikhet per tjeneste er det tredje: styrken hjelper lite hvis samme passord brukes overalt.

Begrensningen: den kan ikke byttes ut. Lekker en database med fingeravtrykk, kan de berørte ikke få nye fingre.

Derfor lagres biometriske data som regel lokalt på enheten og ikke sentralt, og biometri brukes vanligvis som én faktor sammen med noe du vet — ikke som eneste bevis.

Det er ikke bare brukere som må bekrefte hvem de er. En nettleser må også vite at den snakker med rett tjener.

Den autentiseringen skjer med sertifikat, ikke med passord — se kap. 3.4.

Prinsippet er det samme: en part legger fram et bevis som bare den rette kan ha. For mennesker er det noe du vet, har eller er; for tjenere er det en privat nøkkel bundet til en identitet.