Lösenordslagring gjort rätt: Hashing, Salting och bcrypt vs. Argon2 vs. PBKDF2

De flesta tänker aldrig på hur deras lösenord lagras efter att de klickat på Registrera dig. De litar bara på att företag hanterar det på rätt sätt. Men det förtroendet förtjänar man inte alltid. Lösenordslagring är ett av de vanligaste områdena inom applikationssäkerhet som misshantas, och konsekvenserna av att göra fel är allvarliga.

Varje år exponerar dataintrång miljontals användaruppgifter. I många fall lagrades dessa uppgifter på sätt som gjorde det enkelt att knäcka dem. Ingen saltning, svaga hashkoder , ibland till och med klartext. Det här är inte edge-fall. Det är återkommande fel som påverkar riktiga användare.

Det här inlägget förklarar hur säker lösenordslagring faktiskt ser ut, från grunderna i hashing och salting till en praktisk jämförelse av bcrypt, Argon2 och PBKDF2. Om du bygger eller granskar ett autentiseringssystem är det här du ska börja.

Varför säker lösenordslagring är viktig

När angripare stjäl en lösenordsdatabas har de inte omedelbart tillgång till allas lösenord. Det de har är en uppsättning lagrade representationer. Om dessa skapades korrekt är informationen i stort sett värdelös för dem. Annars kan de återställa tusentals riktiga lösenord på bara några timmar.

Risken stannar inte vid ett enda konto. Människor återanvänder lösenord över olika tjänster. Ett knäckt lösenord från en app med låg risk kan låsa upp e-postkonton, bankinloggningar eller företagssystem. Den kedjereaktionen är anledningen till att även små applikationer bär ansvar för sina användares bredare säkerhet.

Det finns också en efterlevnadsdimension. Ramverk som NIST SP 800-63B, GDPR och PCI-DSS har alla förväntningar på hur autentiseringsdata skyddas. Dålig lösenordslagring är både ett tekniskt fel och ett regulatoriskt fel, med påföljder och anseendeskador att följa.

Förstå hashing och lösenordssaltning

En kryptografisk hashfunktion tar ett lösenord som indata och producerar en utdata med fast längd som kallas en hash eller digest. Den viktigaste egenskapen är att den här processen bara går åt ett håll. Du kan inte vända en hash för att få tillbaka det ursprungliga lösenordet. Så istället för att lagra lösenord direkt lagrar systemen sina hashkoder. Vid inloggning hashas det angivna lösenordet och jämförs med vad som lagrades.

Det här låter tillräckligt säkert. Men generella hashfunktioner som MD5 och SHA-256 byggdes för hastighet, inte för lösenord. En modern GPU kan beräkna miljarder SHA-256-hashar per sekund. Den hastigheten är en fördel för angripare som kör brute-force- eller dictionary-attacker.

Lösenordssaltning adresserar en specifik attack: regnbågstabeller. En regnbågstabell är en förberäknad uppslagning av hashkoder för vanliga lösenord. En angripare kan ta en stulen hashkode och slå upp den på några sekunder utan att göra någon riktig beräkning.

Ett salt är en unik, slumpmässigt genererad sträng som läggs till varje lösenord före hashing. Även om två användare har samma lösenord, gör deras saltar att de resulterande hasherna blir helt olika. Detta gör regnbågstabeller oanvändbara och tvingar angripare att knäcka varje hash individuellt.

Salter är inte hemliga. De lagras tillsammans med hashkoden. Deras värde kommer från att vara unika och slumpmässiga, inte från att vara dolda. Saltning är inte kryptering. Det är ett sätt att besegra förberäkningsattacker.

bcrypt förklaras: Styrkor, svagheter och när man ska använda det

bcrypt skapades 1999 specifikt för lösenordshashning. Det inkluderar automatisk saltning och en konfigurerbar kostnadsfaktor, även kallad arbetsfaktor, som styr hur beräkningsmässigt dyr hashningen är. Öka kostnadsfaktorn så ökar du tiden som behövs per hash, vilket saktar ner angripare som försöker knäcka lösenord i stor skala.

Styrkor:

• Inbyggd saltning: bcrypt genererar och lagrar ett unikt salt per lösenord automatiskt, vilket eliminerar en vanlig källa till utvecklarfel.
• Adaptiv kostnadsfaktor: Allt eftersom hårdvaran förbättras kan du öka arbetsfaktorn för att bibehålla motståndskraften mot attacker.
• Stridstestad: Över 25 års granskning utan att några grundläggande sårbarheter hittats.
• Brett stöd: Tillgänglig i praktiskt taget alla större programmeringsspråk och ramverk.

