[PHP] Salt berekenen

[Bv202]

Hey,

Ik vroeg me af hoe je best password salts kunt berekenen. Ik zat te denken aan de gebruikersnaam (laten we er vanuitgaan dat onze tabel "users" 3 velden heeft: id, username en password) te gebruiken om de salt te berekenen, maar hoe doe je dit best? Misschien iets willekeurigs verzinnen zoals:

- Neem de eerste en de derde letter van de username
- Voeg de tweede letter hierachter toe
- Bereken hiervan de MD5
- Neem de eerste 10 tekens van de MD5
- Zet hier ook weer wat gegevens van de username achter en bereken een hash met een algoritme
- Etc. etc.
- Voeg de salt toe aan het wachtwoord en bereken de uiteindelijke hash met SHA512

Dit is iets wat ik zonet heb verzonnen. Is deze manier van denken juist of net helemaal verkeerd? Hoe bereken je een goede salt?

Dan is er nog een probleem met deze methode. Stel nu dat ik gebruikers de mogelijkheid wil geven hun username te veranderen. Geen probleem dan, ik vraag gewoon bij het veranderen ook hun wachtwoord, controleer dat wachtwoord eerst en als het klopt veranderd de username en wordt een nieuwe hash berekent dmv de ingegeven gebruikersnaam en wachtwoord.

Maar wat nu als ik als beheerder een username wil veranderen? Of als ik dit via de database wil doen? Ik heb geen toegang tot hun wachtwoorden, en hun hash is afhankelijk van de gebruikersnaam. Als de gebruikersnaam veranderd, moet een nieuwe hash berekend worden, maar daarvoor heb ik hun wachtwoord nodig. De enige oplossing die ik kan bedenken is in de database een extra veld "old username" toe te voegen en daar tijdelijk de oude naam op te slaan tot de user 1x heeft ingelogd, zodat de hash dan veranderd. Maar dit lijkt me wel een heel slechte methode.

Ben ik hier helemaal verkeerd met mijn denkwijze? Hoe bereken je best zo'n salt?

Bedankt

[orf]

Waarom niet gewoon een random salt per user?

[posttoast]

Volgens mij maakt het niet zoveel uit hoe je die salt berekent. Wat jij nu doet is security through obscurity. De "veiligheid" zit hem bij jou dus in de manier waarop je de salt samenstelt. Ik zelf houd het gewoon eenvoudig: als er een nieuwe user wordt toegevoegd aan de database wordt de "date_created" als unix timestamp in de database gezet. En dat is de salt. Dus:

PHP:

$password_hashed = hash('sha512', $password.$date_created);

[GlowMouse]

Voeg de salt toe aan het wachtwoord en bereken de uiteindelijke hash met SHA512

Een rainbow attack voorkom je zo niet, met sha512(sha512(password)+salt)) wel.

[Wiebbe]

Ik heb gewoon 1 extra veld voor een random salt per user, en gebruik een extra globale salt die voor iedereen hetzelfde is. Zo lang je een goede random salt hebt kunnen ze met een rainbow table echt niet je passwords verkrijgen.

En als het voor een prive site is, zou ik me niet al te druk maken als je iets als jij hebt voorgesteld gebruikt, meer is denk ik overkill

[Orion84]

Een salt wordt doorgaans gebruikt om het kraken van wachtwoorden middels een rainbowtable te voorkomen. Daarvoor hoeft die salt echt niks geheimzinnigs te zijn. Dus iets ingewikkelds dat afhankelijk is van de username, wat zoals je zelf al merkt tot problemen leidt, is niet echt nodig.

Je kan ook gewoon willekeurige strings pakken en die opslaan in de database, naast username en password+salt hash. Waar het om gaat is dat de password hash die in je DB staat niet een hash is van een te korte/eenvoudige string. Dat voorkom je door het wachtwoord eerst te verlengen met de salt voor je hasht en opslaat.

Edit: met al die net iets snelleren hierboven dus
En inderdaad, zoals GlowMouse zegt: eerst password hashen, dan salt er bij en dan nog eens hashen. Anders kan iemand die de salt weet een custom rainbowtable bouwen, dus dan bescherm je alleen tegen kraken middels standaard rainbow tables.
* Orion84 gaat er nog even goed over nadenken.

[ Voor 22% gewijzigd door Orion84 op 13-02-2011 12:24 ]

[Bv202]

orf schreef op zondag 13 februari 2011 @ 12:16:
Waarom niet gewoon een random salt per user?

