Password Fail

Her er ditt passord

Nylig gikk jeg gjennom nærmere 150 nettsider og byttet passord på kontoene mine. Listen over netsidene har jeg i «safen». Som mange andre bruker jeg et eget verktøy for å holde rede på passordene. Jeg benytter LastPass, men det finnes mange tilsvarende med eller uten krav til nett. Det sikreste er selvsagt en lokal safe, slik at man unngår mye av problematikken forbundet med en online løsning, men det handler også om brukervennlighet og tilgang. Derfor har jeg sterke, unike passord på samtlige sider jeg benytter, og kanskje det sterkeste av dem alle er for «safen» selv.

De flest passord er basert på et system som jeg selv har kommet på. Ettersom det følger et system er det selvsagt mulig å finne et mønster, men med mindre et program er skrevet for nettopp dette anser jeg de som svært usannsynlig at noen tar seg bryet. Litt samme logikk som at innbruddstyver heller går inn i villaene noen hundre meter unne leiligheten min. Det er enklere.

Etterhvert som jeg gikk gjennom listen av nettsider oppdaget jeg at svært mange har dårlige rutiner rundt sikkerheten, enten de oppbevarte passordene uforsvarlig (kanskje i klartekst) eller hadde regler som begrenset hvor gode passordene kan være. Mange sendte en epost med bekreftelse på endret passord, hvor passordet var lagt ved i eposten i klartekst. Slik som også noen nettsider gjerne gjør ved registrering. Det er flere grunner til at dette er en dårlig idé:

  • Eposten blir lagret i flere systemer = passordet er lagret i flere systemer. I klartekst.
  • Brukeren trenger som oftest ikke bli påminnet sitt eget passord. Han/hun har tastet det inn selv, og ingen andre trenger vite om det.
  • Selv etter at eposten er slettet vil høyst sannsynlig flere kopier eksistere i andre systemer.
  • Sikkerheten kan være brutt allerede før brukeren har lest eposten.

For å nevne noen.

Det er ingen grunn til å sende passord i eposten.

Når brukeren velger sitt passord ved registrering har vedkommende sannsynligvis god kontroll over hva dette passordet er. Det er typisk tastet inn i to felt, hvor det også gjøres en sjekk om de er like. Hvordan passord håndteres etter dette er litt forskjellig, men ofte blir det håndtert på en dårlig måte.

Om passordet sendes tilbake til den nye brukeren på epost er sikkerheten allerede svekket. Det er utenfor kontroll, og man kan ikke lenger garantere at kun brukeren vet hva passordet er. Det vil ligge kopier av eposten med passordet i flere systemer, i tillegg til at det kan være snust opp på nettverket. Og avsender har ingen kontroll over hvem som har tilgang til mottakers epost.

Skulle brukeren glemme sitt passord bør det være en smal sak å ha en mekanisme for å sette et nytt passord. En vanlig måte å løse dette på er å enten sende brukeren et nytt og midlertidig passord (gjerne med tvang om nytt passord etter innlogging) eller ved å sende en lenke til inntasting av nytt passord (som selvsagt kun er gyldig en viss tid).

Passordet skal ikke lagres!

I løpet av de siste årene har det vært mange saker i media rundt kontoer på avveie. Felles for de fleste av disse har vært dårlig sikkerhet i systemene som har håndtert kontoinformasjon. En gjenganger har vært passord lagret i en database, som noen har fått tilgang til.

De som ikke kjenner til mulighetene lurer gjerne på hvordan man kan bekrefte et passord uten å lagre det. En løsning er å lagre en hash av passordet. En hash er veldig forenklet et resultat av en hashfunksjon med passord som input. Det skal ikke være enkelt å finne ut hva input var, helst umulig. Altså en enveis funksjon.

Tidligere anså man med hash problemet som løst. Et passord ble kjørt gjennom en funksjon som ga en hash som resultat. Denne hashen ble så lagret i en database, sammen med brukernavn og eventuelle andre data om brukeren. Ved innlogging tar man så passordet brukeren taster gjennom samme funksjon og sammenligner resultatet med det som er lagret for brukeren. Er de like vet man så at brukeren har tastet riktig. Og kun brukeren vet passordet. Eller?

Problemet med denne løsningen, som fortsatt brukes i stor grad, er at samme funksjon brukes i mange systemer og samme passord gir alltid samme resultat. Dermed kan man gjøre en del ting for å finne ut hva passordet egentlig er. Med brute-force kan man lage en såkalt rainbow-tabell, en tabell som inneholder hasher for de fleste kombinasjoner et passord kan bestå av. Dermed kan man slå opp en hash i denne tabellen for å finne riktig passord. Selv uten en slik tabell kan man med dagens hardware finne et passord lagret med en svak hashfunksjon relativt raskt.

