Garanti's hjelpetråd til PHP

[Garanti]

Sikrere med forskjellige salt? Selvsagt, men ikke når du lagrer det sammen med passordet!

Hvordan mener du at man skal lagre unike salt da? Det må jo fortsatt lagres i en databasetabell?

[OISNOT]

Det å lagre saltet sammen med passord har jeg aldri sett før nå, av den enkle grunn - det er ingen som gjør det!

Prøv google.

 

http://www.matasano.com/log/958/enough-wit...ssword-schemes/

 

http://en.wikipedia.org/wiki/Shadow_password

http://en.wikipedia.org/wiki/Password_salting

http://en.wikipedia.org/wiki/Password_cracking#Salting

 

Det er mer enn sikkert nok å lagre salt med passordet. Men jo lengre salt jo bedre.

 

Da er det enklere for de som vil ha tilgang å bruke social engineering, bryte seg inn fysisk og stikke av med harddiskene, XXS, få kontroll over web serveren og logge alle passord som kommer inn via siden, få kontroll over en brukers PC og logge internett tilkoblingen, etc.

[OISNOT]

Hvordan mener du at man skal lagre unike salt da? Det må jo fortsatt lagres i en databasetabell?

Han mener det skal lagres på web serveren. Den er jo også sårbar, spesielt hvis du har hostingservice på en delt server.

Som eg sier: det beste er begge, men eg foretrekker ett salt per bruker over ett salt for alle. Og hashe minst 2 ganger.

 

(Ett langt salt er bedre bare fordi det er "raskere" å lage en database over de korte saltene, fordi det er færre muligheter. Tar fremdeles LANG tid og MYE plass. Spesielt med FLERE hasher og gjerne ULIKE hasher.)

Endret 9. oktober 2008 av OISNOT

[Garanti]

Ok. Jeg må bare uttrykke min undring ovenfor denne 'avslørelsen', da de tutorialene jeg har fulgt, nettopp lagrer passord og salt side om side.

 

 

Og hashe minst 2 ganger.

 

Dobbelthashing, i alle fall med samme algoritme, skal visstnok ikke gi økt sikkerhet

[Jonas]

Poenget med å salte er å forhindre bruk av f.eks. rainbowtables og bruteforcing, da rainbowtables blir fullstendig ubrukelige, mens bruteforcing tar lengre tid. Dersom saltet er kjent er rainbowtables fortsatt rimelig ubrukelige, mens bruteforcing på den andre siden tar like lang tid som om man ikke skulle ha hatt saltet passordet i første omgang.

 

Eks.

 

MD5(passord + salt) (Hvor passordet er f.eks. abc)

 

Skal man bruteforce, så leter man faktisk etter passord + salt, noe som forhåpentligvis er utrolig langt og tidkrevende. Dersom jeg allerede vet saltet, så er man like langt. Hvor lang tid tar det å bruteforce f.eks. abc?

 

MD5(force til abc + salt)

 

Hvis du absolutt vil ha unike salt per bruker, gud vet hvorfor, så kan du i det minste lagre de noe separat, f.eks. i forskjellige databaser, med forskjellige passord.

Endret 9. oktober 2008 av Jonas

[OISNOT]

Ok. Jeg må bare uttrykke min undring ovenfor denne 'avslørelsen', da de tutorialene jeg har fulgt, nettopp lagrer passord og salt side om side.

 

 

Og hashe minst 2 ganger.

 

Dobbelthashing, i alle fall med samme algoritme, skal visstnok ikke gi økt sikkerhet

Det gir iallefall ikke dårligere sikkerhet.

Hvis angriperen vet formelen du bruker så hjelper det ikke dersom de skal generere passorddatabasen (rainbow) på nytt. Men dersom de har en ferdig database så hjelper det.

 

Med lange salt og bra hash algoritme så er det trygt nok. Men tror ikke det skader å hashe en gang til, gjerne med en annen algoritme.

 

For de paranoide: hash1(application_salt + hash2(user_password + user_salt))

Endret 9. oktober 2008 av OISNOT

[OISNOT]

Poenget med å salte er å forhindre bruk av f.eks. rainbowtables og bruteforcing, da rainbowtables blir fullstendig ubrukelige, mens bruteforcing tar lengre tid. Dersom saltet er kjent er rainbowtables fortsatt rimelig ubrukelige, mens bruteforcing på den andre siden tar like lang tid som om man ikke skulle ha hatt saltet passordet i første omgang.

 

Eks.

 

MD5(passord + salt) (Hvor passordet er f.eks. abc)

 

Skal man bruteforce, så leter man faktisk etter passord + salt, noe som forhåpentligvis er utrolig langt og tidkrevende. Dersom jeg allerede vet saltet, så er man like langt. Hvor lang tid tar det å bruteforce f.eks. abc?

 

MD5(force til abc + salt)

 

Hvis du absolutt vil ha unike salt per bruker, gud vet hvorfor, så kan du i det minste lagre de noe separat, f.eks. i forskjellige databaser, med forskjellige passord.

Det spørs jo kor de starter, og om de vet kordan du hasher passordet.

Kor lang tid tror du det tar å finne frem til passordet på følgende?

saltet passord <4cdf51f91f85a2da2fd169bc3b7ff8bf1d76ef4e> og salt <sdfbgfdgdr3wq3s>

Finner de frem til den funksjonen så finner de også frem til applikasjonssaltet ditt.

 

Samtidig er det lurt å ikke la brukerne registrere passord fra hackernes første forsøk i brute force angrep, listen over de mest vanlige passordene.

[Jonas]

Hva er vitsen med salting dersom saltet er kjent? Det eneste som er uvisst for en som har fått tilgang til databasen er metoden, men for å lage en rar og "sikker" (security through obscurity) metode trenger man ikke salting. Hvor ble poenget med salting av da?

 

Hva tror du tar lenger tid å bruteforce av

 

1. SHA1(MD5(password) + SHA1(password))

2. SHA1(MD5(password + salt) + SHA1(password + salt) + salt)

 

Svaret er at dersom saltet er kjent, så er det ingen forskjell. Det tar like lang tid å bruteforce.

Endret 9. oktober 2008 av Jonas

[Garanti]

Hvordan skal jeg få tak i en (statisk?) mappebane som jeg kan bruke til å definere mappekonstanter i skriptene mine? Tenker da f.eks på en konstant CLASS_PATH som kan peke til mappen med klassene mine.

[Garanti]

Bump, ingen som kan hjelpe? MAn bruker da slike konstanter i ulike systemer?

Endret 4. november 2008 av Garanti

[Jonas]

Uh, lurer du på hvordan man definerer konstanter? define() er isåfall svaret.

 

Edit: Før du lager en slik klassesti, ta en titt på __autoload, så slipper du å surre med filbaner for alltid!

Endret 4. november 2008 av Jonas

[Garanti]

Neinei, ikke det jeg mener, tror jeg..

Sett at man har et php-dokument begravd dypt inne i haug mapper på en webserver, og man f.eks har behov for å inkludere en klasse som ligger under \classes\img\. Da er det vel noe upraktisk å skrive inn include('..\..\..\..\classes\img\img.php') fremfor include($Root . '\classes\img\img.php')

[Gjest Slettet+6132]

define('ROOT', '/www/example.com/htdocs/myscript/');

include(ROOT . 'classes/img/img.php');

 

?

[itsmebth]

Du kan også bruke set_include_path.