Oskyddade lösenord: En risk för användare
Det har uppmärksammats att åtskilliga företag nyligen har medgett att de förvarar lösenord i ren text, vilket kan jämföras med att notera ett lösenord i en textfil och spara den. Lösenord bör istället skyddas med salting och hashning. Frågan uppstår varför denna grundläggande säkerhetsåtgärd fortfarande inte är praxis under 2019.
Riskerna med att spara lösenord i klartext
När företag sparar lösenord i ren text, blir de tillgängliga för alla som får tillgång till den aktuella lösenordsdatabasen eller den fil där lösenorden lagras. Om en illvillig aktör lyckas infiltrera databasen kan de få insyn i samtliga lösenord.
Detta förfaringssätt är oacceptabelt. Lösenord bör hanteras genom salting och hashning, vilket innebär att ytterligare data läggs till lösenordet innan det omvandlas på ett oåterkalleligt sätt. Detta skyddar lösenordet även om en databas skulle bli stulen, eftersom de stulna lösenorden då blir oanvändbara. När en användare loggar in kan systemet jämföra det angivna lösenordet med den hashade versionen, utan att kunna utläsa originalet.
Varför väljer då företag att spara lösenord i klartext? Ibland beror det på att säkerhet inte tas på allvar, eller att företag medvetet kompromissar med säkerheten för att underlätta användningen. Ibland gör företagen rätt när de ursprungligen sparar lösenord, men lägger senare till loggningsfunktioner som av misstag registrerar lösenorden i ren text.
Företag som misslyckats med lösenordshantering
Det är möjligt att du själv har påverkats av detta bristfälliga säkerhetsförfarande. Företag som Robin Hood, Google, Facebook, GitHub och Twitter har alla hanterat lösenord i klartext på ett eller annat sätt.
Google hashade och saltade visserligen de flesta lösenord på ett korrekt sätt, men lösenord för G Suite Enterprise-konton lagrades i klartext. Google förklarade att detta härrörde från en tidigare praxis när domänadministratörer hade verktyg för att återställa lösenord. En korrekt hantering av lösenorden hade omöjliggjort en sådan återställningsmetod. Endast en lösenordsåterställningsprocess är lämplig när lösenord är skyddade på rätt sätt.
När Facebook också tillät lagring av lösenord i klartext, angavs inte den exakta orsaken. Däremot framgår problematiken från en senare uppdatering:
“…vi upptäckte ytterligare loggar med Instagram-lösenord som lagrades i ett läsbart format.”
Ibland har företag rätt metod från början, men att de lägger till nya funktioner som skapar problem. Utöver Facebook har Robin Hood, Github och Twitter oavsiktligt loggat lösenord i klartext.
Loggning är värdefull för att identifiera problem i applikationer, hårdvara och systemkod. Men om ett företag inte testar loggningen noggrant, kan det skapa fler problem än det löser.
I fallen med Facebook och Robinhood, kunde loggningsfunktionerna se och registrera användarnamn och lösenord i samband med inloggningen. Därefter lagrades dessa loggar på en separat plats. Den som fick tillgång till loggarna hade då allt som behövdes för att ta över ett konto.
I extrema fall kan företag som T-Mobile Australia bortse från säkerheten, ibland i bekvämlighetens namn. I ett numera raderat Twitter-utbyte förklarade en representant för T-Mobile att företaget sparar lösenord i ren text. Denna hantering gav kundtjänsten möjlighet att se de fyra första bokstäverna i ett lösenord för bekräftelse. Andra användare påpekade hur riskabelt det skulle vara om