Selvsagt har noen tenkt ut noen smarte løsninger for dette. En mer komplisert hashfunksjon kan benyttes sammen et såkalt salt. Et salt er kort og godt tilfeldig data. Saltet lagres sammen med hashen (beregnet av hashfunksjonen med passord og saltet som input), men uten passordet. Ved innlogging benyttes samme salt til å beregne en hash sammen det inntastede passord, for deretter å kontrollere om de to hashene er like. Ettersom saltet er tilfeldig for hver bruker blir det også utrolig mye vanskeligere å finne frem til riktig passord med brute-force. En rainbow-tabell må dermed bestå av samtlige kombinasjoner for både hash og salt, som i praksis vil kreve fantastisk mye tid.

De fleste gode rammeverk har innebygd funksjonalitet for dette, eller tilbyr det ved tredjeparts løsninger.

Svakeste ledd

Som nevnt trenger skal ikke systemene lagre passordet. Dermed er også de fleste regler som nettsider har lagt på passordene lite nyttige. De tjener ikke til annet enn å gjøre sikkerheten svakere. Eksempel er maks lengde på passord. Ettersom en hash typisk har en fast lengde, uavhengig av passord, ser jeg liten grunn til å legge slike restriksjoner på brukeren. Det samme gjelder også bruken av tegn i passord, enten det er krav for eller mot visse tegn. Noen nettsider krever alle tegn er enten gyldige bokstaver eller tegn, og har dermed effektivt begrenset antall mulige kombinasjoner betraktelig. Er det krav om visse tegn (f.eks et punktum) er heller ikke dette heldig, siden man da oppgir hvilke tegn som må være inkludert, en joker mindre å finne ut av for den med uærlige hensikter.

I tillegg er det slik at de fleste velger et passord de kan huske. I dag har gjerne de fleste brukere mange kontoer, passord og pinkoder de skal huske på. For å gjøre dette enklere velger de gjerne noe som er lett å huske. F.eks «Bamse1″. Når passordet skal byttes? «Bamse2″. Ved å ha strenge regler for hvordan passord skal bygges opp velger mange minste motstands vei, og finner på et passord som er veldig lett å huske, men også veldig lett å finne ut av. Spesielt kravet om at passord må endres med jevne mellomrom legger opp til denne praksisen.

Sikkerhet er et race mellom flere parter. Mens sikkerheten stadig blir bedre, oppdages det også hele tiden smartere metoder for å komme rundt sikkerheten. Som oftest er brukeren selv det svakeste leddet, men noen ganger klarer nettstedet selv å gjøre seg svakere. Når det er så lett å heve sikkerheten, og vi stadig ser kontoinformasjon på avveie, finnes det ingen unnskyldning for ikke ta grep for sine egne nettsider. Og kommer du over en nettside som åpenbart har dårlig sikkerhet kan det lønne seg å si ifra om dette. Ikke bare for din egen del, men også for andre.

Benytter du samme passord flere steder er du spesielt utsatt. Men det gjør du vel ikke?

2 tanker om “Her er ditt passord

  1. Geir

    Woooops! Her er du inne på et betent område. Jeg bruker selv 1password for å holde skikk på passordene mine, men skulle gjerne hatt en løsning som gjorde det enkelt å få oversikt over alle passord og å endre de. Å gå gjennom 150 sider vil jo ta et halvt år med min hastighet, så det blir liksom aldri til at jeg gidder ta meg bryet. Jeg prøver å skifte passord hvert år, men kjører stort sett det samme passordet over hele fjøla. Jeg tror jeg får begynne å teste ut den løsningen du har.

    Svar
    1. Yngve Thoresen Innleggsforfatter

      Å ha oversikt over alle passordene er greit nok. Lastpass har en innebygd «security check», som blant annet lister opp sider med like passord og gir en indikasjon på hvor godt passord er for hver enkelt tjeneste. Jobben med å endre passord er fortsatt manuell og tar litt tid. Jeg tok dette fortløpende over noen dager. For å dobbeltsjekke kjører jeg bare testen på ny og finner fort ut om det er noen spesielle svakheter.

      Noen svakheter ignorer jeg også, om jeg anser det som godt nok. Det viktigste er at et passord på avveie ikke skal føre til at andre tjenester kan misbrukes. Ett passord over fjøla betyr i praksis at du må bytte passord på samtlige tjenester om du mistenker at passord er på avveie. Med unike passord per tjeneste er ikke dette et problem. Dessverre går ikke alltid brukervennlighet og sikkerhet hånd i hånd.

      Svar

Legg inn en kommentar