Hvordan lagrer nettverk passordene dine og annen påloggingsinformasjon?

For år siden var det vanskelig å knekke tilfeldige passord på åtte tegn bestående av store og små bokstaver, symboler og tall. I noen tilfeller tok det år å knekke et slikt passord.

Takket være dagens skiftende teknologi og utleiebare maskiner er denne tiden redusert til timer. Men hvordan lagres disse passordene i utgangspunktet?

Hvordan passord lagres på nettet

Systemer lagrer ikke brukerpassord direkte i filer eller databaser, fordi angripere kan ta over databasen der systemene oppbevarer passordene. I stedet krypterer systemer brukerpassord, og angripere møter en kryptert versjon av hvert passord.

Det er noen algoritmer som systemer bruker for å kryptere passord. En av disse algoritmene er den symmetriske algoritmen. Den symmetriske algoritmen er en type kryptering hvor du kan bruke samme nøkkel for både kryptering og dekryptering. Nøkkelen du skal bruke til å kryptere dataene er den samme for både kryptering og dekryptering. Sikkerheten til symmetriske algoritmer medfører noen risiko siden det bare er én nøkkel for dekryptering. Av denne grunn bruker ikke systemer generelt symmetriske algoritmer for passordkryptering.

Vanligvis er metoden som systemene bruker for kryptering hash-algoritmer. Hash-algoritmer er for å verifisere og representere integriteten til data, ikke for å kryptere data. Hash-algoritmer konverterer data til en hash med fast størrelse. Disse hashene representerer vanligvis en unik hash av data.

Takket være hash-algoritmen, hvis en angriper har tatt over passorddatabasen, kan angriperen ikke få tilgang til passordet bakover herfra. Det er en veldig viktig nyanse som du bør være oppmerksom på her. Teoretisk sett kan en angriper som kompromitterer et system som bruker samme hash-algoritme for alle passordkombinasjoner sammenligne resultatene som er oppnådd. Hvis angriperen produserer samme verdi som et resultat av disse sammenligningene, har angriperen funnet ut hva den åpne versjonen av passordet er. Denne metoden handler om prøving og feiling, og denne formen for angrep er det vanligvis kalt et brute force angrep.

På begynnelsen av 2000-tallet kunne det ta hundrevis av år å prøve alle kombinasjoner for 8-tegns passord kryptert med populære hashing-algoritmer. Selvfølgelig inkluderer dette ikke veldig enkle kombinasjoner som "123456" eller "mittpassord" i dette settet. Med utviklingen av dagens programvare- og maskinvareteknologier har også metoden for å knekke passord endret seg mye.

Effekten av nye GPUer

Parallelle databehandlingsevner til grafikkprosessorer (GPUer) har forbedret seg over tid. GPUer er ikke i stand til å utføre allsidige operasjoner som generelle CPUer. Så selv om det finnes så mange kjerner og parallell prosessorkraft, er det ikke fornuftig å bruke dem for nesten alle problemer som PROSESSOR.

Likevel er det mulig å utføre noen hash-algoritmer som brukes for passord ganske effektivt på GPU. De beregningsbare hashene per sekund du kan oppnå med tradisjonelle CPUer har vokst enormt med nye GPU-plattformer.

For å få en ide, undersøk hashing-tallene per sekund for hash-algoritmer som NTLM, MD5 og SHA1 i tabellen nedenfor. Det er nok foreløpig å vite at disse algoritmene bare er en hash-algoritme. For å lage denne tabellen brukte jeg et klyngesystem bestående av 25 AMD Radeon GPUer.

Som du kan se, med et slikt system kan du generere NTLM-hasher 350 milliarder ganger per sekund. Dette betyr at du kan prøve alle kombinasjoner av et 8-tegns passord på mindre enn 6 timer. Dessuten tilhører maskinvaren i dette eksemplet for mange år siden. Tenk deg dagens passord-knekkingskraft.

Hva bør programvareutviklere gjøre?

Måten programmerere bør gå på er ganske enkel: de bør foretrekke algoritmer som tar lengre tid å beregne hash-verdier når de krypterer passord. Utviklere må lære ikke bare om ytelsen til algoritmen de bruker på CPU-en, men også om hvor motstandsdyktig den er mot GPU-verdenen.

Hvis utviklere jobber med et programvarerammeverk som også adresserer passordkrypteringsprosesser som Django, Ruby on Rails, og Spring Security bør de sjekke om det er tatt riktige avgjørelser innenfor rammene mht sikkerhet.

For eksempel, Devise, et av de mest brukte bibliotekene for brukeroperasjoner i Ruby on Rails, bruker Bcrypt som standard hash-algoritme. Den lar deg også bruke en annen metode som hash-algoritmen. Bcrypt-algoritmen er pålitelig da det fortsatt tar veldig lang tid før GPU-en går i stykker.

Oppsummert, jo lengre tid hashverdiberegningen tar, jo sikrere er du.

Hvor mange tegn bør passordet ditt ha?

Hvert ekstra tegn du bruker vil geometrisk øke antallet forsøk og feil som trengs for å knekke passordet ditt og gjøre passordet ditt sikrere.

La oss vurdere denne situasjonen gjennom to forskjellige scenarier. Tenk på verdiene i tabellen ovenfor for NTLM-hash-algoritmen og forestill deg at du vil prøve å knekke passordet. Tenk deg målretting av passord på åtte tegn eller mer.

Når du undersøker tabellen, kan du se at bruk av et passord på minimum 12 tegn er trygt når du bruker alle kombinasjoner av store/små bokstaver, tall og spesialsymboler. Hvis du ikke bruker spesielle symboler, viser det seg at du må bruke 13 tegn som sikker passordlengde. Hvis du brukte Bcrypt-hash-metoden i stedet for NTLM-hash i dette systemet, ville 8 tegn være nok. Du har imidlertid ikke mulighet til å vite med hvilken hashmetode et system du går inn på over nettet beholder passordet ditt. Derfor bør du vurdere alle muligheter.

Hovedproblemet for programvareutviklere er at det er nesten umulig å overbevise brukere om å ha et passord på minimum 12 tegn. I dag er det mulig å si at frekvensen av passordbruk av denne lengden er lav. Derfor, i henhold til bruksscenarioet til det utviklede systemet, vil det være nødvendig å finne en mellomting som vil bli akseptert av brukerne for å forbedre passordsikkerheten deres.

et siste forslag til utviklere er å sjekke ikke bare minimumslengden, men også den maksimale lengden på inngangene som kommer gjennom skjemaene du har presentert for brukeren. Spesielt når du aktiverer bruk av en hash-algoritme som kan beregnes sakte, slik som Bcrypt for sikkerhet formål, kan du støte på noen risikoer hvis du ikke kontrollerer maksimal lengde på passordet som angis av brukeren. For eksempel kan angripere utføre angrep ved å prøve dusinvis av passord på 100 tusen tegn samtidig med noen spesielt forberedte forespørsler. I et slikt tilfelle er det høyst sannsynlig at systemet ditt ikke reagerer på andre brukere.

Råd til sluttbrukere

Gjør passordlengden på minst 12 tegn, og sørg for å inkludere kombinasjoner av store og små bokstaver, tall og symboler. Glem aldri at systemene som lagrer passordet ditt kan bli hacket, og informasjonen din kan misbrukes. Du kan ikke vite hvilke algoritmer et system bruker for å kryptere passordet ditt, så det er helt opp til deg å ta forholdsregler og lage sterke passord.