Säkra lösenord

Säkra lösenord

Användarnamn och lösenord fungerar inte längre som en säker inloggningsmetod. I alla fall inte på sättet som det var tänkt från början. Idag måste lösenorden vara komplexa och de får aldrig återanvändas. Problemet är att våra hjärnor inte är kapabla att komma ihåg ett unikt lösenord för varenda webbtjänst vi använder.

Idag lider rekommendationer kring lösenordshantering av samma problematik som ­rekommendationer inom kost- och näringslära. Det finns så många olika rekommendationer för vad vi ska äta att flera av dem säger emot varandra. Likaså finns det så många lösenordsrekommendationer att det är omöjligt att följa samtliga.

I denna bok lägger jag (undertecknad chefredaktör) fram min rekommendation. Eftersom den hävdar att flera andra lösenordsrekommendationer är felaktiga har jag vigt ett flertal sidor åt att förklara matematiken bakom det hela. Detta för att inte bara ge ytterligare en lösenordsrekommendation, utan istället presentera en helhetslösning och visa hur allt hänger samman. Om du inte är intresserad av tekniken bakom det hela kan du hoppa direkt till summeringen i slutet av detta kapitel.

Ett lösenord är inte säkert

Ett säkert lösenord är ett lösenord som ingen kan gissa och en hackande dator inte kan testa sig fram till. Kravet på att ingen ska kunna gissa lösenordet leder till att namn på vänner, barn, föräldrar och husdjur är olämpliga. Samma sak gäller dessa namn följda av en siffra (t.ex. Maria1). Namn är något som både någon i omgivningen kan gissa och en hackande dator kan testa sig fram till.

Alla ”klassiska” lösenord är självfallet också olämpliga. Eftersom det historiskt sett har skett ofantligt många lösenordsläckor har hackare skaffat sig en bra överblick över vilka lösenord som många användare väljer. När de vill komma åt ett konto börjar de därför med att testa de klassiska lösenorden. Exempel på sådana är:

  • 123456 (ibland 12345678)
  • password (ibland password1)
  • qwerty (de första bokstäverna på tangentbordet)
  • abc123
  • 00000000 eller 11111111
  • monkey
  • admin
  • iloveyou
  • (ett censurerat könsord)

Ovanstående lösenord och liknande lösenord bör därför absolut undvikas. Samma sak gäller ord som finns i ordlistor. Efter att ha testat de klassiska lösenorden utför hackarna nämligen det som kallas en ordlisteattack. En ordlisteattack är (precis som det låter) ett försök att komma åt ett konto genom att testa alla lösenord som finns i en ordlista. Den 13:e upplagan av Svenska akademiens ordlista innehåller 125 000 ord, vilket är få ord i sammanhanget. Det innebär att det går förhållandevis snabbt att hacka ett konto om lösenordet är något av orden som finns i ordlistan (eller något av orden följt av siffran 1, t.ex. skrivkramp1).

Hackare nöjer sig givetvis inte med att testa ord som finns i Saol. Hela internet är ett under­bart uppslagsverk för att hitta alla konstiga slangord och facktermer som ­används. Det gör att ett lösen-ord per definition är osäkert. Det är bättre att använda en lösen-mening.

En lösenmening är inte helt säker

En lösenmening eller lösenfras (från engelskans passphrase) är en kombination av ord som används istället för lösenord. Ett exempel på en lösenmening är:

OskarÄterLunch

eller

oskaräterlunch

Tyvärr är inte lösenmeningar helt säkra, även om de är säkrare än lösenord! Genom att först dammsuga internet efter vanliga meningar och fraser, kan hackare sedan testa de mest vanligt förekommande ordkombinationerna. Det kräver betydligt med datorkapacitet och tar betydligt längre tid, men lösenmeningarnas säkerhet sjunker i takt med att datorernas prestanda ökar. 

Lösenstrunt är säkert

Eftersom inte ens lösenmeningar är säkra bör istället ”lösenstrunt” användas. Lösen­strunt är en mening som inte betyder något eller i alla fall inte kan tänkas dyka upp någonstans på webben. Lösenstrunt kan mycket väl bestå av befintliga ord, men de ska kombineras på ett totalt nonsenssätt. Ett exempel på lösenstrunt är:

MuminFräschaFiskarFotar