Dat was hetgene wat ik ook deed eerst, maar zo'n random salt moet ergens opgeslagen worden. Die plakte ik dan achteraan de hash en sloeg dit op in de database.

Maar na dit topic blijkt dat deze methode niet juist is.

EDIT:
Wow, jullie zijn snel met reageren. Ff doorlezen

[ Voor 6% gewijzigd door Bv202 op 13-02-2011 12:21 ]

[GlowMouse]

Orion84 schreef op zondag 13 februari 2011 @ 12:19:
En inderdaad, zoals GlowMouse zegt: eerst password hashen, dan salt er bij en dan nog eens hashen. Anders kan iemand die de salt weet een custom rainbowtable bouwen, dus dan bescherm je alleen tegen kraken middels standaard rainbow tables.

Nee, dat kan nu nog steeds. En dat is niet zo erg, want wie gaat er voor elke user een aparte rainbowtable opbouwen? Wat ik voorkom is dat je zonder dat je de salt weet een rainbowtable kunt gebruiken.

Als je echt wilt voorkomen dat iemand met db-toegang voldoende info heeft, kun je een deel van de salt in de code zetten, zoals ook wordt voorgesteld.

[ Voor 21% gewijzigd door GlowMouse op 13-02-2011 12:24 ]

[Orion84]

Ik zou eerder twijfelen aan de opmerkingen in dat topic dat die methode niet juist zou zijn.

Zeker, een geheime salt maakt het sterker, maar dat is moeilijk doen om niks, want daar is salting helemaal niet voor bedoeld.

[posttoast]

Orion84 schreef op zondag 13 februari 2011 @ 12:19:
En inderdaad, zoals GlowMouse zegt: eerst password hashen, dan salt er bij en dan nog eens hashen. Anders kan iemand die de salt weet een custom rainbowtable bouwen, dus dan bescherm je alleen tegen kraken middels standaard rainbow tables.

Is dat ook persé nodig in het geval dat ik aanhaalde? De enige manier om daar aan de salt te komen is als je toegang tot de database hebt. En je kunt je afvragen of het dan überhaupt nog uitmaakt (hoewel dat een andere discussie is).

[GlowMouse]

posttoast schreef op zondag 13 februari 2011 @ 12:24:
[...]

Is dat ook persé nodig in het geval dat ik aanhaalde? De enige manier om daar aan de salt te komen is als je toegang tot de database hebt. En je kunt je afvragen of het dan überhaupt nog uitmaakt (hoewel dat een andere discussie is).

Bij jou hoef je de salt niet te weten, één grote rainbowtable volstaat. Hij moet wel heel groot zijn

[posttoast]

GlowMouse schreef op zondag 13 februari 2011 @ 12:25:
[...]

Bij jou hoef je de salt niet te weten, één grote rainbowtable volstaat. Hij moet wel heel groot zijn

Dat snap ik niet helemaal, kun je dat uitleggen?

[GlowMouse]

posttoast schreef op zondag 13 februari 2011 @ 12:29:
[...]

Dat snap ik niet helemaal, kun je dat uitleggen?

Als ik $password_hashed heb van dit stukje:

PHP:

$password_hashed = hash('sha512', $password.$date_created);

dan krijg ik met de juiste rainbowtable $password.$date_created terug. Ik zie dan direct het wachtwoord.

[Orion84]

posttoast schreef op zondag 13 februari 2011 @ 12:24:
[...]

Is dat ook persé nodig in het geval dat ik aanhaalde? De enige manier om daar aan de salt te komen is als je toegang tot de database hebt. En je kunt je afvragen of het dan überhaupt nog uitmaakt (hoewel dat een andere discussie is).

Hoe wilde je anders aan die password hash komen? Sniffen? Als je hem kan sniffen dan is het makkelijk om gewoon een replay attack te doen, ipv de hash te gaan kraken denk ik. Salting is volgens mij juist bedoeld om snel kraken van een gelekte password database middels rainbowtables te voorkomen.

GlowMouse schreef op zondag 13 februari 2011 @ 12:22:
[...]

Nee, dat kan nu nog steeds. En dat is niet zo erg, want wie gaat er voor elke user een aparte rainbowtable opbouwen? Wat ik voorkom is dat je zonder dat je de salt weet een rainbowtable kunt gebruiken.

Als je echt wilt voorkomen dat iemand met db-toegang voldoende info heeft, kun je een deel van de salt in de code zetten, zoals ook wordt voorgesteld.

