Lösenordsverktyg Tillbaka till generatorn

Säkerhetsguide

Varför Math.random inte är säkert för lösenord

Lär dig varför Math.random passar för UI-effekter men inte för lösenord, återställningskoder, tokens eller andra säkerhetskänsliga hemligheter.

Sammanfattning

Math.random() är en allmän JavaScript-pseudoslumpfunktion. Den är användbar för animationer, slumpmässigt UI-beteende, exempel, spel och simuleringar. Den är inte specificerad för kryptografisk säkerhet och bör inte användas för att generera lösenord, återställningskoder, API-hemligheter, signeringsnycklar eller återställningstokens.

Problemet

En lösenordsgenerator behöver oförutsägbarhet mot en angripare, inte bara värden som ser varierade ut för en användare. Math.random() ger ingen webbläsarstandardiserad kryptografisk säkerhetsgaranti, och implementationer kan skilja sig mellan motorer.

Det säkrare webbläsaralternativet

Moderna webbläsare tillhandahåller crypto.getRandomValues() via Web Crypto API. PwdGen använder detta gränssnitt och rejectionssampling, vilket undviker partisk teckenval. Om API:t inte är tillgängligt är det säkra beteendet att stoppa genereringen och förklara kompatibilitetskravet.

Hur man granskar en generator

Sök i källkoden efter Math.random. En seriös lösenordsgenerator bör inte använda den för lösenordstecken. Den kan förekomma i dokumentation som förklarar varför den är osäker, men inte i genereringsvägen.

Detaljerad vägledning

Denna guide fokuserar på varför Math.random är olämpligt för lösenord och hemligheter. Den är skriven för utvecklare, studenter och verktygsanvändare som kontrollerar om en generator använder säker slumpmässighet, så det praktiska målet är inte att skapa ett dramatiskt säkerhetspåstående. Målet är att välja en lösenordsvana som kan överleva vardaglig användning: inloggningsformulär, lösenordshanterare, mobila tangentbord, kontorelatering, delade enheter och den enstaka tjänsten med konstiga valideringsregler. En säker rekommendation är bara användbar om en verklig person kan följa den konsekvent.

Den säkraste utgångspunkten är slumpmässighet plus unikhet. Slumpmässighet innebär att värdet väljs från ett stort utrymme av en kryptografiskt lämplig slumpkälla, inte uppfunnet från en födelsedag, ett husdjursnamn, ett tangentbordsmönster eller ett favoritcitat. Unikhet innebär att samma lösenord inte används någon annanstans. Ett lösenord som är långt men återanvänt kan misslyckas snabbt efter en orelaterad dataintrång, medan ett unikt slumpmässigt lösenord begränsar skadan till det enda kontot där det användes.

För detta ämne är en praktisk förinställning crypto.getRandomValues med rejectionssampling istället för Math.random. Du kan tillämpa den förinställningen med Web Crypto API-guiden och sedan lagra slutvärdet i en betrodd lösenordshanterare. PwdGen genererar värden lokalt i webbläsaren med Web Crypto; det genererade lösenordet skickas inte till en PwdGen-server. Den lokala designen minskar exponeringen på serversidan, men den skyddar inte mot alla hot. En skadlig webbläsartillägg, en komprometterad enhet, en nätfiskesida eller osäker klippbordshantering kan fortfarande exponera en hemlighet efter att den genererats.

De vanligaste problemen att undvika är förutsägbara pseudoslumpsekvenser, modulobias, anpassade slumpfunktioner och demokod som kopierats till produktion. Dessa problem spelar roll eftersom angripare sällan behöver brute-force varje möjligt lösenord när mänskliga vanor ger dem en genväg. Credential stuffing, nätfiske, läckta lösenordslistor och missbruk av kontorelatering är ofta mer realistiska än en ren matematisk sökning. Därför kombinerar den bästa rådgivningen lösenordskvalitet med kontonivåkontroller som MFA, passkeys, lagring av återställningskoder och regelbunden granskning av återställnings-e-post eller telefoninställningar.

Använd denna checklista när du tillämpar rekommendationen:

Om en webbplats avvisar den ideala inställningen, tvinga inte lösenordet till ett svagare mönster för hand. Justera en variabel i taget. Om symboler avvisas, behåll versaler, gemener och siffror aktiverade och öka längden. Om en maxlängd är låg, använd den största accepterade längden och se till att värdet är unikt. Om ett lösenord måste läsas högt, skrivas ut eller skrivas på en TV- eller routerskärm, överväg att utesluta förvirrande tecken och öka längden för att kompensera för det mindre alfabetet.

Slutligen, kom ihåg gränsen för lösenordsrådgivning. Ett starkt lösenord är ett lager av försvar, inte en garanti. Det kan inte göra en nätfiskesida säker, åtgärda skadlig programvara eller kompensera för en tjänst som lagrar referenser dåligt. Den användbara vanan är tråkig men hållbar: generera ett unikt värde, lagra det säkert, skydda återställningsvägen och byt ut det snabbt om du misstänker exponering.

Ett säkert nästa steg

Efter att ha läst denna guide, gör en liten kontogranskning istället för att försöka fixa allt på en gång. Välj det konto som skulle orsaka mest problem om det övertogs, bekräfta att dess lösenord är unikt och kontrollera återställnings-e-post, återställningstelefon, MFA-metod och lagring av reservkoder. Om någon del av den kedjan är svag, förbättra den delen innan du går vidare till konton med lägre risk. Denna ordning håller arbetet hanterbart och skyddar de konton som angripare mest sannolikt använder som en språngbräda. För varför math.random inte är säkert för lösenord är det bästa resultatet en repeterbar vana: generera lokalt, lagra noggrant och undvik återanvändning.

Vanliga frågor

Är Math.random någonsin okej?

Ja, för visuella effekter, simuleringar och vanlig UI-slumpmässighet, men inte för referenser eller säkerhetstokens.

Vad bör lösenordsgeneratorer använda istället?

De bör använda en kryptografisk slumpkälla som crypto.getRandomValues() i webbläsaren.

Faller PwdGen tillbaka på Math.random?

Nej. Om Web Crypto inte är tillgängligt visar PwdGen en kompatibilitetsvarning och genererar inte lösenord med Math.random().

Källor