Men... men... tenk om de Rainbow Tabler det to ganger, da?
Eller du kan bare bruke SHA1 som PHP og muligens (hvis jeg husker riktig) MySQL har innebygd støtte for.

Ja, det går godt an å gjøre det slik. En vanlig greie å gjøre er å bruke et salt når det genereres hasher. På denne måten er du ikke kun avhengig av én funksjon, men funksjon og salt.

Med tanke på bruteforce og rainbow tables har det lite å si om du har flere hasher eller ikke. Gå ut ifra denne koden:
Passordet blir definert med $_POST['password'], så antall hasher har absolutt ingen ting å si. Treffer du riktig passord vil du bli logget inn uansett.

Om databasen skulle komme på avveie slik at en inntrenger sitter med alle passordene, så er det mulig du gjør jobben vanskligere for h*n om du har benyttet mange stadier med hashing. Jeg er ikke helt sikker her, men hashen må nok bruteforces for hver level med hash du har brukt. Når det er sagt er jeg sikker på at jeg har lest på et annet forum at det er totalt unødvendig å bruke flere hasher fordi det ikke gjør passordet sikrere, men klarer ikke å finne igjen innlegget nå. Mulig det er noen andre her som kan forklare dette bedre enn meg.

Er dette godt nok?

Så det enkelte mener er at md5 er "knukket" ved at det er mulig å brute-force seg frem til to like hasher?

Ja. Når søkerommet er redusert nok til at bruteforcing er mulig over maks noen dager så er algoritmen praktisk talt knukket. Ikke at det har så mye å si for hjemmesnekra PHP-autentisering i praksis, men "sha1()" er bare en bokstav mer enn "md5()", så hvorfor ikke bruke det istedet.

Og er du ekstremt, ekstremt paranoid har du http://no2.php.net/manual/en/function.hash.php - sha512 burde holde en liten stund ihvertfall.

Vil det ikke også være lurt, for å hindre BF, at man legger inn at man max kan ha X antall forsøk før man blir ip-banned (o.l) i XX antall minutter?

Samme har jeg kommet fram til med bruteforcing. La oss si fem forsøk, så fem minutter. Deretter fem forsøk, 15 minutter, tre forsøk, 30 minutter. En simpel algoritme for å øke tidsrommet, og senke antall forsøk. Antageligvis mest hensiktsmessig til en viss grense.

Jeg antar at man kan basere antall tillatte autentiseringsforsøk på cookies også? I tillegg til IP-adresse. Og kreve statisk IP for en liten periode. Dette vil gjøre bruteforcing meget tidkrevende, men gjør antageligvis at angrepet blir ledet i en annen retning, nemlig finne passordhashene.

Mente dette som et tillegg til IP. Spørs vel hvilken sessiontype man bruker også. Session cookies som eksempel, men skal ikke skryte på meg nok kunnskap om emnet.

Så hvis du hasher passordet i både SHA1 og MD5 så skal det være ganske trygt?

Bør vel det. Men salt er viktig.

Ja, hvis du hasher passordet sammen med saltet i SHA1 og MD5 så skal det være trygt nok?

En liten avsporing her, men siden det er mange her som tydeligvis kan en del om kryptering så skyter je ut følgende spørsmål.

hvorfor er ikke md5 reverserbart ? Jeg antar at "formelen" for å kyptere med md5 er allment kjent siden det er bred støtte for denne krypteringen.

Og når man så vet hva som skal til for å lage en slik hash, hvorfor ikke bare reversere regnestykket? (vet at det sikkert er veldig godt svar på det, ellers så ville jo ikke md5 vært like "sikkert" fortsatt)

Fordi MD5 ikke er kryptering.

Ok, så jeg ordla meg feil. Spørsmålet mitt gjelder fortsatt.

Eller.. Når jeg tenker meg om så lar det seg vel ikke gjøre å reverse dette av den enkle grunn at man ikke vet lengden på input strengen. md5("a") gir like lang hash som md5("abcdefghijklmnopqrstuvwxyzæøå")

