Nycklar och lösenord: varför att förlora en förstör allt

Varje lektion i den här kursen har tyst förlitat sig på samma antagande: rätt nyckel stannade hos rätt person. Symmetrisk kryptering fallerar i samma stund dess delade nyckel läcker. Asymmetrisk kryptering fallerar om en privat nyckel exponeras. En signatur betyder ingenting när väl dess privata nyckel är stulen — en angripare kan nu signera vad som helst och det kommer att verifieras som äkta. NCAE-C:s grundläggande kryptografi-kunskapsenhet listar nyckelhantering, tillsammans med själva algoritmerna, som en fråga som ”måste hanteras före implementering” — inte en eftertanke.

Varför en stark algoritm inte räddar en svag nyckel

AES med en 256-bitars nyckel är, i praktiken, oknäckbar genom gissning. Inget av det spelar roll om själva nyckeln är skriven på en gul lapp, återanvänd över konton, eller skyddad av en fyrsiffrig kod en angripare kan prova på sekunder. De flesta verkliga kryptografiska misslyckanden är inte trasiga algoritmer; de är exponerade nycklar, återanvända lösenord, eller hemligheter lämnade i klartext där de borde ha skyddats. Det är därför de föregående lektionernas garantier alltid kom med ett villkor bifogat — ”om den delade nyckeln förblir hemlig”, ”bara innehavaren av den privata nyckeln” — det villkoret är där nyckelhantering lever.

Vad aktuell lösenordsvägledning faktiskt säger

NIST:s nuvarande riktlinjer för digital identitet (SP 800-63B) vänder på mycket av rådet många människor lärt sig. Verifierare, säger den, ”SKA INTE kräva att abonnenter byter lösenord periodiskt” och bör inte påtvinga sammansättningsregler som tvingar fram blandningar av teckentyper — båda praxis som drev folk mot små, förutsägbara variationer istället för genuint starkare lösenord. Istället rekommenderar NIST längre lösenord (dess vägledning pekar mot ett minimum i intervallet åtta till femton tecken beroende på sammanhang, med ett maximum på minst 64 tillåtet) och att kontrollera nya lösenord mot listor över vanligt läckta eller förväntade lösenord istället för att kräva konstgjord komplexitet. Den kräver också uttryckligen att verifierare ”tillåter användning av lösenordshanterare och autofyllnadsfunktionalitet”, inklusive att tillåta inklistring i lösenordsfält — och erkänner att ett verktyg som genererar och lagrar unika, långa lösenord per webbplats gör mer för säkerheten än någon regel en person kan förväntas följa utantill.

Passkeys: att ta bort den delade hemligheten helt

Ett lösenord är en delad hemlighet: både du och tjänsten känner till det, vilket är precis det som gör det nätfiskbart — en falsk inloggningssida frågar bara efter samma hemlighet. En passkey undviker detta genom att använda den asymmetriska krypteringen från tidigare i den här kursen. Apples supportdokumentation beskriver processen: din enhet genererar ”ett unikt kryptografiskt nyckelpar” när du skapar en passkey — en publik nyckel som går till tjänsten, och en privat nyckel som aldri lämnar din enhet. Apple anger att passkeys är motståndskraftiga mot nätfiske eftersom det inte finns någon delad hemlighet att lura dig att skriva in: den privata nyckeln kan helt enkelt inte extraheras av en falsk webbplats, oavsett hur övertygande den ser ut. På Apple-enheter skyddas och synkroniseras den privata nyckeln över dina egna enheter via iCloud-nyckelring, som Apple beskriver som totalsträckskrypterad så att inte ens Apple har nyckeln.

CISA:s hierarki av faktorer, i korthet

Vägledning från den amerikanska Cybersecurity and Infrastructure Security Agency om flerfaktorsautentisering rangordnar metoder efter motståndskraft mot nätfiske. Den anger att ”den enda allmänt tillgängliga nätfiskeresistenta autentiseringen är FIDO/WebAuthn-autentisering” — samma underliggande standard passkeys är byggda på. En engångskod skickad via textmeddelande är, med dess ord, fortfarande mycket bättre än ingen andra faktor alls, men den kan vidarebefordras eller avlyssnas på sätt en nätfiskeresistent metod inte kan. Där en tjänst erbjuder en passkey eller en FIDO-säkerhetsnyckel är det för närvarande det starkaste allmänt tillgängliga alternativet; där den bara erbjuder appbaserade koder eller SMS är endera fortfarande betydligt bättre än enbart lösenord.

En praktisk slutsats

Använd en lösenordshanterare, så att varje konto får ett långt, unikt lösenord du aldrig behöver komma ihåg. Slå på den starkaste tillgängliga andra faktorn — en passkey eller en fysisk säkerhetsnyckel där den erbjuds, en autentiseringsapp annars. Och behandla varje tillfälle ett lösenord eller en nyckel möjligen exponerades — ett nätfiskeklick, en förlorad enhet, ett läckagemeddelande — som något att agera på omedelbart, inte senare: byt autentiseringsuppgiften, och kontrollera om den återanvändes någon annanstans.