Sikre passord

Brukernavn og passord er ikke lenger en sikker innloggingsmetode. I hvert fall ikke slik det opprinnelig var tenkt. I dag må passord være komplekse og må aldri brukes på nytt. Problemet er at hjernen vår ikke er i stand til å huske et unikt passord for hver eneste nettjeneste vi bruker. Du som leser dette har sikkert mer enn én gang vært i ferd med å logge deg inn på et sted og tenkt «Hva slags passord har jeg her, da...?».

I dag er anbefalingene rundt passordhåndtering like problematiske som anbefalingene innen kosthold og ernæring. Det er et utallig antall forskjellige anbefalinger for hva vi bør spise, og flere av dem motsier hverandre. På samme måte er det så mange passordanbefalinger at det ikke er mulig å følge dem alle.

Her presenterer jeg (undertegnede sjefredaktør) min anbefaling. Ettersom jeg hevder at flere andre passordanbefalinger er feil, har jeg viet flere sider til å forklare matematikken bak det hele. Det er ikke bare for å gi enda en passordanbefaling, men i stedet ønsker jeg å presentere en helhetlig løsning samt vise hvordan alt henger sammen. Hvis du ikke er interessert i teknologien bak det hele, kan du hoppe rett til sammendraget på slutten av dette kapittelet.

Et sikkert passord er et passord som ingen kan gjette, og et passord en hacking-datamaskin ikke kan teste seg frem til. Kravet om at ingen kan gjette passordet, vil si at navnet på venner, barn, foreldre og kjæledyr ikke er egnet. Det samme gjelder de samme navnene etterfulgt av et tall (f.eks. Maria1). Navn er noe som både omgivelsene kan gjette seg til og som en hacking-datamaskin kan teste seg frem til.

Alle "klassiske" passord er selvfølgelig også uegnet. Fordi det historisk sett har vært et stort antall passordlekkasjer, har hackere fått god oversikt over hvilke passord mange brukere velger. Når de ønsker å få tilgang til en konto, starter de derfor med å teste de klassiske passordene. Eksempler på slike er:

• 123456 (noen ganger 12345678)
• password (noen ganger password1)
• qwerty (de første bokstavene på tastaturet)
• abc123
• 00000000 eller 11111111
• monkey
• admin
• iloveyou
• (et sensurert kjønnsord)

Passordet ovenfor og lignende passord bør derfor absolutt unngås. Det samme gjelder ord som finnes i ordbøker. Etter å ha testet de klassiske passordene, utfører hackerne nemlig det som kalles et ordbokangrep. Et ordbokangrep er (akkurat som det høres ut som) et forsøk på å få tilgang til en konto ved å teste alle passordene i en ordbok. Den 13. utgaven av Svenska Akademiens ordbok inneholder 125 000 ord, det er få ord i denne sammenhengen. Det vil si at det er relativt raskt å hacke en konto hvis passordet er et av ordene i ordboken (eller et av ordene etterfulgt av tallet 1, f.eks. skrivefeil1).

Selvfølgelig er hackere ikke fornøyd med å teste ord som finnes i Saol. Hele internett er et fantastisk leksikon for å finne alle de rare slangordene og faguttrykkene som brukes. Det betyr at et passord per definisjon er usikkert. Det er bedre å bruke en passordsetning.

En passordsetning eller passordfrase (fra engelsk passwordfrase) er en kombinasjon av ord som brukes i stedet for et passord. Et eksempel på en passordsetning er:

OskarSpiserLunsj

eller

oskarspiserlunsj

Dessverre er passordsetning ikke helt sikre, selv om de er sikrere enn et passord! Ved først å pløye internett etter vanlige setninger og fraser, kan hackere deretter teste de mest brukte ordkombinasjonene. Det krever betydelig datamaskinkapasitet og tar betydelig lenger tid, men passordsetningenes sikkerhet reduseres etter hvert som ytelsen til datamaskinene øker. 

Den tradisjonelle anbefalingen i passordsammenheng er å blande store og små bokstaver, tall og spesialtegn. Et eksempel på et slikt passord er:

kR&34Ca9