Trenger ikke kunne noe krypto for å svare på det
Dette går heller under grunnleggende funksjonslære. Hvis vi har en funksjon f(x)=y så kan vi bare finne en invers funksjon f^-1(y)=x dersom f(x) er injektiv (en-til-en).

Hash-funksjoner er mange-til-en, og det finnes derfor ingen invers til disse. Kort sagt: ikke alle regnestykker kan reversers

Jeg skjønner ikke helt tankegangen til folk. Du kan lage så mange hasher ut av passordet og du vil uansett være like utsatt for et brute-force angrep. Sikkerheten må ha sviktet i ganske mange ledd før databasen din er på avveie og noen faktisk sitter på alle hashene. Det finnes ganske enkelt mange andre steder hvor du bør legge inn tid og krefter på å gjøre det sikkert.

Har man tilgang til databasen, er det jo forsåvidt bare å legge inn sin egen bruker + kjent hash med de rettighetene man ønsker.

PHP er også et språk som er lett å lære, men mange utviklere tar ikke sikkerheten på alvor (les: liten/ingen kunnskap om emnet) og det er dermed duket for sql injection og andre godsaker :-)

Må meg nesten si meg enig med Deezire her.. BF vil nok være mer aktuelt å stoppe på brukersiden, enn DB siden.
Har en person kommet seg inn i DB'n så er det meste kjørt uansett.

Nå vil jo dette variere litt på hvilket brukersystem det er snakk om ifra TS... Men uansett så er det jo snakk om en passord-login, og da må man jo uansett skrive ett passord inn.. og ikke en hash verdi av passordet...

Er passordet 123, så skriver man jo inn 123 i innloggingsfeltet, og ikke hash-verdien av passordet.

Så vil nok være mer sikkert å satse på en god BF sperre som regger IP og evt kjeks, og så gir pause på 15-30 min etter 5-6 misslykket forsøk. Istedet for å hashe passordet til man blir grønn i ansiktet...

I bunn og grunn tror jeg ikke det er mulig å sikre seg 100% mot angrep. Det skal godt gjøres å bygge et system som er så sikkert at det ikke kan knekkes. Som Dyret er inne på så vil passordet, eller nærmere bestemt brukeren selv, være det svakeste leddet. Om du har satt opp et uknekkelig innloggingssystem som hasher og krypterer og verifiserer i alle retninger, så hjelper det svært lite om en bruker registrerer seg med passordet "a".

Nå har jeg kludret litt med dette her selv, og har kommet frem til at man egentlig bare må gjøre det man kan og sikre sin egen konto best mulig, så får man ta seg av slike angrep når de kommer (ved å lagre backuper og skifte passord jevnlig). For å beskytte databasen din bør du i det minste ha et skikkelig ulogisk passord av typen du ikke går rundt å husker. Bruk gjerne alle tre typer tegn (a-z A-Z 0-9 !-~) for å gjøre det vanskeligst mulig å gjette. Det er forresten også noe av grunnen til at noen nettsider tvinger det til å ha både tall og bokstaver i passordet.

Men om vi først skal lage noe som er ganske "sikkert" i PHP (fra serveren sin side, altså), så tenkte jeg på dette:
Bruke et innloggingsskjema med brukernavn og to eller flere passord (til samme konto). Passordene kan du hashe så mange ganger som du har tid til med flere saltst(r)enger. Hvert innlogginsforsøk som går i dass noteres med timestamp i databasen, slik at du kun har x antall forsøk uansett IP, sessions eller cookies. Som en bonus kan man notere IP-adressene som brukes også, slik at disse kan sjekkes eller sperres og sånt. Også må brukeren også svare på en CAPTCHA hver gang. Dette ville tatt rimelig lang tid og vært utrolig plagsomt, selvsagt. Hvis du er laget av gryn så kan du jo også legge inn en SMS-tjeneste, hvor du må taste inn en engangskode fra mobilen din ved innlogging. Ikke ulikt Bank-ID-systemet.