Hvordan vi beskytter dine adgangskoder

I de tidligere artikler udforskede vi, hvordan HTTPS beskytter ruten mellem din app og vores server, og hvordan SSH sikrer selve serveren. Nu er det tid til at se nærmere på serveren - på hvordan Splync holder din adgangskode sikker, når den er ankommet dertil. Hvis nogen fik fat i din adgangskode, kunne de logge ind på din konto og få adgang til følsomme oplysninger, inklusive dine udgiftsoptegnelser. Derfor gemmer Splync aldrig adgangskoder som almindelig tekst. I stedet bliver hver adgangskode omdannet til en hash-version, før den gemmes i databasen. Hvad betyder det præcist? Hashing er en envejs-konvertering - når den først er omdannet, kan den aldrig blive til den oprindelige adgangskode igen. Denne metode er standard over hele internettet, fra banker til store cloud-tjenester, men mange ved ikke, hvordan det egentlig fungerer. Lad os udforske det gennem en simpel hverdagsanalog.

For at forstå, hvordan adgangskodebeskyttelse virker, lad os starte med en simpel hashingmetode kaldet SHA-256. Tænk på det som en blender, der altid blander ingredienserne på præcis samme måde. Hvis du putter den samme adgangskode i blenderen og trykker på knappen, får du altid den samme unikke smoothie - en sammenblanding af bogstaver og tal. Den vigtigste idé er, at processen ikke kan vendes. Ligesom du ikke kan tage en smoothie og adskille den tilbage til den oprindelige banan og mælk, kan du ikke tage den sammenblandede hash og genskabe den oprindelige adgangskode.

SHA-256 er en af de mest almindelige hashingalgoritmer. For eksempel hasher den adgangskoden "splync1234" til “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. På få millisekunder, hver gang en eksisterende bruger indtaster en login-adgangskode, producerer SHA-256 altid den samme hash-adgangskode. Appen hasher bare den indtastede adgangskode igen og tjekker, om den matcher den gemte hash. Systemet kender på intet tidspunkt brugerens oprindelige adgangskode. Men hvad nu hvis en angriber forudberegner en liste over almindelige adgangskoder og deres hashes (kendt som et rainbow table-angreb) for hurtigt at gætte brugernes adgangskoder? Denne bekymring er meget reel. Det er derfor, moderne systemer, inklusive Splync, ikke stoler på almindelig SHA-256.

Bcrypt bruger en tilfældig bruger-specifik salt og koder den salt (og omkostningsfaktoren) direkte i den gemte hash-streng. Tænk på bcrypt som en blender med en hemmelig krydderi (salt) og en langsom motor (arbejdsfaktor) - det gør hver blanding unik og sværere at kopiere. Fordi salten er 128 bits (≈3×10³⁸ muligheder), kan den samme adgangskode kortlægge til et astronomisk stort antal forskellige gemte hashes. Det gør forudberegnede rainbow tables ubrugelige i stor skala. Under login læser Splync salten og omkostningen fra den gemte bcrypt-streng, kører bcrypt igen på den indtastede adgangskode med disse parametre og sammenligner resultatet med den gemte hash. Hvis de matcher, er adgangskoden korrekt - men fordi bcrypt er bevidst langsom og salte er unikke, bliver brute-force-angreb langt dyrere for en angriber.

Lad os se, hvordan dette ser ud i praksis. Hvis du hasher adgangskoden "splync1234" med bcrypt (med omkostning 12), kan du få en streng som denne: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. I denne bcrypt-streng markerer `$2b` algoritmeversionen, `$12` viser omkostningsfaktoren (hvor mange gange adgangskoden behandles), `gBeouKYdue9uvvuV0HtGgeV` er den unikke tilfældige salt, og `PymnrojMqP/wcRw28HFlGEGIQbyw7O` er den endelige hash-adgangskode. Fordi hashen selv indeholder salten og omkostningen, kan Splync reproducere den samme hashing-proces til verifikation ved at udtrække disse værdier fra den gemte streng og sammenligne resultatet. På den anden side, hvis en angriber ikke kender salten og omkostningen, kan de ikke bygge et enkelt rainbow table, der virker for alle brugere.

Denne tilgang har en anden vigtig fordel. Fordi Splync aldrig gemmer almindelige adgangskoder, er brugerne ikke straks i fare, selv hvis databasen blev lækket eller stjålet. Angribere kan ikke logge direkte ind med de stjålne data, fordi det, de har, kun er sammenblandede strenge. Dette design giver brugerne et ekstra lag af beskyttelse, oven på de foranstaltninger, der allerede eksisterer omkring selve serveren. Hashing af adgangskoder er ikke unikt for Splync; det er standard i hele teknologiindustrien, brugt af giganter som Google, Apple og Amazon. Splync er bygget meget sikkert, og det bliver kun mere sikkert, efterhånden som vi fortsætter med at forbedre sikkerheden med funktioner som e-mail-verifikation, brute-force-beskyttelse og løbende overvågning.