Dags att byta lösenord för tredje gången i år?

Känns det jobbigt att ständigt tvingas byta lösenord? Då är du inte ensam. Många organisationer kräver fortfarande att deras användare byter lösenord regelbundet, troligtvis baserat på föråldrade uppfattningar om att det är ett effektivt skydd.

I det här inlägget kan du läsa om flera säkerhetsåtgärder som är mycket effektivare än att tvinga användare att byta lösenord.

Hur är det då med de påtvingade lösenordsbytena? Höjer de säkerheten? Inte alls, visar det sig. Forskningen pekar i en diametralt motsatt riktning: påtvingade lösenordsbyten sänker ofta säkerheten! University of North Carolina och NIST visar att användare som tvingas byta lösenord ofta väljer svagare varianter av sina tidigare lösenord, vilket förenklar för angripare att gissa det nya lösenordet[1][2].

Sedan 2015 har flera ledande säkerhetsorganisationer, inklusive NIST[3] i USA och NCSC[4] i Storbritannien, avrått från regelbundna lösenordsbyten eftersom de ofta leder till sämre säkerhet och mer frustration hos användarna. I stället rekommenderas andra åtgärder som stärker säkerheten på ett hållbart sätt. Dessa åtgärder rör både användare och it-administratörer.

  1. Använd långa lösenfraser
    Lösenfraser på minst 12-14 tecken ökar både säkerhet och användarvänlighet. Det är längden snarare än svåra specialtecken som gör lösenordet svårt att knäcka och en fras är lättare att komma ihåg än ett komplext lösenord.

    För utvecklare betyder detta att systemet måste tillåta långa lösenord. Tyvärr har många system fortfarande begränsningar i hur långa lösenord får vara, vilket ställer till det för användare som försöker att använda långa lösenord eller lösenfraser.

  2. Undvik tvingande komplexitet
    Istället för att tvinga fram komplicerade kombinationer av specialtecken och siffror, tillåt dem frivilligt och inkludera då även emojis och UNICODE-tecken så att användaren själv får välja.

  3. Presentera säkerhetsinformation för användaren
    Informera användare om senaste misslyckade inloggningsförsöket för att hjälpa till att upptäcka misstänkt aktivitet.

  4. Blockera upprepade inloggningsförsök
    För att minska risken att en angripare lyckas gissa ett lösenord eller prova sig fram bör upprepade inloggningsförsök spärras. Tänk dock på risken att en angripare medvetet försöker spärra ett konto och stänga ute den legitima användaren. Därför kan det vara aktuellt att spärra inloggning baserat på varifrån inloggningsförsöket gjorts eller en kombination av vem och varifrån.

  5. Förhindra användning av tidigare läckta lösenord eller ord från ordböcker
    Hindra användarna från att använda lösenord som funnits med i tidigare dataintrång genom tjänster som tex. HaveIBeenPwned.com, eller ord från ordböcker. Dessa lösenord är bland de första en angripare testar för att logga in med någon annans konto.

  6. Tillämpa flerfaktorsautentisering MFA
    Flerfaktorautentisering skyddar mot intrång även om ett lösenord komprometteras och kommer på villovägar. En tvåfaktorenhet som du tappar kommer du att sakna, till skillnad från ett läckt lösenord som du inte saknar förrän någon missbrukar det – och då är det för sent.

  7. Använd lösenordshanterare
    Det finns en rad bra lösenordshanterare på marknaden som hjälper dig eller dina användare att välja bra lösenord som är unika och inte behöver återanvändas. På köpet får du ofta en sk plugin som skriver in lösenordet åt dig i din webbläsare eller app. På så sätt förenklas hela inloggningsproceduren även om du har olika lösenord överallt. Många lösenordshanterare är dessutom ganska billiga att köpa, eller ingår i ditt operativsystem. Det är sällan vi ser lösningar som ger hög säkerhet samtidigt som de ökar användarvänligheten och inte heller kostar så mycket.

    För dig som arbetar med utveckling av it-system: Tillåt att användaren klistrar in lösenord i inloggningsfälten och hindra inte lösenordshanterare från att fylla i användarens inloggningsuppgifter. Genom att tillåta lösenordshanterare behöver vi inte lägga lika stort fokus vid hur en användare väljer ett bra lösenord eftersom lösenordshanteraren gör detta åt oss!

  8. Lagra lösenord säkert
    Detta är inte bara en uppmaning till dig som användare att lagra dina lösenord i en lösenordshanterare. Det är också en uppmaning till dig som utvecklar it-system där lösenord används. Ett tips som är en självklarhet för de flesta, men som fortfarande alltför ofta orsakar onödiga läckor: Lagra aldrig användarnas lösenord i klartext. Alla kan bli hackade – och den dag det är din tur att blir hackad vill du inte ha dina användares lösenord lagrade i klartext. Lagra istället lösenord i sk. hashad och saltad form. Då minskar du risken att användare som mot bättre vetande ändå återanvänder eller ersätter lösenord1 med lösenord2 när de tvingas byta lösenord regelbundet blir hackade. Och om du inte redan har implementerat MFA så gör även det.

Vi ställer idag stora krav på att våra användare ska vara säkerhetsmedvetna och bete sig säkert. Det är lika viktigt att vi som bygger och förvaltar it-system gör det på ett säkert sätt. Det innebär att vi hjälper användarna att fokusera på rätt säkerhet och på rätt sätt.

Så, vilket lag tillhör du? Det lag som håller fast vid gamla traditioner eller det lag som anpassar sig till dagens hotbild och implementerar moderna säkerhetslösningar?

Michael Westlund

Michael Westlund är säkerhetsarkitekt och hjälper organisationer att bygga säkra system där inte bara teknik utan också användarna är i fokus.

Referenser

[1] Time to rethink mandatory password changes | Federal Trade Commission https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2016/03/time-rethink-mandatory-password-changes

[2] Quantifying the security advantage of password expiration policies | Designs, Codes and Cryptography https://link.springer.com/article/10.1007/s10623-015-0071-9

[3] The problems with forcing regular password expiry https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry

[4] NIST Special Publication 800-63B: Digital Identity Guidelines https://pages.nist.gov/800-63-3/sp800-63b.html