Problemet med et slikt passord er at det er vanskelig å huske. Hvis hver eneste nettjeneste skal få et såpass unikt passord, blir det fort uhåndterlig. Et slikt passord er også vanskelig å skrive inn på et mobil- eller nettbrettastatur.

Det verste med denne tradisjonelle passordanbefalingen er at den er direkte kontraproduktiv. Det får brukerne til å velge korte passord! Kravet om å blande bokstaver og tall har til og med vist seg å få brukere til å bruke passord som er enkle å knekke, som f.eks. abc123!

Den stadig gjentatte oppfordringen om å blande store og små bokstaver, tall og spesialtegn har fått mange til å tro at passordet kR&34Ca9 ville være sikrere enn et tullete passord som MummitrollFerskFiskFotograferer. Det er ikke tilfelle.

Et brute-force-attack betyr at en hacking-datamaskin prøver alle mulige kombinasjoner av tegn for til slutt å finne det riktige passordet. Den kan for eksempel starte med å teste kombinasjonen aaaaaaaa. Hvis det ikke var riktig passord, prøver den aaaaaaab etterfulgt av aaaaaaac og så videre til den har kommet frem til riktig passord. Det tar enormt lang tid å teste riktig passord på denne måten. Men ettersom verken kR&34Ca9 eller MumintrollFotarGatlykta finnes i en ordbok (eller vises som en ofte brukt setning), er et brute-force attack den eneste metoden for å finne passordet.

Lengden på passordet er i praksis den mest avgjørende faktoren for hvor lang tid det tar hackerens datamaskin å finne det riktige passordet. Dette fremgår av følgende eksempel:

Hvert enkelt tegn i et passord som kR&34Ca9 kan være ett av omtrent 78 mulige tegn, da det teoretisk sett blandes opptil:

