Salt til passord

[kongen]

Hva er den beste måten å generer random salt til passord?

 

[adeneo]

Norsk Webforum ? Se emne - Sikkerhet på passord

 

[TorsteinO]

Veldig bra innlegg du lenka til der adeneo!

 

[kongen]

Er noen av disse godkjente som salt?

bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
base64_encode(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
uniqid(openssl_random_pseudo_bytes(32);

 

[adeneo]

Du kan bruke hva som helst som salt, og saltet er egentlig ikke super hemmelig (bare litt), men å generere en passe lang tilfeldig streng som er unik for hvert passord er det beste.

Med andre ord, alle de der holder, og 32 bytes er mer enn langt nok, målet er ikke å lage noe superlangt og vanskelig, men noe unikt som gjør det umulig å generere passordene med regnbue tabeller, og selv 8 bytes med salt kjørt mot 128 bits kryptering bør gi noe sånt som 922337203685477 muligheter, men det heter seg at "bits is cheap" når man krypterer, slik at 32 bytes, eller for den saks skyld 64 bytes eller mer per passord er egentlig ingenting når det kommer til å lagre og hente i databasen.

 

[Tetto]

Dette er kanskje et dumt spørsmål, men det spiller vel ingen rolle hvordan passordet er kryptert så lenge hackeren prøver å logge inn fra innloggingssiden? Kan man ikke sette en grense for antall spørringer?

 

[adeneo]

Kan man ikke sette en grense for antall spørringer?

Det kan man selvfølgelig, og det er en god ide.

Nå er det jo slik at det er vanskelig å gjette seg til passord helt på måfå, de fleste bruker systemer til dette, men det er fortsatt nesten umulig å treffe, og det er sjeldent noen gidder å sitte og prøve passord i en evighet.

Det vanligste er nok ikke at noen sitter og gjetter noen millioner passord til de finner ett som virker, det vanligste er at noen får tilgang til databasen for eksempel.

Dersom man lagrer passordet direkte i databasen, så er løpet kjørt hvis noen klarer å finne en åpning, men dersom man lagrer kun hashen, så er det vanskelig å regne seg tilbake til det egentlige passordet, og det er jo det egentlige passordet som må skrives inn for å få tilgang til nettsiden, ikke hashen, den virker ikke i passordfeltet.
Derfor lagrer man kun hashen, og aldri passordet.

Så er det slik at selv gode algoritmer kan knekkes relativt raskt i dag, og knekker man et par av hashene så kan man regne seg frem til resten, og så har man alle passordene.

En unik salt gjør det uendelig mye vanskeligere å regne seg frem til passordene fra hashen, og ettersom hver hash har sitt eget salt så kan man heller ikke bruke resultatet fra et par hasher til å finne løsningen på resten, de er alle forskjellige, mens ting som SHA256 er kjente algoritmer som kan reverseres dersom man gidder.

Dette er den største sikkerhetsfordelen ved å salte hashen (høres fint ut, salte hasjen), og det gjør at regnbuetabeller og den slags plutselig ikke er særlig effektivt lengre. Samtidig så er en salt et ekstra lag med unik kompleksitet som man må gjennom, slik at det øker sikkerheten i nesten alle tilfeller svært mye.

En annen ting som er blitt mer vanlig er å bruke krypteringer som tar en angitt mengde tid.
Dagens datamaskiner er så raske at en vanlig PC relativt raskt kan teste en hash mot milliarder av muligheter, men algoritmer som tar en angitt mengde med tid vil gjøre det vanskelig.
Om det tar noen millisekunder å sjekke ett enkelt passord opp mot en hash og salt på en nettside, så spiller det ingen rolle, men noen millisekunder kan bety mye når noen prøver å sjekke milliarder av muligheter, og plutselig tar det måneder i stedet for timer å kjøre en slik test.

Mye greier ?

 

[Tetto]

Mye greier ?

Ja! Men dette var ganske oppklarende. Takk!

I praksis skal man altså bruke det selvalgte passordet pluss en tilfeldig string og lage en hash ut av det. Hash(passord + tilfeldig_string). Så må den tilfeldige stingen ha et eget felt i databasen, f.eks. til høyre for hash-passordet. Når en bruker prøver å logge inn må man sjekke om hashen til det innskrevne passordet pluss den lagrede stringen er lik det lagrede hash-passordet. Stemmer ikke det?

I så fall er den tilfeldige stringen lett å få tak i om man først har fått tilgang til hash-passordet. En ting er at man jo er temmelig føkd uansett om noen får tilgang til databasen (Da greier de vel også å endre og slette ting) så første prioritet bør jo være å hindre dette. Men blir det ikke lettere for hackeren å finne ut av hash-algoritmen når han allerede vet hva den tilfeldige stringen er?

 

[xdex]

Oh well, ikke heng dere for mye oppi alt saltet.

It’s important to note that salts are useless for preventing dictionary attacks or brute force attacks. You can use huge salts or many salts or hand-harvested, shade-grown, organic Himalayan pink salt. It doesn’t affect how fast an attacker can try a candidate password, given the hash and the salt from your database.

Det viktigste med salt, er at man ikke skal kunne få to like hash (evt. søke opp en hash i en database full av ordlister). Det er normalt å bruke en fast random string, dynamisk string (brukernavn f.eks) og passord.

F.eks sha1 [ "xUHw/16"^dJxMM____!!øæå" + "passord" + "brukernavn/annet"]

A modern server can calculate the MD5 hash of about 330MB every second. If your users have passwords which are lowercase, alphanumeric, and 6 characters long, you can try every single possible password of that size in around 40 seconds.

And that’s without investing anything.

If you’re willing to spend about 2,000 USD and a week or two picking up CUDA, you can put together your own little supercomputer cluster which will let you try around 700,000,000 passwords a second. And that rate you’ll be cracking those passwords at the rate of more than one per second.

Ta også en titt på: PHP: hash_pbkdf2 - Manual dersom PHP versjonen din støtter det, evt. ta en titt på bcrypt.