Kan je eens uitleggen waarom je met hash(password+salt) geen rainbow attack voorkomt? Om het wachtwoord te kraken moet je dan een rainbowtable hebben waar password+salt als string in voorkomt toch? Die tables zijn er als je de salt lang genoeg kiest niet...
In het beste geval krijg je een string X waarvoor geldt dat X != password+salt, maar hash(X) == hash(password+salt). Maar met X kan je vervolgens niet inloggen, omdat er serverside nog de salt aan wordt geplakt.
Wellicht zie ik iets over het hoofd, het is zondagochtend, en ik zit niet heel diep in deze materie, maar toch...

[ Voor 31% gewijzigd door Orion84 op 13-02-2011 12:33 ]

[Bv202]

Hey,

Bedankt voor de reacties

Dus als ik het goed begrijp, zou dit moeten volstaan?

PHP:

<?php

// Bereken random salt en zet deze in $salt

$hash = hash("sha512", hash("sha512", $password).$salt).$salt;
?>

De salt wordt nu gewoon achter de hash geplakt en zo in de db opgeslagen.

En is het hashen van het password vooraleer de salt toe te voegen en opnieuw te hashen enkel om grote rainbow tables te voorkomen die ook hashes bevatten van je wachtwoorden met salts? Als je salt nu lang genoeg is, is de kans dat dit voorkomt toch wel erg klein?

[ Voor 7% gewijzigd door Bv202 op 13-02-2011 12:34 ]

[Orion84]

GlowMouse schreef op zondag 13 februari 2011 @ 12:30:
[...]

Als ik $password_hashed heb van dit stukje:

PHP:

$password_hashed = hash('sha512', $password.$date_created);

dan krijg ik met de juiste rainbowtable $password.$date_created terug. Ik zie dan direct het wachtwoord.

Ja, maar die rainbowtable is er in de praktijk niet, want een rainbowtable voor strings van tientallen karakters lang is achterlijk groot. En met jouw aanpak moet je gewoon twee rainbow attacks doen. 1x om hash(password)+salt te achterhalen, en dan nog een keer op hash(password) (die je er dan ook zo uitpikt, als je de methode weet).

@hierboven: inderdaad, eerst het wachtwoord zelf hashen is iets beter, maar ik vraag me ook af of dat in de praktijk echt verschil maakt.
Overigens zou ik de salt gewoon in een los veld op slaan, dat lijkt me een stuk makkelijker in gebruik, in plaats van dat je steeds stringoperaties moet gaan toepassen om de salt los te knippen van de hash.

[ Voor 36% gewijzigd door Orion84 op 13-02-2011 12:39 ]

[CyBeR]

Bv202 schreef op zondag 13 februari 2011 @ 12:32:
Hey,

Bedankt voor de reacties

Dus als ik het goed begrijp, zou dit moeten volstaan?

PHP:

<?php

// Bereken random salt en zet deze in $salt

$hash = hash("sha512", hash("sha512", $password).$salt).$salt;
?>

De salt wordt nu gewoon achter de hash geplakt en zo in de db opgeslagen.

En is het hashen van het password vooraleer de salt toe te voegen en opnieuw te hashen enkel om grote rainbow tables te voorkomen die ook hashes bevatten van je wachtwoorden met salts? Als je salt nu lang genoeg is, is de kans dat dit voorkomt toch wel erg klein?

Dat volstaat ja. Voor de duidelijkheid: de meeste salted hashes van UNIX systemen zijn simpelweg hash(passwd . salt) . salt (of andersom natuurlijk, meestal wordt de salt vooraan gezet maar dat is implementatie).

Orion84 schreef op zondag 13 februari 2011 @ 12:31:

In het beste geval krijg je een string X waarvoor geldt dat X != password+salt, maar hash(X) == hash(password+salt). Maar met X kan je vervolgens niet inloggen, omdat er serverside nog de salt aan wordt geplakt.
Wellicht zie ik iets over het hoofd, het is zondagochtend, en ik zit niet heel diep in deze materie, maar toch...

Dat ligt er sterk aan hoe je tot de string gekomen bent. Het geinige bijvoorbeeld van de meeste hash collisions is dat als je twee strings hebt die dezelfde hash opleveren, je daar achteraan best dezelfde data kunt appenden en dat dan de hash hetzelfde blijft. Dus als hash(X) = AA en hash(Y) = AA, dan is hash(X . Z) = BB en hash (Y . Z) = ook BB.