Lösenstruntet ovan är lätt att komma ihåg. Föreställ dig Mumintrollet som står och foto­graferar fräscha fiskar. Det är totalt struntprat, men det är förhållandevis lätt att ­komma ihåg. Eftersom det är totalt nonsens är det heller inte något som en hackande dator kan testa sig fram till under överskådlig tid.

Lösen-ord bör av denna anledning ersättas av lösen-strunt. Lösenstrunt är lätta att ­komma ihåg och svåra att knäcka. Inloggningssidorna på webben borde alltså se ut som på följande bilder!

Inloggning till e-postkonto med användarnamn och lösenstrunt.

Traditionell rekommendation är osäker

Den traditionella rekommendationen i lösenordssammanhang är att blanda versaler, gemener, siffror och specialtecken. Ett exempel på ett sådant lösenord är:

kR&34Ca9

Problemet med ett sådant lösenord är att det är svårihågkommet. Om varje enskild webbtjänst ska få ett unikt sådant lösenord blir det snabbt ohanterbart. Ett sådant lösen­ord är dessutom svårt att skriva på en mobils eller surfplattas skärmtangentbord.

Det värsta med denna traditionella lösenordsrekommendation är att den är direkt kontra­produktiv. Den får användare att välja korta lösenord! Kravet på att blanda bokstäver och siffror har bevisligen till och med fått användare att använda lättknäckta lösenord som abc123!

Den ständigt upprepade uppmaningen att blanda versaler, gemener, siffror och special­tecken har fått många att tro att lösenordet kR&34Ca9 skulle vara säkrare än lösen­struntet MuminFräschaFiskarFotar. Så är inte fallet.

Brute-force-attack

En brute-force-attack innebär att en hackande dator testar alla möjliga kombinationer av tecken för att till slut hitta det rätta lösenordet. Den kan exempelvis börja med att testa kombinationen aaaaaaaa. Om det inte var rätt lösenord testar den aaaaaaab följt av aaaaaaac och så vidare tills den har kommit fram till rätt lösenord. Att testa fram rätt lösenord på detta vis tar enormt lång tid. Eftersom varken kR&34Ca9 eller MumintrollFotarGatlykta finns i någon ordlista (eller förekommer som en frekvent använd mening) är dock en brute-force-attack den enda metoden för att hitta lösenordet.

Lösenordets längd är i praktiken den mest avgörande faktorn för hur lång tid det tar för hackerdatorn att hitta det rätta lösenordet. Det framgår av följande exempel:

