Lösenordshanterare samlar alla hemligheter i ett krypterat valv men måste dekryptera i användarens dator

Lösenordshanterare säljs ofta som den vuxna lösningen på nätets lösenordskaos: skapa långa, unika inloggningsuppgifter, lagra dem i ett krypterat valv och låt programmet sköta resten. Men ett återkommande tema i ny säkerhetsforskning och i rapporter om intrång är att många lösenordshanterare delar samma grundsvaghet. Den sitter sällan i valvets kryptering, utan i den miljö på användarens sida där hemligheterna måste låsas upp och faktiskt användas.

Som Wired beskriver är den ”dolda svagheten” att lösenordshanteraren till slut måste presentera inloggningsuppgifter för webbläsare och program – ofta genom automatisk ifyllning, urklipp eller logik som injiceras för att fylla i formulär. Det är i det ögonblicket som elegant kryptografi möter den röriga verkligheten på slutanvändarens apparat: ändpunkter, tillägg och gränssnittsautomatisering. Om en angripare kan ta kontroll över enheten – genom skadlig kod, illasinnade webbläsartillägg eller trojaner som stjäl inloggningar – blir valvet mindre en fästning och mer ett välordnat arkivskåp för tjuvar.

Angreppsytan brukar samlas i några förutsägbara kategorier.

För det första: komprometterad klient. När angriparen väl ”äger” ändpunkten kan han fånga huvudlösenordet när det skrivs in, skrapa fram dekrypterade hemligheter ur minnet, kapa hjälpmedelsgränssnitt eller helt enkelt vänta tills användaren låser upp valvet och sedan föra bort resultatet. Det här är inte ett hypotetiskt felsätt, utan en direkt följd av konstruktionen: klartext måste finnas någonstans, om än tillfälligt, för att inloggningar ska fungera.

För det andra: missbruk av automatisk ifyllning och formulärinjektion. Automatisk ifyllning är en bekvämlighetsfunktion som samtidigt fungerar som ett automatiseringsgränssnitt. Om en illasinnad sida kan lura lösenordshanteraren att fylla i fel fält, eller skapa formulär som liknar de riktiga och sedan skörda det som fylls i, kan hanteraren förvandlas till ett orakel för inloggningsuppgifter. Vissa produkter dämpar risken med domänmatchning och uppmaningar om användarbekräftelse, men spänningen kvarstår: ju mer ”handsfree” systemet är, desto lättare kan det förmås att agera i användarens ställe.

För det tredje: risker i leveranskedjan och vid uppdateringar. Lösenordshanterare är program som distribueras via programbutiker, marknadsplatser för webbläsartillägg och uppdateringskanaler. En komprometterad byggkedja, ett kapat utvecklarkonto eller ett illasinnat beroende kan göra en betrodd uppdatering till en masshändelse där inloggningsuppgifter förs bort. Centralisering förstorar vinsten.

För det fjärde: återställning och kontoflöden. Även när valvkrypteringen är stark introducerar ekosystemet runt den – lösenordsåterställningar, nyregistrering av enheter, kontåterställning, säkerhetskopior och export av valv – alternativa vägar. Angripare behöver inte knäcka avancerad kryptering om de kan manipulera stödprocesser eller missbruka återställningsmekanismer.

Ironin är att branschens bästa råd – samla dina hemligheter i ett välskött system – också samlar din felzon. Användaren som ”gjorde allt rätt” (unika lösenord, flerfaktorsautentisering, ingen återanvändning) kan ändå ha skapat ett enda mål med högt värde: en upplåst session på en ändpunkt som kan tvingas att lämna ifrån sig innehållet.

Överge inte lösenordshanterare, utan justera hotmodellen. Se ändpunktsskydd som icke förhandlingsbart (uppdateringar av operativsystemet, minsta möjliga behörighet, försiktighet med webbläsartillägg). Föredra hanterare och inställningar som kräver uttrycklig användarinteraktion före ifyllning, använd hårdvarustödd flerfaktorsautentisering för hanterarens konto och dela upp där det går: särskilt värdefulla inloggningar (e-post, bank, administratörskonton) kan motivera mer friktion, inklusive separata valv eller särskilda enheter.

Lösenordshanterare minskar den systematiska risken med återanvända lösenord. De upphäver inte lagarna för komprometterade klienter – och det kan de inte, eftersom användaren fortfarande måste logga in någonstans.