Volgens mij is het met het bovenstaande in het achterhoofd trouwens dus technisch iets veiliger om de random salt vooraan te plakken.

[ Voor 3% gewijzigd door CyBeR op 13-02-2011 12:42 ]

[GlowMouse]

Orion84 schreef op zondag 13 februari 2011 @ 12:31:
@GlowMouse: Kan je eens uitleggen waarom je met hash(password+salt) geen rainbow attack voorkomt? Om het wachtwoord te kraken moet je dan een rainbowtable hebben waar password+salt als string in voorkomt toch? Die tables zijn er als je de salt lang genoeg kiest niet...
In het beste geval krijg je een string X waarvoor geldt dat X != password+salt, maar hash(X) == hash(password+salt). Maar met X kan je vervolgens niet inloggen, omdat er serverside nog de salt aan wordt geplakt.
Wellicht zie ik iets over het hoofd, het is zondagochtend, en ik zit niet heel diep in deze materie, maar toch...

Als salt heel erg lang is dan werkt het inderdaad niet. Maar als je slechts een paar tekens pakt uit een kleine deelverzameling van alle mogelijke 256 bytes dan hangt de kwaliteit sterk samen met de lengte van het wachtwoord van de user.

@Bv202: hash heeft een derde parameter, $raw_output, waarmee je weer een factor 2 spaart door het op te slaan in een blob-veld.

[Orion84]

CyBeR schreef op zondag 13 februari 2011 @ 12:41:
[...]
Dat ligt er sterk aan hoe je tot de string gekomen bent. Het geinige bijvoorbeeld van de meeste hash collisions is dat als je twee strings hebt die dezelfde hash opleveren, je daar achteraan best dezelfde data kunt appenden en dat dan de hash hetzelfde blijft. Dus als hash(X) = AA en hash(Y) = AA, dan is hash(X . Z) = BB en hash (Y . Z) = ook BB.

Volgens mij is het met het bovenstaande in het achterhoofd trouwens dus technisch iets veiliger om de random salt vooraan te plakken.

Is dat zo bij MD5, of ook bij SHA512, waar het hier over ging? Lijkt me dan namelijk een tamelijk brak hash algoritme en ik kan me van MD5 wel voorstellen dat dat zo gaar is, maar SHA512 ook?

GlowMouse schreef op zondag 13 februari 2011 @ 12:42:
[...]

Als salt heel erg lang is dan werkt het inderdaad niet. Maar als je slechts een paar tekens pakt uit een kleine deelverzameling van alle mogelijke 256 bytes dan hangt de kwaliteit sterk samen met de lengte van het wachtwoord van de user.

Mja, als je dat soort salts gebruikt, dan sla je imho ook gewoon compleet de plank mis. En bovendien, op wat voor manier is jouw methode dan beter, behalve dat het dan twee rainbow attacks nodig heeft?

[ Voor 87% gewijzigd door Orion84 op 13-02-2011 12:47 ]

[CyBeR]

Orion84 schreef op zondag 13 februari 2011 @ 12:43:
[...]


Is dat zou bij MD5, of ook bij SHA512, waar het hier over ging? Lijkt me dan namelijk een tamelijk brak hash algoritme en ik kan me van MD5 wel voorstellen dat dat zo gaar is, maar SHA512 ook?

Het is in ieder geval zo bij MD5 (toch een veelgebruikt algoritme). SHA512 zijn nog geen collisions bij gevonden geloof ik.

[GlowMouse]

Orion84 schreef op zondag 13 februari 2011 @ 12:43:
[...]

Mja, als je dat soort salts gebruikt, dan sla je imho ook gewoon compleet de plank mis. En bovendien, op wat voor manier is jouw methode dan beter, behalve dat het dan twee rainbow attacks nodig heeft?

Je kunt die van mij op twee manieren kraken:
1) Per salt een rainbowtable bouwen.
2) De buitenste sha512 los kraken, maar dit vereist een rainbowtable waarin minimaal 2^512 * [aantal mogelijke tekens die je voor de salt gebruikt]^[lengte salt] hashes moeten staan om gegarandeerd succesvol te zijn.

Het voordeel bij mijn methode is dat methode 2 nooit mogelijk zal zijn.

[CyBeR]

Overigens: een rainbow table voor een 512-bit hash is de eerstkomende tientallen jaren (en dat is een erg progressieve schatting) nog compleet en 120% onhaalbaar, als de wachtwoorden zelf niet compleet kut zijn (en dan is simpelweg bruteforcen sneller). Waar hebben we 't eigenlijk over