Varje enskilt tecken i ett lösenord som kR&34Ca9 kan vara ett av cirka 78 möjliga tecken eftersom det i teorin blandar upp till:

  • 29 versaler (A-Ö)
  • 29 gemener (a-ö)
  • 10 siffror (0-9)
  • Cirka 10 vanliga specialtecken ( ! # % & / @ * = ? - )

Det innebär att om lösenordet endast hade varit ett tecken långt hade det som längst tagit 78 (781) försök att hitta det rätta lösenordet. Med två tecken ökar antalet möjliga kombinationer till 6 084 (782). Med tre tecken ökar antalet möjliga kombinationer till 474 552 (783) stycken och så vidare. Vi kallar detta lösenordsmodell A.

Varje enskilt tecken i ett lösenord som MumintrollFotarGatlykta kan endast vara ett av 58 tecken. Detta eftersom det endast kan tänkas innehålla:

  • 29 versaler (A-Ö)
  • 29 gemener (a-ö)

Det är i och för sig något som inte den hackande datorn kan veta, men det är av underordnad betydelse.

Det innebär att om lösenordet endast hade varit ett tecken långt hade det som längst tagit 58 (581) försök att hitta det rätta lösenordet. Med två tecken ökar antalet möjliga kombinationer till 3 364 (582). Med tre tecken ökar antalet möjliga kombinationer till 195 112 (583) och så vidare. Vi kallar detta lösenordsmodell B.

Antalet kombinationer som finns av ett åtta tecken långt lösenord enligt lösenordsmodell A (78 alternativ per tecken) är 788:

1 370 114 370 683 140

Antalet kombinationer som finns av ett åtta tecken långt lösenord enligt lösenords­modell B (58 alternativ per tecken) är färre (588):

128 063 081 718 016

Hittills ser det ut som att lösenordsmodell A är säkrare. Men genom att öka lösenordet som följer lösenordsmodell B med ett enda tecken ökar antalet möjliga kombinationer till:

7 427 658 739 644 930

Ett nio tecken långt och lättihågkommet lösenord enligt lösenordsmodell B har över fem gånger fler tänkbara kombinationer än ett åtta tecken långt och svårihågkommet lösenord enligt lösenordsmodell A. Här följer en tabell som visar antalet möjliga kombinationer som lösenordsmodell B har vid ett bestämt antal tecken jämfört med ett åtta tecken långt lösenord enligt lösenordsmodell A.

Antal tecken 78 möjliga tecken 58 möjliga tecken
1 78 58
2 6 084 3 364
3 474 552 195 112
4 37 015 056 11 316 496
5 2 887 174 368 656 356 768
6 225 199 600 704 38 068 692 544
7 17 565 568 854 912 2207 984 167 552
8 1 370 114 370 683 140 128 063 081 718 016
9 7 427 658 739 644 930
10 430 804 206 899 406 000
11 24 986 644 000 165 500 000
12 1 449 225 352 009 600 000 000
13 84 055 070 416 556 900 000 000
14 4 875 194 084 160 300 000 000 000
15 282 761 256 881 297 000 000 000 000
16 16 400 152 899 115 200 000 000 000 000
17 951 208 868 148 684 000 000 000 000 000
18 55 170 114 352 623 700 000 000 000 000 000
19 3 199 866 632 452 170 000 000 000 000 000 000
20 185 592 264 682 226 000 000 000 000 000 000 000
21 10 764 351 351 569 100 000 000 000 000 000 000 000
22 624 332 378 391 008 000 000 000 000 000 000 000 000
23 36 211 277 946 678 500 000 000 000 000 000 000 000 000

Detta innebär att en hackande dator hinner testa alla kombinationer av åtta tecken långa lösenord i stil med kR&34Ca9 ganska många gånger, innan den en enda gång hinner igenom alla kombinationer av 23 tecken långa lösenord i stil med MumintrollFotarGatlykta (närmare bestämt över 26 tusen triljarder gånger).

Ett långt lösenord med en lite mindre teckenuppsättning blir snabbt säkrare än ett kort lösenord med en lite större teckenuppsättning.

Många funderar säkert på om det inte vore ännu säkrare att också lägga till specialtecken. Det blir det i teorin, så länge det inte leder till att lösenordet görs kortare (vilket det råder stor risk för). Det är dessutom onödigt i praktiken, vilket visas med följande exempel.

Ponera att det tar en dator en minut att testa alla kombinationer som finns av ett åtta tecken långt lösenord med en teckenuppsättning på 58 tecken (det är för övrigt betydligt snabbare än vad som är möjligt idag). Om lösenordet är helt slumpmässigt valt ­kommer datorn att hitta det efter i genomsnitt en halv minut. Genom att öka antalet tecken till nio stycken ökar antalet kombinationer 58 gånger. Det tar därmed 58 gånger så lång tid (58 minuter) att testa alla möjliga kombinationer. Genomsnittet hamnar då på 29 ­minuter. Genom att lägga till ytterligare ett tecken ökar antalet kombinationer 58 gånger igen. Det tar därmed 58 gånger så lång tid att testa alla möjliga kombinationer, vilket motsvarar drygt två dygn. Genomsnittstiden blir drygt ett dygn

Här följer en översikt över hur tiden det tar att hitta det rätta lösenordet ökar i takt med lösenordslängden.

Antal tecken Tid för att testa alla kombinationer Genomsnittlig tid
8 1 minut * 0,5 minuter
9 58 minuter 29 minuter
10 2 dygn 1 dygn
11 135 dygn 68 dygn
12 22 år 11 år
13 1 249 år 624 år
14 72 millennier 36 millennier
15 4 201 millennier 2 100 millennier
16 243 651 millennier 121 826 millennier

* 1 minut är satt som hypotetiskt startvärde. Det tar mycket längre tid egentligen.

Eftersom det knappast spelar någon roll om det tar hundratusen millennier eller tvåhundratusen millennier att hitta lösenordet, är behovet av specialtecken ganska litet. Det är viktigare med ett långt lösenord!

Obs! I dessa räkneexempel har lösenordsmodellerna förenklats så till vida att lösenordslängen alltid är känd (vilket den inte är). Rekommendationen förutsätter också att lösenstrunt (totalt nonsens) används.

Risken med lösenordsledtrådar

Lösenordsledtrådar är ett otyg som gör våra annars säkra lösenord (d.v.s. lösenstrunt) osäkra. Tanken är att lösenordsledtrådarna ska hjälpa oss komma på våra lösenord om vi glömmer bort dem. Problemet är att lösenordsledtrådarna alltför ofta används på fel sätt. Om lösenordsledtråden är ”sitter runt bananen” kan vem som helst räkna ut att lösenordet är ”bananskal”.

Samma problem finns hos webbtjänster som uppmanar sina användare att i samband med registrering välja och besvara en uppsättning lösenordsåterställningsfrågor i stil med:

  • Vad hette den första skolan du gick på?
  • Vilket var din mors flicksmeknamn?
  • Vad hette ditt första husdjur?

Problemet är att dessa frågor är alltför lätta att besvara. Min första skola hette Anneroskolan. Min mamma kallades Maja. Mitt första husdjur hette Kissemisse. Detta är svar som vem som helst som känner mig kan ta reda på. Inte minst så vet alla i min familj svaren på dem!

Lösenordsledtrådar och -ledtrådsfrågor bör aldrig användas. I princip alla webbtjänster erbjuder möjligheten att skicka ett nytt lösenord till den registrerade e-postadressen. Det är ett betydligt säkrare sätt att komma in på en tjänst vars lösenord är bortglömt. Om det i samband med registrering inte går att välja bort att skriva in en lösenordsledtråd eller besvara -ledtrådsfrågor bör ledtråden eller svaren vara ett annat lösenstrunt som aldrig används. Lägg förslagsvis struntsvaren i lösenordshanteraren som behandlas i slutet av detta kapitel.

Risken med att återanvända lösenord

Flera gånger per år råkar någon större webbtjänst ut för en lösenordsläcka. Det är den främsta anledningen till varför lösenord aldrig får återanvändas. Om samma lösenord används för fem webbtjänster och en av webbtjänsterna läcker lösenordet, kommer hackare också att kunna logga in på de fyra andra tjänsterna där samma kombination av lösenord och användarnamn används (inkl. tjänster som lagrar kreditkortsuppgifter).

En annan anledning till att aldrig återanvända lösenord är att långtifrån alla webb­tjänster skickar inloggningsdatan krypterat. Vid en okrypterad inloggning kan någon som befinner sig på samma öppna trådlösa nätverk snappa upp lösenordet och sedan försöka använda det på andra tjänster.

Behov av att byta lösenord

En annan traditionell uppmaning är att regelbundet byta lösenord. Upphovet till uppmaningen är risken för att en användares lösenord hamnar på avvägar. En kollega som får nys om en annan kollegas lösenord kan logga in som honom eller henne utan att någon märker det. Uppmaningen är därför en god idé i teorin, men den faller ofta i praktiken. Våra hjärnor är inte gjorda för att komma ihåg alla våra lösenord. De är än mindre gjorda för att regelbundet glömma samtliga lösenord och ersätta dem med en ny uppsättning. Utan assistens av en lösenordshanterare (se slutet av detta kapitel) är det helt enkelt omänskligt att följa uppmaningen och den resulterar ofta i att användarna istället väljer enkla lösenord. Om så blir fallet har även denna uppmaning varit direkt kontraproduktiv.

Användare som blir tvingade att regelbundet byta lösenord löser ofta ”problemet” ­genom att använda ett statiskt lösenord i kombination med en variabel siffra. Första månaden är lösenordet exempelvis tandborste1. Andra månaden är det tandborste2 och så vidare. Ett sådant lösenordsbyte medför en mycket liten säkerhetshöjning. En kollega som har kommit över lösenordet kan lätt förstå att om tandborste2-lösenordet slutar fungera så är det nya lösenordet med högsta sannolikhet tandborste3.

Det är däremot av högsta vikt att alltid byta lösenord efter att en tjänst har blivit utsatt för ett intrång och en lösenordsläcka. Om en webbtjänst skickar ut e-brev som säger att deras lösenordsdatabas har hamnat på avvägar bör du byta lösenord omgående. Klicka dock aldrig på länken i e-brevet! Öppna istället webbläsaren och skriv in adressen själv. Detta eftersom e-brevet kan vara sänt av bedragare och länken i själva verket går till en webbsida vars uppgift är att få ditt lösenord. Se exempelvis e-brevet på den följande bilden. Bedragarna uppmanar mottagaren att gå in på appleid.apple.com, men genom att klicka på länken i e-brevet hamnar mottagaren i själva verket på en tyskregistrerad nätfiskesida.

Klicka aldrig på länkar i e-brev. Det finns ingen garanti om vart de leder.

Hierarkisk säkerhetsnivå

Exakt hur säkert ett lösenord behöver vara beror på vilken tjänst det ska skydda. Lösenordet som skyddar ett sällan använt forumkonto behöver inte vara lika säkert som det som skyddar e-postkontot. Vissa tjänster behöver inte ens ha komplexa lösenord (d.v.s. lösenstrunt), eftersom de inte skyddar något väsentligt.

Hur säkert ett lösenord bör vara beror på var tjänsten befinner sig i säkerhetshierarkin. Hierarkin är inte någon lista som finns, utan bestäms av hur varje enskild användare väljer att koppla samman olika tjänster.

Längst upp i hierarkin finns användarens primära e-postkonto. E-posttjänsten är alltid den tjänst som måste skyddas bäst (gärna med tvåstegsverifiering som behandlas närmare senare i detta kapitel). Detta är för att i princip alla webbtjänster har en funktion för att återställa användarens lösenord och skicka ett nytt sådant till hans eller hennes e-postadress. En ljusskygg person som får tillgång till en användares e-postkonto har därmed också tillgång till alla andra webbtjänster (e-handelsbutiker, appbutiker, forum, sociala nätverk m.m.).

Ett hackat e-postkonto öppnar alla andra konton på grund av hur tjänsterna är sammankopplade.

Obs! Fortsätt aldrig att använda ett lösenord som skickas till ditt e-postkonto i samband med nyregistrering eller lösenordsåterställning. E-post skickas okrypterat och i klartext, vilket innebär att någon kan ha snappat upp lösenordet på vägen. Logga in med lösenordet som kom i e-brevet och byt till ett nytt lösenord (lösenstrunt).

Näst längst upp i hierarkin finns webbtjänster som kan påverka andra webbtjänster. Däribland finns framför allt Facebook, Twitter och Google Plus (om Gmail används som primär e-posttjänst tillhör Google Plus toppen av hierarkin). Detta eftersom dessa tjänster kan användas för att i sin tur logga in på andra tjänster. Det går exempelvis att logga in på fitnesstjänsterna Runkeeper, Fitbit och Sats med sitt Facebook- eller Google Plus-konto.

Använd säkra lösenord (lösenstrunt) till tjänster som i sin tur kan logga in på andra tjänster.

Längst ned i hierarkin finns tjänster som inte i sin tur kan användas för att komma in på ytterligare tjänster. Exempel på sådana är forumkonton och de nämnda fitness­tjänsterna.

Det räcker med att fundera över två punkter för att välja hur säkert lösenord en tjänst behöver:

  • Hur högt i säkerhetshierarkin befinner sig denna tjänst? Kommer den kunna ­användas för att i sin tur logga in på en annan tjänst? Ju högre upp i hierarkin tjänsten är, desto säkrare lösenord måste användas.
  • Hur känslig data kommer tjänsten att lagra? Kommer den att spara kreditkortsuppgifter?

Tvåstegsverifiering

Tjänster som ligger högt upp i hierarkin bör om möjligt skyddas med tvåstegsverifiering. Det är en teknik som gör att det inte räcker med ett lösenord för att logga in, utan det krävs två faktorer: dels ett lösenord och dels något annat. Det andra är generellt en tidsbaserad kod som genereras av en app som är installerad på användarens mobiltelefon. Den aktuella kodgenereringsappen är kopplad till kontot, så att ingen annan app eller mobiltelefon kan generera rätt kod.

Inloggning utan tvåstegsverifiering (endast lösenord krävs).
Inloggning med tvåstegsverifiering (lösenord och mobiltelefon krävs).

Google och Microsoft följer branschens de facto-standard för tvåstegsverifiering. Det gör att samma app kan användas för att tvåstegsverifiera både Google- och Microsoft-konton. Undertecknad chefredaktör rekommenderar följande appar för respektive operativ­system:

  • Android: Google Authenticator (utvecklad av Google och finns i Google Play)
  • IOS: Google Authenticator (utvecklad av Google och finns i App store)
  • Windows Phone: Microsoft Authenticator (utvecklad av Microsoft och finns i Windows Phone Store).

Enligt Googles beskrivning kan inte Microsoft Authenticator användas för att tvåstegsverifiera Google-konton, men det fungerar utmärkt (testat augusti 2014). Denna branschstandardlösning används även av bland annat Lastpass (lösenordshanteraren som behandlas längre fram i detta kapitel), Synology DSM (NAS-operativsystemet i Nätverk 16) och Facebook.

Apple har valt att använda en egen lösning för att erbjuda sina kunder ett utökat skydd. Deras lösning förlitar sig på appen Hitta min Iphone som endast finns till IOS. Tyvärr har Apple hittills valt att endast möjliggöra tvåstegsverifieringsskydd av inställnings­sidorna för Apple-ID samt köp i Itunes, App store och Ibooks store. Tvåstegsverifieringsskyddet omfattar inte känsliga tjänster som till exempel Iclouds e-posttjänst. ­Twitter har likaså valt en egen lösning för tvåstegsverifiering.

Inloggning med tvåstegsverifiering

Google och Microsoft är två av företagen som erbjuder tvåstegsverifiering enligt branschstandarden. Om en användare väljer att skydda sitt Google- eller Microsoft-konto med tvåstegsverifiering måste han eller hon både känna till sitt lösenord och ha tillgång till sin mobiltelefon för att kunna logga in till sin mail (Gmail respektive Outlook), inställningssidor och alla andra tjänster som använder kontot (t.ex. Google Plus, Google Drive, Microsoft Onedrive, Microsoft Office och Skype).

Det första steget vid inloggning med tvåstegsverifiering är att ange användarnamn och lösenord precis som vanligt.

När det korrekta lösenordet är angivet efterfrågar tjänsten en sexsiffrig kod.

Den sexsiffriga koden genereras av appen i användarens mobiltelefon och är endast giltig i ett visst antal sekunder.

Genom att skriva in den sexsiffriga koden släpps användaren in. Om inloggningen sker på en dator som används frekvent kan användaren be Google respektive Microsoft att inte efterfråga tvåstegsverifiering på just den datorn fler gånger. Google och Microsoft kommer dock fortsätta att kräva tvåstegsverifieringskoder vid inloggning på andra ­datorer och i andra webbläsare på samma dator.

Aktivera tvåstegsverifiering

Tvåstegsverifiering är i skrivande stund inaktiverat som standard. Det krävs att varje användare manuellt väljer att aktivera funktionen, vilket görs på samma ställe som ändring av lösenordet. Här följer ett exempel på hur det görs. I exemplet behandlas Gmail och Outlook eftersom båda dessa tjänster följer branschstandarden. Det är dessutom två tjänster som ligger högst i säkerhetshierarkin och därför har störst behov av tvåstegsverifiering.

För Gmail (Google-konto) öppnar vi datorns webbläsare och går till www.google.com/settings/security.

För Outlook (Microsoft-konto) öppnar vi datorns webbläsare och går till account.live.com/proofs/Manage.

Det första steget är att koppla samman vår mobiltelefon med kontot genom mobiltelefonens telefonnummer (om det inte redan är gjort). Detta för att verifieringskoderna ska kunna levereras som SMS.

SMS är både ett opraktiskt och ett långsamt sätt att få koderna levererade. Det är betydligt smidigare att använda någon av verifieringsapparna som nämndes tidigare i detta kapitel.

Det är dock bra att ha SMS-funktionen som en backup om det skulle bli problem med appen.

Både Google och Microsoft använder QR-koder för att koppla samman verifierings­appen med kontot. Vi öppnar därför appen, lägger till ett nytt konto och skannar QR-koden som webbtjänsten visar på datorns skärm.

Konfigurationen för Google (vänster) resp. Microsoft (höger).

Sedan är grundkonfigurationen klar! Nu kan appen generera koderna som krävs. ­Samma app kan användas för att generera koder åt flera tjänster.

För att minimera risken att bli utelåsta från vårt konto genomför vi två extrasteg. När det gäller Microsoft kopplar vi vårt Microsoft-konto till en alternativ e-postadress. Det gör att Microsoft kan skicka verifieringskoder till den e-postadressen om vi blir av med både appen och mobiltelefonnumret. Inställningen gör vi från samma sida som vi aktiverade tvåstegsverifieringen på.

När det gäller Google använder vi funktionen för att generera tio långtidsgiltiga verifierings­koder. Genom att skriva ut dem och förvara dem i plånboken har vi alltid med oss ett alternativt sätt att få fram en verifieringskod (om vi skulle bli av med vår mobiltelefon). Observera att varje långtidsgiltig kod endast går att använda en gång. Genereringen av långtidsgiltiga koder gör vi från samma sida som vi aktiverade tvåstegsverifieringen på.

Tvåstegsverifiering för inkompatibla appar

Tyvärr har inte alla program och appar stöd för tvåstegsverifiering. Som tur är går det problemet att lösa genom att generera program- och applösenord. Det är permanenta lösenord som genereras för varje enskilt program och enskild app som ska kopplas till kontot. Det är lämpligt för bland annat e-postklienter och kalenderappar som saknar stöd för tvåstegsverifiering.

Program- och applösenorden genereras från samma inställningssidor som användes för att aktivera tvåstegsverifieringen. Därifrån kan användaren också välja att dra tillbaka giltigheten för ett specifikt program- eller applösenord och därmed hindra det berörda programmet eller den berörda appen att komma åt kontot.

Lösenordshanterare

Även om ett lösenord i form av ett lösenstrunt kan vara förhållandevis lätt komma ihåg, är det orimligt att komma ihåg ett unikt lösenstrunt för varenda tjänst. Istället för att antingen göra lösenorden korta eller att återanvända samma lösenord bör en lösenordshanterare användas.

En lösenordshanterare genererar ett unikt och starkt lösenord (d.v.s. ett lösenstrunt) åt varje enskild tjänst som användaren skapar ett konto på. Användaren behöver aldrig komma ihåg dessa tjänstspecifika lösenord, eftersom lösenordshanteraren gör det åt honom eller henne. Det enda lösenordet som användaren behöver komma ihåg är det som lösenordshanteraren kräver för att i sin tur låsa upp alla andra konton (exempelvis ett Twitterkonto eller ett forumkonto). Det gör att alla tjänster kan skyddas med långa och svårknäckta lösenord (sådana som i genomsnitt tar åtminstone ett par millennier att testa fram) och användaren behöver aldrig memorera eller ange fler än ett sådant! Användaren kan till och med regelbundet byta lösenord till tjänster som kräver det, utan att han eller hon behöver memorera något nytt sådant. En lösenordshanterare löser helt enkelt lösenordsproblematiken.

Det finns en handfull populära lösenordshanterare. Undertecknad chefredaktör rekommenderar Lastpass (www.lastpass.com). Det är en betaltjänst som i skrivande stund kostar tolv dollar per år, men jag ser det som betryggande att företaget som transporterat mitt krypterade lösenordsarkiv har en tydlig finansieringsmodell.

Med Lastpass läggs alla lösenord in ett krypterat valv. Det krypterade valvet synkroniseras via Lastpass servrar till alla enheter som användaren äger. Lastpass finns till Windows, Windows RT, Mac OS X, Android, IOS och Windows Phone (för att nämna operativsystemen som vi behandlar i denna bok). Enheterna behåller varsin offlinekopia av det krypterade valvet så att lösenorden finns tillgängliga även om de saknar internetuppkoppling.

Lastpass synkroniserar det krypterade lösenordsvalvet till användarens alla enheter.

När en mobiltelefonanvändare vill logga in i en app behöver han eller hon bara öppna Lastpass-appen, skriva in huvudlösenordet, kopiera applösenordet som behövs och klistra in det i appen som efterfrågar det.

Om mobiltelefonen kör Android är det till och med ännu enklare. Tack vare Android-systemets uppbyggnad kan Lastpass-appen ta över inloggningen. Så fort användaren öppnar en app som efterfrågar inloggningsuppgifter dyker en Lastpass-knapp upp. Om användaren klickar på den och skriver in huvudlösenordet fyller Lastpass i användarnamn och lösenord automatiskt.

Kom ihåg lösenordet till Lastpass så kommer Lastpass ihåg lösenordet till allt annat.

Lika enkelt fungerar Lastpass i webbläsaren på datorer. Lastpass har utvecklat insticksprogram för Chrome, Firefox, Internet Explorer och Safari (för att nämna webb­läsarna som behandlas i denna bok). Insticksprogrammet gör att så fort användaren ska ­logga in på en webbsida kan han eller hon istället trycka på Lastpass-knappen, skriva in huvud­lösenordet och låta Lastpass fylla i alla uppgifter som webbsidan efterfrågar.

Lastpass har även en inbyggd funktion för att skapa säkra lösenord (d.v.s. ”lösenstrunt”). Lastpass har en pseudo-slumpgenerator som slumpar ut teckenkombinationer. Det går själv att välja vilka tecken som är tillåtna och huruvida lösenordet ska vara uttalbart eller inte. Genom att göra det uttalbart går det lätt att skriva av det och genom att inte använda annat än bokstäver blir det också lätt att vid behov skriva på mobiltelefoners och surfplattor skärmtangentbord.

Lösenordshanterare hamnar per automatik längst upp i säkerhetshierarkin som behandlades tidigare i detta kapitel. Det är därför en god idé att skydda lösenordshanteraren med tvåstegsverifiering. Detta har Lastpass stöd för och de följer branschens de facto-standard. Det gör att samma kodgenereringsapp som används för Gmail och Outlook även kan användas för Lastpass.

Obs! Användare som aktiverar tvåstegsverifiering på Lastpass-kontot bör också ha lösen­ordet till sitt e-postkonto tillgängligt på ett alternativt sätt. Detta eftersom Lastpass kan skicka en återställningskod till e-postkontot om mobiltelefonen som används för tvåstegsverifiering tappas bort. Utan mobiltelefonen riskerar användaren annars att hamna i ett moment 22 (han eller hon behöver Lastpass för att logga in på e-postkontot och behöver e-postkontot för att logga in på Lastpass).

Utöver Lastpass finns ett flertal andra lösenordshanterare. Här följer några exempel på populära sådana. Observera att jag inte har sett närmare på säkerheten i dessa. Jag vill framförallt varna för säkerhetsrisken med att använda inofficiella Keepass-klienter och -tillägg (d.v.s. allt förutom Keepass officiella Windowsklient). Att det är öppen källkod är i sig ingen garant för vare sig god säkerhet eller avsaknad av bakdörrar.

1password (betalalternativ)
agilebits.com/onepassword

Lösenordshanterare som är populär bland Mac OS X- och IOS-användare. Finns ­numera även till Windows och Android.

Icloud Nyckelring (ingår)
Apples egen lösenordshanterare för Mac OS X och IOS. Fungerar inte utanför Apples ekosystem.

Keepass (gratisalternativ)
keepass.info

Gratis lösenordshanterare som bygger på öppen källkod. Synkroniserar inte lösenord mellan enheter själv, men arkivet kan läggas i lämplig molntjänst. Endast officiellt stöd för Windows. Inofficiella klienter finns för andra operativsystem.

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

Lösenordshanterare som synkroniserar lösenord mellan Windows, Mac OS X, Android och IOS.

Sammanfattning

Detta avsnitt sammanfattar kapitlet kortfattat. Läs hela kapitlet för att få bakgrunden till rekommendationerna.

  • Använd inte lösenord som finns i ordlistor, är frekvent använda lösenord eller är något som folk i din närhet kan gissa sig fram till.
  • Använd hellre ett långt lösenord utan siffror och specialtecken än ett kort lösenord med siffror och specialtecken.
  • Använd helst av allt ”lösenstrunt”, eftersom sådana både är lätta att komma ihåg och svåra att knäcka.
  • Undvik att använda lösenordsledtrådar och -ledtrådsfrågor.
  • Återanvänd aldrig lösenord.
  • Låt ditt e-postkonto ha det säkraste lösenordet!
  • Aktivera om möjligt tvåstegsverifiering på de mest kritiska tjänsterna (däribland e-posttjänsten).
  • Använd en lösenordshanterare.
Senast ändrad: 2015-11-17