• 29 store bokstaver (A-Å)
• 29 små bokstaver (a-å)
• 10 sifre (0-9)
• Omtrent 10 vanlige spesialtegn (!# % & / @ * = ? - ) # % & / @ * = ? - )

Det vil si at hvis passordet bare hadde vært ett tegn langt, ville det tatt 78 (781) forsøk på å finne riktig passord. Med to tegn øker antallet mulige kombinasjoner til 6 084 (782). Med tre tegn øker antallet mulige kombinasjoner til 474 552 (783) og så videre. Vi kaller dette passordmodell A.

Hvert enkelt tegn i et passord som MumintrollFotarGatlykta kan bare være ett av 58 tegn. Dette er fordi det bare kan tenkes å inneholde:

• 29 store bokstaver (A-Å)
• 29 små bokstaver (a-å)

Det i seg selv er noe hackeren ikke kan vite, men det er av underordnet betydning.

Det vil si at hvis passordet bare hadde vært ett tegn langt, ville det tatt 58 (581) forsøk på å finne riktig passord. Med to tegn øker antallet mulige kombinasjoner til 3 364 (582). Med tre tegn øker antallet mulige kombinasjoner til 195 112 (583) og så videre. Vi kaller dette passordmodell B.

Antall mulige kombinasjoner av et passord på åtte tegn i henhold til passordmodell A (78 alternativer per tegn) er 788:

1 370 114 370 683 140

Antall kombinasjoner tilgjengelig for et passord på åtte tegn i henhold til passordmodell B (58 alternativer per tegn) er færre (588):

128 063 081 718 016

Så langt ser det ut som passordmodell A er sikrere. Å øke passordet som følger passordmodell B med ett enkelt tegn øker imidlertid antall mulige kombinasjoner til:

7 427 658 739 644 930

Et ni tegn langt og lett å huske passord, i henhold til passordmodell B, har over fem ganger flere mulige kombinasjoner enn et åtte tegn langt, og vanskelig å huske, passord, i henhold til passordmodell A. Her følger en tabell som viser antall mulige kombinasjoner som passordmodell B har for et visst antall tegn, sammenlignet med et passord på åtte tegn, i henhold til passordmodell A.

Dette betyr at en hacking-datamaskin har tid til å prøve alle kombinasjoner av et åtte-tegns passord som kR&34Ca9 ganske mange ganger, før den rekker å gå gjennom alle kombinasjoner av et 23-tegns passord som MumintrollFotarGatlykta én gang (mer presist, over 26 tusen trillioner ganger).

Et langt passord med et litt mindre antall tegnsett blir fort sikrere enn et kort passord med et litt større antall tegnsett.

Mange tenker nok på om det ikke ville vært enda tryggere å også legge til spesialtegn. I teorien blir det det, så lenge det ikke fører til at passordet gjøres kortere (noe det er stor fare for). Det er også unødvendig i praksis, som vist av følgende eksempel.

Anta at det tar en datamaskin ett minutt å teste alle kombinasjonene som finnes, for et passord på åtte tegn, med et tegnsett på 58 tegn (som forøvrig er betydelig raskere enn det som er mulig i dag). Hvis passordet er valgt helt tilfeldig, vil datamaskinen finne det etter gjennomsnittlig et halvt minutt. Ved å øke antall tegn til ni, øker antall kombinasjoner 58 ganger. Det tar dermed 58 ganger så lang tid (58 minutter) å teste alle mulige kombinasjoner. Gjennomsnittet havner dermed på 29 minutter. Hvis du legger til et tegn til, øker antall kombinasjoner 58 ganger igjen. Det tar derfor 58 ganger så lang tid å teste alle mulige kombinasjoner, det tilsvarer litt over to døgn. Gjennomsnittlig tid er litt over ett døgn

Her er en oversikt over hvordan tiden det tar å finne riktig passord øker i takt med passordlengden.

* 1 minutt er satt som en hypotetisk startverdi. Det tar egentlig mye lenger tid.

Fordi det knapt spiller noen rolle om det tar hundre tusen årtusener eller to hundre tusen årtusener å finne et passord, er behovet for spesialtegn ganske lite. Det er viktigere å ha et langt passord!

Obs! I disse regneeksemplene er passordmodellene forenklet i den grad at passordlengden alltid er kjent (noe den ikke er). Anbefalingen forutsetter også at det brukes et tullete passord (totalt vrøvl).

Passordledetråder er en plage, som gjør våre ellers sikre passord (dvs. tullete passord) usikre. Tanken bak er at passordledetrådene vil hjelpe oss med å finne passordene våre, hvis vi har glemt dem. Problemet er at passordledetrådene misbrukes altfor ofte. Hvis passordet er "sitter rundt bananen", kan hvem som helst finne ut at passordet er "bananskall".

Det samme problemet eksisterer med nettjenester som ber brukerne om å velge samt svare på et sett med spørsmål om tilbakestilling av passord når de registrerer seg:

• Hva het den første skolen du gikk på?
• Hva var din mors pikenavn?
• Hva het ditt første kjæledyr?

Problemet er at disse spørsmålene er altfor enkle å svare på. Min første skole het Anneroskolan. Min mor het Maja. Mitt første kjæledyr var Kissemisse. Dette er svar som alle som kjenner meg kan finne ut. Ikke minst, vet alle i familien min svarene på dem!

Passordhint og hintspørsmål bør aldri brukes. I prinsippet gir alle nettjenester muligheten til å sende et nytt passord til den registrerte e-postadressen. Det er en betydelig tryggere måte å få tilgang til en tjeneste på, hvis du har glemt passordet. Hvis du ikke kan velge bort passordhint eller å svare på hintspørsmål under registreringen, bør hintet eller svarene være et annet tullete passord som aldri brukes. Legg for eksempel tullete svar til i passordbehandlingen, som vu dekker ved slutten av dette kapittelet.

Flere ganger i året er det en eller annen stor nettjeneste som har en passordlekkasje. Det er hovedgrunnen til at passord aldri bør gjenbrukes. Hvis det samme passordet brukes på fem nettjenester og en av nettjenestene lekker passordet, vil hackere også kunne logge seg inn på de fire andre tjenestene der samme passord- og brukernavnkombinasjon brukes (inkludert tjenester som lagrer kredittkortinformasjon).

En annen grunn til å aldri gjenbruke passord er at ikke alle nettjenester sender innloggingsdataene kryptert. Med en ukryptert innlogging kan noen på det samme åpne trådløse nettverket fange opp passordet og deretter prøve å bruke det på andre tjenester.

Nøyaktig hvor sikkert et passord må være, avhenger av hvilken tjeneste det skal beskytte. Passordet som beskytter en sjelden brukt forumkonto trenger ikke å være like sikkert som passordet som beskytter e-postkontoen din. Noen tjenester trenger ikke engang komplekse passord (dvs. uten passord), fordi de ikke beskytter noe viktig.

Hvor sikkert et passord skal være, avhenger av hvor tjenesten er i sikkerhetshierarkiet. Hierarkiet er ikke en eksisterende liste, men bestemmes av hvordan hver enkelt bruker velger å koble til de ulike tjenestene.

Øverst i hierarkiet er brukerens primære e-postkonto. E-posttjenesten er alltid den tjenesten som må beskyttes mest (gjerne med totrinnsverifisering, vi dekker dette mer detaljert senere i dette kapittelet). Det er fordi stort sett alle nettjenester har en funksjon for å tilbakestille brukerens passord og sende et nytt til hans eller hennes e-postadresse. En lyssky person som får tilgang til en brukers e-postkonto, har dermed også tilgang til alle andre nettjenester (nettbutikker, appbutikker, forum, sosiale nettverk osv.).

En hacket e-postkonto åpner alle andre kontoer på grunn av hvordan tjenestene er sammenkoblet.

 

Obs! Fortsett aldri med å bruke et passord som er sendt til e-postkontoen din, i forbindelse med en nyregistrering eller tilbakestilling av et passord. E-poster sendes ukryptert og i klartekst, det innebærer at noen kan ha snappet opp passordet på veien. Logg deg inn med passordet som kom i e-posten og bytt til et nytt passord (et tullete passord).

Nest øverst i hierarkiet er nettjenester som kan påvirke andre nettjenester. Disse inkluderer fremfor alt Facebook, Twitter og Google Plus (hvis Gmail brukes som primær e-posttjeneste, tilhører Google Plus toppen av hierarkiet). Det er fordi disse tjenestene kan i sin tur brukes til å logge seg inn på andre tjenester. Du kan for eksempel logge deg inn på treningstjenestene Runkeeper, Fitbit og Sats med Facebook- eller Google Plus-kontoen din.

Bruk sikre passord (tullete passord) for tjenester som igjen kan logge deg inn på andre tjenester.

Nederst i hierarkiet er tjenester som ikke senere kan brukes til å få tilgang til andre tjenester. Eksempler på slike er forumkontoer og de nevnte treningstjenestene.

Du trenger bare å tenke over to punkter for å velge hvor sikkert passord du må ha til en bestemt tjeneste:

• Hvor høyt i sikkerhetshierarkiet er denne tjenesten? Vil den kunne brukes til å logge seg inn på en annen tjeneste? Jo høyere opp i hierarkiet tjenesten er, jo sikrere passord må brukes.
• Hvor sensitive er dataen som skal lagres på tjenesten? Vil det lagre kredittkortopplysninger?

Tjenester som er høyt oppe i hierarkiet bør, om mulig, beskyttes med totrinnskontroll. Det er en teknologi som gjør at det ikke er nok med ett passord for å logge seg inn, men det kreves to faktorer: dels et passord og dels noe annet. Den andre faktoren er vanligvis en tidsbasert kode generert av en app som er installert på brukerens mobiltelefon. Den gjeldende kodegeneratorappen er knyttet til kontoen, slik at ingen annen app eller mobiltelefon kan generere riktig kode.

Innlogging uten totrinnskontroll (kun passord kreves).

  Innlogging med totrinnskontroll (passord og mobiltelefon kreves).

Google og Microsoft følger de facto bransjestandarden for totrinnskontroll. Dette gjør at den samme appen kan brukes til totrinnskontroll av både Google- og Microsoft-kontoer. Undertegnede sjefredaktør anbefaler følgende apper for hvert operativsystem:

• Android: Google Authenticator (utviklet av Google og tilgjengelig i Google Play)
• IOS: Google Authenticator (utviklet av Google og tilgjengelig i App Store)
• Windows Phone: Microsoft Authenticator (utviklet av Microsoft og tilgjengelig i Windows Phone Store).

I følge Googles beskrivelse kan ikke Microsoft Authenticator brukes til totrinnskontroll av Google-kontoer, men det fungerer faktisk fint (testet i august 2014). Denne industristandardløsningen brukes også blant annet av Lastpass (passordbehandlingen som dekkes senere i dette kapittelet), Synology DSM (NAS-operativsystemet i Network 16) og Facebook.

Apple har valgt å bruke sin egen løsning for å tilby utvidet beskyttelse. Løsningen deres er avhengig av Find My Iphone-appen, som finnes kun for iOS. Dessverre har Apple så langt valgt å kun aktivere beskyttelse med totrinnskontroll av instillingssidene for Apple ID samt kjøp i iTunes, App store og Ibooks store. Beskyttelse med totrinnskontroll dekker ikke sensitive tjenester som f.eks. iClouds e-posttjeneste. Twitter har også valgt en egen løsning for totrinnskontroll.

Google og Microsoft er to av selskapene som tilbyr totrinnskontroll i henhold til bransjestandarden. Hvis en bruker velger å beskytte Google- eller Microsoft-kontoene sine med totrinnskontroll, må brukeren både vite passordet sitt og ha tilgang til mobiltelefonen sin, for å logge seg inn på e-postkontoen sin (Gmail og Outlook), innstillingssidene og alle andre tjenester som bruker kontoen (f.eks. Google Plus, Google Drive, Microsoft Onedrive, Microsoft Office og Skype).

Det første trinnet ved innlogging med totrinnskontroll er å oppgi brukernavn og passord, som vanlig.

Når riktig passord er angitt, ber tjenesten om en sekssifret kode.

Den sekssifrede koden genereres av appen i brukerens mobiltelefon og er kun gyldig i et visst antall sekunder.

Ved å taste inn den sekssifrede koden slippes brukeren inn. Hvis innloggingen foregår på en datamaskin som brukes ofte, kan brukeren be Google eller Microsoft om ikke å be om totrinnskontroll på den aktuelle datamaskinen flere ganger. Google og Microsoft vil imidlertid fortsette å kreve kode for totrinnskontroll når de logger seg inn på andre datamaskiner og i andre nettlesere, på samme datamaskin. I Authenticator-appen vises en sirkel ved siden av hver innloggingskode som blir mindre og mindre (innringet i oransje på bildet ovenfor). Når tiden er ute, genereres en ny tilfeldig sekssifret kode og sirkelen fylles ut igjen.

Totrinnskontroll er for øyeblikket deaktivert som standard. Det kreves at hver bruker velger å aktivere funksjonen manuelt, det gjøres på samme sted som der du endrer passord. Her følger et eksempel på hvordan det gjøres. I eksemplet er Gmail og Outlook dekket, fordi begge disse tjenestene følger bransjestandarden. De er også to tjenester som er øverst i sikkerhetshierarkiet, og derfor har størst behov for totrinnskontroll.

For Gmail (Google-konto) åpner vi datamaskinens nettleser og går til www.google.com/settings/security.

For Outlook (Microsoft-konto) åpner vi datamaskinens nettleser og går til account.live.com/proofs/Manage.

Det første trinnet er å koble mobiltelefonen vår til kontoen, via mobilnummeret (hvis det ikke allerede er gjort). Dette gjør vi for at verifiseringskodene skal kunne leveres som SMS.

SMS er både en upraktisk og treg måte å motta kodene på. Det er mye enklere å bruke en av verifiseringsappene som nevnt tidligere i dette kapittelet.

Det er likevel greit å ha SMS-funksjonen som backup, i tilfelle det skulle oppstå problemer med appen.

Både Google og Microsoft bruker QR-koder for å koble verifiseringsappen til kontoen. Vi åpner derfor appen, legger til en ny konto og skanner QR-koden som nettjenesten viser på dataskjermen.

Konfigurasjonen for Google (til venstre) og Microsoft (til høyre).

Da er den grunnleggende konfigurasjonen fullført! Nå kan appen generere de nødvendige kodene. Den samme appen kan brukes til å generere koder for flere tjenester.

For å redusere risikoen for å bli utestengt fra kontoen vår, utfører vi to ekstra trinn. Når det gjelder Microsoft, kobler vi Microsoft-kontoen vår til en alternativ e-postadresse. Da kan Microsoft sende verifiseringskoder til denne e-postadressen hvis vi mister både appen og mobilnummeret. Vi utfører innstillingen fra samme side som vi aktiverte totrinnskontrollen på.

Når det gjelder Google, bruker vi funksjonen til å generere ti langsiktige verifiseringskoder. Ved å skrive dem ut og ha dem i lommeboken, har vi alltid en alternativ måte å motta en verifiseringskode på (i tilfelle vi mister mobiltelefonen vår). Vær oppmerksom på at hver langtidsgyldige kode kun kan brukes én gang. Vi genererer langtidsgyldige koder fra samme side som vi aktiverte totrinnskontrollen på.

Dessverre er det ikke alle programmer og apper som støtter totrinnskontroll. Heldigvis kan det problemet løses ved å generere program- og app-passord. Det er permanente passord som genereres for hvert enkelt program og individuell app, som skal knyttes til kontoen. Den passer for blant annet e-postklienter og kalenderapper som mangler støtte for totrinnskontroll.

Program- og app-passordene genereres fra de samme innstillingssidene som ble brukt for å aktivere totrinnskontroll. Derfra kan brukeren også velge å tilbakestille gyldighetstiden til et spesifikt program- eller app-passord, og dermed forhindre at det aktuelle programmet eller appen får tilgang til kontoen.

Selv om et passord, i form av et tullete passord, kan være relativt enkelt å huske, er det vanskelig å huske et unikt passord for hver enkelt tjeneste. I stedet for å gjøre passord korte eller gjenbruke dem, bør du bruke en passordbehandler.

En passordbehandler genererer et unikt og sterkt passord (dvs. et tullete passord) for hver enkelt tjeneste som brukeren oppretter en konto på. Brukeren trenger aldri å huske disse tjenestespesifikke passordene, fordi passordbehandleren gjør det for dem. Det eneste passordet brukeren trenger å huske er det passordbehandleren krever for å låse opp alle andre kontoer (for eksempel en Twitter-konto eller forumkonto). Dette betyr at alle tjenester kan beskyttes med lange passord som er vanskelige å knekke (som i gjennomsnitt tar minst et par årtusener å teste seg frem til) og brukeren trenger aldri å huske eller oppgi mer enn ett! Brukeren i tillegg regelmessig endre passord for tjenester som krever det, uten å måtte huske et nytt et. En passordbehandler løser ganske enkelt passordproblemet.

Det finnes en håndfull populære passordbehandlere. Undertegnede sjefredaktør anbefaler Lastpass (www.lastpass.com). Det er en betalt tjeneste som i skrivende stund koster tolv dollar i året, men jeg synes det er betryggende at selskapet som transporterer det krypterte passordarkivet mitt, har en tydelig finansieringsmodell.

Med Lastpass legges alle passord inn i et kryptert hvelv. Det krypterte hvelvet synkroniseres via Lastpass-servere til alle enheter som eies av brukeren. Lastpass er tilgjengelig for Windows, Windows RT, macOS, Android, IOS og Windows Phone (for å nevne operativsystemene vi dekker i denne boken). Enhetene beholder hver sin frakoblet kopi av det krypterte hvelvet, slik at passordene er tilgjengelige, selv uten internettforbindelse.

Lastpass synkroniserer det krypterte passordhvelvet til alle brukerens enheter.

 

Når en mobiltelefonbruker vil logge seg inn på en app, trenger de bare å åpne Lastpass-appen, skrive inn hovedpassordet, kopiere det nødvendige app-passordet og lime det inn i appen som ber om det.

Hvis mobiltelefonen kjører Android, er det til og med enda enklere. Takket være strukturen til Android-systemet kan Lastpass-appen ta over innloggingen. Så snart brukeren åpner en app som ber om legitimasjon, vises en Lastpass-knapp. Hvis brukeren klikker på den og skriver inn hovedpassordet, fyller Lastpass inn brukernavn og passord automatisk.

 

Hvis du husker passordet for Lastpass, husker Lastpass passordet for alt annet.

Lastpass fungerer like enkelt i nettleseren på datamaskiner. Lastpass har utviklet plugin for Chrome, Firefox, Internet Explorer og Safari (for å nevne nettleserne som dekkes i denne boken). Plugin-en gjør at så snart brukeren skal logge seg inn på et nettsted, kan de bare trykke på Lastpass-knappen, skrive inn hovedpassordet og la Lastpass fylle ut all informasjon som nettstedet ber om.

Lastpass har også en innebygd funksjon for å opprette sikre passord (dvs. "tullete passord"). Lastpass har en pseudo-tilfeldig generator som velger tilfeldige tegnkombinasjoner. Du kan velge hvilke tegn som er tillatt og om passordet skal være mulig å uttale eller ikke. Ved å gjøre det mulig å uttale, er det enkelt å skrive det ned og når du kun bruker bokstaver, blir det også enkelt å skrive det inn på skjermtastaturene til mobiltelefoner og nettbrett, om nødvendig.

Passordadministratorer havner automatisk øverst i sikkerhetshierarkiet, som ble diskutert tidligere i dette kapittelet. Det er derfor en god idé å beskytte passordbehandleren med totrinnskontroll. Dette støttes av Lastpass og de følger bransjens de facto-standard. Dette betyr at den samme kodegeneratorappen som brukes for Gmail og Outlook, også kan brukes for Lastpass.

Obs! Brukere som aktiverer totrinnskontroll på Lastpass-kontoen sin, bør også ha passordet for e-postkontoen tilgjengelig på en alternativ måte. Dette er fordi Lastpass kan sende en gjenopprettingskode til e-postkontoen din, hvis mobiltelefonen som brukes til totrinnskontroll går tapt. Uten mobiltelefon risikerer brukeren ellers å havne i en catch 22 (de trenger Lastpass for å kunne logge seg inn på e-postkontoen og e-postkontoen for å logge seg inn på Lastpass).

I tillegg til Lastpass finnes det flere andre passordbehandlere. Her er eksempler på noen som er populære. Vær oppmerksom på at jeg ikke har sett nærmere på sikkerheten til disse. Fremfor alt vil jeg advare om sikkerhetsfaren ved å bruke uoffisielle Keepass-klienter og -utvidelser (dvs. alt annet enn den offisielle Keepass Windows-klienten). At det er åpen kildekode er ikke i seg selv en garanti for verken god sikkerhet eller fravær av bakdører.

Bitwarden (gratis og betalte alternativer)
www.bitwarden.com

Passordbehandlere som synkroniserer mellom ulike enheter, er basert på åpen kildekode, bruker en «zero knowledge»-policy, det betyr at de heller ikke har tilgang til passordene dine.

1passord (betalingsalternativ)
agilebits.com/onepassword

Passordbehandling populær blant macOS- og iOS-brukere. Nå også tilgjengelig for Windows og Android.

iCloud nøkkelring (inkludert)
Apples egen passordbehandling for macOS og iOS. Fungerer ikke utenfor Apple-systemet.

Keepass (gratis alternativ)
keepass.info

Gratis passordbehandling basert på åpen kildekode. Synkroniserer ikke passord mellom enhetene selv, men arkivet kan legges i en passende skytjeneste. Kun offisiell støtte for Windows. Det finnes uoffisielle klienter for andre operativsystemer.

F-secure Key (betalingsalternativ)
www.f-secure.com/key

Passordbehandling som synkroniserer passord mellom Windows, macOS, Android og iOS.

Dette avsnittet er en kort oppsummering av kapittelet. Les hele kapittelet for å få forklaringen til anbefalingene.

• Ikke bruk passord som finnes i ordbøker, ofte brukte passord, eller passord som folk rundt deg enkelt kan gjette seg frem til.
• Bruk heller et langt passord uten tall og spesialtegn, enn et kort passord med tall og spesialtegn.
• Bruk aller helst "tullete passord", de er både lette å huske og vanskelige å knekke.
• Unngå å bruke passordhint og hintspørsmål.
• Gjenbruk aldri passord.
• La e-postkontoen din ha det sikreste passordet!
• Aktiver, om mulig, totrinnskontroll for de mest kritiske tjenestene (inkludert e-posttjenesten).
• Bruk passordbehandling.