Hoe groot acht je bijvoorbeeld de kans dat iemand wél je wachtwoord-database heeft, maar niet de code die je gebruikt hebt om die hashed wachtwoorden te genereren?

[ Voor 29% gewijzigd door CyBeR op 13-02-2011 12:55 ]

[Verwijderd]

CyBeR schreef op zondag 13 februari 2011 @ 12:46:

Het is in ieder geval zo bij MD5 (toch een veelgebruikt algoritme). SHA512 zijn nog geen collisions bij gevonden geloof ik.

Ik zie het probleem niet zo. Het valt best mee met de "onveiligheid" van MD5. De enige reden om het wachtwoord te hashen is om het originele wachtwoord te beschermen zodat andere applicaties waarbij de eindgebruiker datzelfde wachtwoord heeft niet kunnen worden misbruikt. Als je een collision vindt kun je een ander wachtwoord gebruiken, maar alleen als die andere applicatie hetzelfde algoritme gebruikt.

[CyBeR]

Ik heb ook nergens gezegd dat ik een probleem heb met MD5. Voor dit doel volstaat 't namelijk gewoon prima.

[Bv202]

Hmm, ik dacht dat een rainbow table gewoon een gigantische lijst van wachtwoorden en hun hashes (van een bepaald algoritme) is. Als je dan een password hash hebt, kun je gewoon in de lijst het wachtwoord opzoeken.

Is dit verkeerd? Want waarom is dit voor 512-bit hashes op dit moment onmogelijk? In principe is het samenstellen van zo'n rainbow table dan toch enkel afhankelijk van de snelheid van het algoritme?

[CyBeR]

Om compleet te zijn moet je dan dus 2^512 hashes hebben, vermenigvuldigd met het aantal bits van je salt. Veel plezier.

Zoals ik al zei: je moet natuurlijk niet met z'n allen 5-karakterige wachtwoorden hebben. Daar ben je zo doorheen inderdaad, maar feitelijk bruteforce je dan de wachtwoorden en niet de hashes.

[joppybt]

GlowMouse schreef op zondag 13 februari 2011 @ 12:51:
[...]

Je kunt die van mij op twee manieren kraken:
1) Per salt een rainbowtable bouwen.

Kun je niet stellen dat het maken van de rainbowtable voor een bepaalde salt evenveel werk (dezelfde complexiteit) is als het als het brute-forcen van één wachtwoord?
Een rainbow table heeft alleen zin als dezelfde salt (geen salt of korte salt) gebruikt wordt voor meerdere wachtwoorden. Dan ben je weliswaar voor het eerste wachtwoord heel druk maar daarna heb je de rest heel snel.
Of zie ik het te simpel

[begintmeta]

Natuurlijk alleen semi-ontopic, maar ik vond dit best interessant. Misschien je MD5 ook nog eens overdenken.

[ Voor 13% gewijzigd door begintmeta op 13-02-2011 14:24 ]

[Shapeshifter]

Ik doe het altijd zo:

PHP:

function GenerateSalt(){
    for($i = 1; $i <= 128; $i++){
        $Salt .= chr(rand(1,255));
    }

    return hash('sha512', $Salt);
}

Dit geeft een Salt van 128 karakters (sha512 hash), welke random genoeg is voor een salt (ik bedacht me net dat de salt in de for loop meer entropie heeft dan de hash ervan, maar dat is niet zo heel erg, in principe kun je net zo goed time() oid hashen).

Vervolgens sla ik de salt op in een text document op de server (als iemand dan je db kraakt maar niet je server heeft hij de salts niet) en gebruik ik de volgende code om de passwordhash (die in de db opgeslagen is) te berekenen:

PHP:

$Salt = file_get_contents('../salts/'.$UID.'.txt');
$Hash = hash('sha512', $UID.$Salt.'~P3pp3r~'.$Password);

for($i = 1; $i <= 1000; $i++){
    $Hash = hash('sha512', $Hash);
}

Het User ID (het UID) fungeert dus als "salt" in de database, er staat een salt op de server, er zit een hardcoded pepper in de php en hij wordt nog gestrengthened. Verder kun je enkel via https op de site komen.

[Verwijderd]

Shapeshifter schreef op zondag 13 februari 2011 @ 14:28:
(ik bedacht me net dat de salt in de for loop meer entropie heeft dan de hash ervan, maar dat is niet zo heel erg, in principe kun je net zo goed time() oid hashen).

Bijna wel, ja, want rand() is niet heel erg random:

quote: http://PHP.net

By default, PHP uses the libc random number generator with the rand() function.

Je hebt meer aan mt_rand().

[Shapeshifter]

Verwijderd schreef op zondag 13 februari 2011 @ 14:39:
[...]
Bijna wel, ja, want rand() is niet heel erg random:
[...]
Je hebt meer aan mt_rand().

Klopt, maar dat is voor een salt niet echt belangrijk, zolang twee users maar niet dezelfde salt hebben...

[Verwijderd]

Shapeshifter schreef op zondag 13 februari 2011 @ 15:16:

Klopt, maar dat is voor een salt niet echt belangrijk, zolang twee users maar niet dezelfde salt hebben...

Waarom dan iets randoms als salt gebruiken als users unieke eigenschappen hebben?
Ik bedoel maar: een username, een emailadres?

Je hebt het probleem eigenlijk al omzeild door $UID te gebruiken, en dan maakt het random getal inderdaad eigenlijk al niet meer uit. Het voegt echter ook niets meer toe, behalve dat de salt dan misschien lang genoeg wordt gemaakt.

[ Voor 24% gewijzigd door Verwijderd op 13-02-2011 15:20 ]

[joppybt]

Verwijderd schreef op zondag 13 februari 2011 @ 15:19:
[...]

Waarom dan iets randoms als salt gebruiken als users unieke eigenschappen hebben?
Ik bedoel maar: een username, een emailadres?

• Ze kunnen te kort zijn. Op mijn werk (klein bedrijf) is je username twee of drie letters van je naam.
• Ze willen nog wel eens veranderen. Niet echt vaak hopelijk maar toch. Getrouwde personen willen bijvoorbeeld wel eens van naam veranderen.

[Soultaker]

GlowMouse schreef op zondag 13 februari 2011 @ 12:19:
Een rainbow attack voorkom je zo niet, met sha512(sha512(password)+salt)) wel.

Dat is onzin. Met simpelweg hash(password+salt) versla je een rainbow table ook (mits de salt een beetje zinnige lengte heeft).

In oudere UNIX systemen werd de username zelf als salt gebruikt. Dat werkt op zich wel goed, maar heeft als potentiële nadeel dat de salt erg kort kan zijn. Tegenwoordig is de conventie om een losse salt op te slaan en die ook geheim te houden; dat laatste is zoals Orion84 ook zegt niet de essentie van salting, maar het kan natuurlijk geen kwaad.

Als je liever iets ingewikkelders dan hash(salt+password) gebruikt, gebruik dan meteen HMAC; dat is een standaardmethode om voor keyed hash functions (waarbij je salt dus de key is) die rekening houdt met mogelijke zwaktes in de hashfunctie. Bedenk wel dat bij een theoretisch perfecte hashfunctie HMAC geen enkele extra veiligheid biedt; het nut bestaat eruit om (onvoorziene) zwaktes zo goed mogelijk te ondervangen.

CyBeR schreef op zondag 13 februari 2011 @ 12:41:
Het geinige bijvoorbeeld van de meeste hash collisions is dat als je twee strings hebt die dezelfde hash opleveren, je daar achteraan best dezelfde data kunt appenden en dat dan de hash hetzelfde blijft. [..] Het is in ieder geval zo bij MD5 (toch een veelgebruikt algoritme).

Zo eenvoudig als je het nu beschrijft is het niet; de invoer van MD5 wordt bijvoorbeeld uitgebreid met de lengte van de invoer. Die aanpak werkt in z'n algemeenheid dus alleen als je al een hashcollision hebt vóór het einde van de invoer, en als je twee strings hebt van gelijke lengte. (Aangezien de meeste hashfuncties met een eindige state werken is het inderdaad onvermijdelijk dat als je op enig moment op dezelfde state uitkomt, de rest van het algoritme ook hetzelfde verloopt als de invoer verder hetzelfde is.)

Om nog even samen te vatten (want dit is weer een typisch cryptografietopic waarin iedereen een mening heeft, maar niet iedereen verstand van zaken): de best practice is om een random salt te genereren, en vervolgens salt en HMAC(salt,wachtwoord) op te slaan.

De salt hoeft niet geheim te zijn, maar het kan geen kwaad, en het ligt wel voor de hand als je 'm toch naast de hashcode opslaat. In plaats van HMAC kun je ook gewoon hash(salt+wachtwoord) of iets dergelijks doen, maar dan ben je meer vatbaar voor zwaktes in de hashfunctie.