Begränsningar:

• 72 teckengräns: bcrypt avkortar indata utöver 72 byte. Detta kan vara ett problem för långa lösenfraser om det inte hanteras korrekt.
• Ingen minneshårdhet: bcrypt kräver inte betydande RAM, vilket gör det mer sårbart för mycket parallella hårdvaruattacker jämfört med nyare alternativ.

Argon2 vs. PBKDF2 vs. bcrypt: Viktiga skillnader som spelar roll

Inte alla lösenordshashningsalgoritmer erbjuder samma skyddsnivå. Så här jämför de tre huvudalternativen sig utifrån de faktorer som är viktigast.

Leverans	bcrypt	Argon 2	PBKDF2
Minneshårdhet	Inte minnessvårt	Hårdminne med konfigurerbar RAM-användning	Inte minnessvårt
Inbyggd saltning	Ja, automatiskt	Ja, automatiskt	Nej, måste hanteras manuellt
Parallellitetskontroll	Stöds inte	Stöds via Argon2id	Stöds inte
Lösenordslängdsgräns	Begränsat till 72 byte	Ingen begränsning	Ingen begränsning
NIST rekommenderas	Inte listad i SP 800-63B	Ja	Ja
GPU-motstånd	Moderate	Hög	Låg till måttlig
Mognad	Genom åren	Tillgänglig sedan 2015	Tillgänglig sedan 2000

Argon2: Den moderna standarden

Argon2 vann Password Hashing Competition 2015 och rekommenderas av NIST i SP 800-63B. Det finns i tre varianter. Argon2d motstår GPU-attacker. Argon2i motstår sidokanalattacker. Argon2id kombinerar båda och är det rekommenderade valet för de flesta lösenordslagringsscenarier.

Det som skiljer Argon2 från mängden är minneshårdheten. Det kräver en konfigurerbar mängd RAM under beräkningen. Detta gör parallella attacker mot specialiserad hårdvara som ASIC:er eller FPGA:er betydligt dyrare. Högre minneskostnad innebär färre samtidiga hackningsförsök som en angripare kan köra.

PBKDF2: Efterlevnadsalternativet

PBKDF2 är den äldsta av de tre och används flitigt i FIPS-validerade miljöer eftersom den är byggd på godkända HMAC- konstruktioner. Om din organisation kräver FIPS 140-2- eller 140-3-efterlevnad, vilket är vanligt inom federala och reglerade finanssektorer, kan PBKDF2 med SHA-256 eller SHA-512 krävas. Den saknar minneshårdhet, vilket gör den till den svagaste av de tre mot hårdvaruattacker. Kompensera med ett högt iterationsantal. NIST rekommenderar minst 600 000 iterationer med HMAC-SHA-256.

Bästa praxis för att lagra lösenord säkert

Att välja rätt algoritm är bara början. Här är vad en solid implementering bör innehålla:

• Välj rätt algoritm: Använd Argon2id för nya system. Behåll bcrypt för befintliga system med en kostnadsfaktor på 12 eller högre. Använd PBKDF2 endast när det krävs enligt gällande regelverk.
• Justera dina parametrar: För Argon2id rekommenderar OWASP minst 19 MiB minne, 2 iterationer och 1 grad av parallellitet. Justera uppåt baserat på din serverkapacitet och acceptabel inloggningslatens.
• Använd alltid unika, slumpmässiga salter: Även om ditt bibliotek hanterar saltning automatiskt, kom ihåg att det gör det. Använd aldrig statiska värden eller sekventiella identifierare som salt.
• Framtvinga starka lösenord: Hashing ersätter inte en bra lösenordspolicy. Kräv minimilängder, avvisa kända lösenord som brutits och stöd för flerfaktorsautentisering.
• Separat lagring av autentiseringsuppgifter: Lagra lösenordshash i en dedikerad lagring med strikta åtkomstkontroller. Program bör endast få åtkomst till autentiseringsuppgifter vid autentiseringstillfället.
• Plan för algoritmmigrering: Utforma ditt system så att det hashar inloggningsuppgifterna vid nästa inloggning. Detta låter dig uppgradera algoritmer eller parametrar utan att tvinga fram en massåterställning av lösenord.

