Neida, jeg mener ikke at det er ubrukelig.

Salting er absolutt en lur ting å gjøre, men det eneste du egentlig beskytter deg mot er rainbow tables. Det vil ikke ta mange timene å bruteforce et saltet passord av formatet md5(md5(pass)+md5(salt)), og i alle fall ikke årevis (avhengig av passordkompleksitet). Er du realistisk så vil nemlig en angriper sjeldent kun sitte på étt felt fra databasen, men hele databasen på en gang. Hashing gir da en slags "timeout" for administratorene å oppdage feilen, advare brukerne, og for brukerne å endre passord.

Hvis du vil ha en bedre "tidsbeskyttelse" så er det ikke så lurt å bruke hashingalgoritmer som er laget for å være raske å kjøre (f.eks. md5). Det er det jeg prøver å få fram. Samtidig er det ikke lurt å lage egenproduserte kryptografiske kombinasjoner av ulike varianter uten å vite nøyaktig hva man holder på med. Eksempelvis er rand() vanligvis uniformt fordelt, mens rand()*rand() (som tilsynelatende gir "mer" randomness) blir en Gauss-kurve med mye mer bias nær midtpunktet. Ekstremt mange personer får slike lure idéer om at ting blir sikrere om de legger til sin egen lille tvist i algoritmene, og det fører ofte til kritiske feil i ettertid.

Alle de ulike verktøyene har derimot sine baksider. Salts ødelegger for rainbow tables, men krever mer lagringsplass. Bcrypt o.l. ødelegger for brute-forcing, men legger til ekstra CPU-bruk på server og innloggingstid for en bruker. Egenproduserte komposisjoner av kryptografiske algoritmer gir "security through obscurity", men introduserer ofte kritiske hull som er vanskelig å oppdage før det er for sent.