Salt maken met OpenSSL of Mcrypt
Kan ik voor het genereren van een salt beter
Wat ik ook wel eens zie, is dat er een uuid wordt gebruikt. Ook die voldoen aan de voorwaarde dat ze wereldwijd uniek zijn (althans, de kans is best wel klein dat je twee dezelfde genereert) en ze zijn bovendien snel te genereren. Volgens mij is het lood om oud ijzer. Het belangrijkste aan een salt is dat hij (wereldwijd) uniek is, maar voor een goed hashing-algoritme zou het niet moeten uitmaken wat er verder in de salt staat. Hoe langer de salt, hoe groter de kans dat hij uniek is.
Het gaat overigens om een verbetering van deze $salt uit OpenCart:
Dat is natuurlijk een opeenstapeling van meerdere fouten. Dank je Willem, een UUID is inderdaad ook een goede optie.
En md5() met een undefined rand() ook.
Dat kan inderdaad veel beter. En of je nu 255 tekens of 9 opslaat, dat verschil is echt te verwaarlozen. Substr(... 9) is wel een hele korte salt inderdaad.
Knelpunten:
1. rand() is zwakker dan mt_rand();
2. uniqid() geeft geen unieke ID;
3. md5() is zwak en verouderd;
4. substr() geeft hier maar 9 hexadecimale karakters.
Ik heb mijn voorlopige oplossing in een inhaaktopic gepost. THX Eddy, helemaal goed!
Daarmee vertaal je eventueel moeilijk te raden tekens naar makkelijkere (A-Z, a-z, 0-9).
Je kan het wel makkelijker doorspelen via urls etc, maar waarom zou je dit doen?
Goed, je kan het terugvertalen (en is dus geen hash), maar toch. Waarom die base64_encode()?
Een salt mag openbaar zijn, dus is het al dan niet moeilijk kunnen raden geen issue.
Hoogstens zou je kunnen zeggen dat een base64-encode de entropie van de salt verlaagt, maar ook dat is eigenlijk niet zo'n heel belangrijk punt. Als de salt maar uniek is. ;-) > Daarmee vertaal je eventueel moeilijk te raden tekens naar makkelijkere (A-Z, a-z, 0-9).
> Een salt mag openbaar zijn, dus is het al dan niet moeilijk kunnen raden geen issue.
Correct. Ik heb de methode daarom vereenvoudigd tot ASCII-karakters en de Mersenne Twister. Daarbij staat $this->Length standaard op 255, zodat de salt makkelijk in een CHAR(255) is op te slaan:
Dank allen!
Wat ik ook wel eens zie, is dat er een uuid wordt gebruikt. Ook die voldoen aan de voorwaarde dat ze wereldwijd uniek zijn (althans, de kans is best wel klein dat je twee dezelfde genereert) en ze zijn bovendien snel te genereren.
Het gaat overigens om een verbetering van deze $salt uit OpenCart:
Dat is natuurlijk een opeenstapeling van meerdere fouten.
En md5() met een undefined rand() ook.
Dat kan inderdaad veel beter. En of je nu 255 tekens of 9 opslaat, dat verschil is echt te verwaarlozen.
Knelpunten:
1. rand() is zwakker dan mt_rand();
2. uniqid() geeft geen unieke ID;
3. md5() is zwak en verouderd;
4. substr() geeft hier maar 9 hexadecimale karakters.
Ik heb mijn voorlopige oplossing in een inhaaktopic gepost.
Gewijzigd op 04/11/2014 08:53:27 door Stefan Fransen
Daarmee vertaal je eventueel moeilijk te raden tekens naar makkelijkere (A-Z, a-z, 0-9).
Je kan het wel makkelijker doorspelen via urls etc, maar waarom zou je dit doen?
Goed, je kan het terugvertalen (en is dus geen hash), maar toch.
Een salt mag openbaar zijn, dus is het al dan niet moeilijk kunnen raden geen issue.
Hoogstens zou je kunnen zeggen dat een base64-encode de entropie van de salt verlaagt, maar ook dat is eigenlijk niet zo'n heel belangrijk punt. Als de salt maar uniek is. ;-)
> Een salt mag openbaar zijn, dus is het al dan niet moeilijk kunnen raden geen issue.
Correct. Ik heb de methode daarom vereenvoudigd tot ASCII-karakters en de Mersenne Twister. Daarbij staat $this->Length standaard op 255, zodat de salt makkelijk in een CHAR(255) is op te slaan:
Code (php)