Så skyddar vi dina lösenord

I tidigare artiklar har vi utforskat hur HTTPS skyddar vägen mellan din app och vår server, och hur SSH säkrar själva servern. Nu är det dags att titta in i servern – hur Splync skyddar ditt lösenord när det väl är där. Om någon skulle få tag på ditt lösenord kan den personen logga in på ditt konto och få tillgång till känslig information, inklusive dina utgiftsuppgifter. Därför lagrar Splync aldrig lösenord i klartext. Istället omvandlas varje lösenord till en hashad version innan det sparas i databasen. Vad betyder det egentligen? Hashning är en envägsomvandling – när det väl har omvandlats kan det aldrig återställas till det ursprungliga lösenordet. Denna metod är standard på internet, från banker till stora molntjänster, men många vet inte hur det egentligen fungerar. Låt oss utforska det genom en enkel vardagsanalogi.

För att förstå hur lösenordsskydd fungerar, låt oss börja med en enkel hashmetod som kallas SHA-256. Tänk på det som en mixer som alltid blandar ingredienser på exakt samma sätt. Om du lägger i samma lösenord i mixern och trycker på knappen, får du alltid samma unika smoothie – en blandning av bokstäver och siffror. Huvudidén är att processen inte kan vändas. Precis som du inte kan ta en smoothie och separera den tillbaka till den ursprungliga bananen och mjölken, kan du inte ta den skramlade hash och återställa det ursprungliga lösenordet.

SHA-256 är en av de vanligaste hashalgoritmerna. Till exempel, det hashar lösenordet "splync1234" till “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. På millisekunder, varje gång en befintlig användare anger ett inloggningslösenord, ger SHA-256 alltid samma hashade lösenord. Appen hashar helt enkelt det angivna lösenordet igen och kontrollerar om det stämmer överens med den lagrade hash. Systemet känner aldrig till användarens ursprungliga lösenord. Men vad händer om en angripare förbereder en lista över vanliga lösenord och deras hash (kallas en regnbågstabellattack) för att snabbt gissa användarnas lösenord? Den oron är mycket verklig. Det är därför moderna system, inklusive Splync, inte förlitar sig på vanlig SHA-256.

Bcrypt använder ett slumpmässigt per-användar salt och kodar det saltet (och kostnadsfaktorn) direkt i den lagrade hashsträngen. Tänk på bcrypt som en mixer med en hemlig krydda (salt) och en långsam motor (arbetsfaktor) – det gör varje blandning unik och svårare att kopiera. Eftersom saltet är 128 bitar (≈3×10³⁸ möjligheter) kan samma lösenord mappas till ett astronomiskt stort antal olika lagrade hash. Det gör förbereder regnbågstabeller oanvändbara i stor skala. Under inloggning läser Splync salt och kostnad från den sparade bcrypt-strängen, kör om bcrypt på det angivna lösenordet med dessa parametrar och jämför resultatet med den lagrade hash. Om de matchar är lösenordet korrekt – men eftersom bcrypt är avsiktligt långsam och salter är unika, blir brute-force-attacker mycket dyrare för en angripare.

Låt oss se hur detta ser ut i praktiken. Om du hashar lösenordet "splync1234" med bcrypt (med kostnad 12), kan du få en sträng som denna: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. I denna bcrypt-sträng markerar `$2b` algoritmversionen, `$12` visar kostnadsfaktorn (hur många gånger lösenordet bearbetas), `gBeouKYdue9uvvuV0HtGgeV` är det unika slumpmässiga saltet, och `PymnrojMqP/wcRw28HFlGEGIQbyw7O` är det slutliga hashade lösenordet. Eftersom hash själv innehåller saltet och kostnaden, kan Splync återskapa samma hashprocess för verifiering genom att extrahera dessa värden från den lagrade strängen och jämföra resultatet. Å andra sidan, om en angripare inte känner till saltet och kostnaden, kan de inte bygga en enda regnbågstabell som fungerar för varje användare.

Detta tillvägagångssätt har ytterligare en viktig fördel. Eftersom Splync aldrig lagrar lösenord i klartext, är användarna inte omedelbart i riskzonen även om databasen skulle läcka eller bli stulen. Angripare kan inte logga in direkt med de stulna uppgifterna, eftersom det de har bara är skramlade strängar. Denna design ger användarna ett extra skyddslager, utöver de skydd som redan finns kring själva servern. Lösenordshashning är inte unikt för Splync; det är standard i teknikindustrin, används av giganter som Google, Apple och Amazon. Splync har byggts mycket säkert, och det kommer bara att bli säkrare när vi fortsätter att förbättra säkerheten med funktioner som e-postverifiering, skydd mot brute-force och kontinuerlig övervakning.