Hur krypteringskonsulting kan hjälpa

Att få lösenordslagring rätt är ett beslut gällande kryptografiskt implementering, och liksom de flesta kryptografiska beslut är det lätt att göra fel på sätt som inte är omedelbart synliga. Fel algoritm, ett saknat salt, ett otillräckligt antal iterationer eller en FIPS-inkompatibel implementering kan alla se bra ut på ytan samtidigt som de i tysthet utsätter din organisation för allvarliga risker. Det är där Encryption Consultings krypteringsrådgivningstjänster kommer in i bilden.

Vårt team hjälper organisationer att utvärdera och stärka sina kryptografiska implementeringar i moln-, lokala och hybridmiljöer. Oavsett om ni bygger ett nytt autentiseringssystem, granskar ett befintligt eller förbereder er för en efterlevnadsrevision enligt PCI-DSS, NIST SP 800-63B eller GDPR, har vi djupet för att utvärdera vad som faktiskt finns på plats och den praktiska erfarenheten för att hjälpa er att åtgärda det som inte står rätt till.

Här är vad våra krypteringsrådgivningstjänster gäller direkt för lösenordslagring och autentiseringssäkerhet:

Granskning av kryptografisk implementering: Vi utvärderar er nuvarande implementering av lösenordslagring, inklusive algoritmval, saltningsrutiner, parameterjustering och hur autentiseringsuppgifter separeras och åtkomstkontrolleras. Detta ger er en tydlig bild av var luckorna finns innan ett intrång eller en granskning avslöjar dem.

Algoritmval och migreringsplanering: Att gå från bcrypt till Argon2id, eller från en äldre PBKDF2-implementering till en som uppfyller nuvarande NIST-rekommendationer för iterationsantal, kräver noggrann planering för att undvika att befintliga autentiseringsflöden bryts. Vi utformar migreringsvägar som successivt omhashar inloggningsuppgifterna vid nästa inloggning, utan tvingande lösenordsåterställningar och utan avbrott i användarupplevelsen.

FIPS-efterlevnadsanpassning: För organisationer som verkar i federala eller reglerade finansiella miljöer där FIPS 140-2- eller 140-3-validering krävs, hjälper vi er att välja och konfigurera PBKDF2-implementeringar som uppfyller efterlevnadskraven samtidigt som vi kompenserar för algoritmens svagare hårdvaruresistans genom korrekt parameterkonfiguration.

Analys av efterlevnadsgap: Ramverk som PCI-DSS, GDPR och NIST SP 800-63B har alla förväntningar kring hur autentiseringsdata skyddas. Vi kartlägger er nuvarande implementering mot dessa krav, identifierar luckor och tar fram en tydlig åtgärdsplan.

Dålig lösenordslagring är ett av de vanligaste och mest undvikbara säkerhetsproblemen. Om din organisation inte formellt har granskat sina rutiner för hantering av inloggningsuppgifter är det nu rätt tidpunkt.

Slutsats

Lösenordslagring är inte ett glamoröst ämne, men det är grundläggande. De val som görs på datalagret avgör om ett intrång blir en begränsad incident eller ett mycket större problem. Varje annan säkerhetskontroll i en applikation beror i slutändan på hur inloggningsuppgifter lagras, och med tanke på hur ofta folk återanvänder lösenord sträcker sig skadan från en svag implementering ofta långt bortom den ursprungliga applikationen.

Det som gör detta område knepigt är att konsekvenserna sällan är synliga förrän något går fel. Ett svagt hashval varken saktar ner prestandan eller utlöser varningar. Det ligger tyst i produktion tills ett intrång inträffar och angripare börjar knäcka de lagrade hasherna. Den goda nyheten är att vägledningen här inte är tvetydig. NIST har publicerat tydliga rekommendationer, och det finns mogna bibliotek i alla större språk för att implementera dessa algoritmer korrekt.

Vägen framåt är tydlig. Använd Argon2id för nya implementeringar. Underhåll bcrypt ansvarsfullt för äldre system med en kostnadsfaktor på minst 12. Använd PBKDF2 endast när efterlevnad kräver det, och kompensera med ett högt iterationsantal. Salta alltid, justera alltid dina parametrar och planera för framtida algoritmmigreringar från början. Betrakta detta som en pågående praxis, inte en engångsinstallation.