Wat is tegenwoordig de beste manier om wachtwoorden te hashen? En welke algoritme te gebruiken?
Iemand wellicht een voorbeeldje?
Wachtwoord hash
2.050 views
Ozzie PHP op 12/02/2019 21:46:59
@Rob
Maar als je het overlaat aan het 'team' en niet expliciet een algoritme aangeeft, heb je wel een probleem als het team dat algoritme wijzigt. Dan kan niemand meer inloggen.
@Ariën
>> Als je PASSWORD_BCRYPT meegeeft aan de functie ...
Geef jij zelf PASSWORDT_BCRYPT mee aan de functie? Of gebruik je de default?
Nee, ik gebruik de standaard.
[size=xsmall]Toevoeging op 12/02/2019 22:31:41:[/size]
Rob Doemaarwat op 12/02/2019 22:20:30
Daarom moet je na een succesvolle password_verify() ook even een password_needs_rehash() doen (zie example #1).
Goed idee....
Maar wanneer zou de hash niet meer kloppen? Bij een wijziging van de PHP-versie of de cost?
@Aar
"As mentioned on the Password Hashing Predefined Constants and password_hash pages, the algorithm used by PASSWORD_DEFAULT is subject to change as different versions of PHP are released."
Anders gezegd, met de default optie (die jij dus gebruikt) kan een keer het algoritme veranderen. Dat zou dan inhouden dat niemand meer kan inloggen. Oeps ...
"As mentioned on the Password Hashing Predefined Constants and password_hash pages, the algorithm used by PASSWORD_DEFAULT is subject to change as different versions of PHP are released."
Anders gezegd, met de default optie (die jij dus gebruikt) kan een keer het algoritme veranderen. Dat zou dan inhouden dat niemand meer kan inloggen. Oeps ...
En in dat geval lijkt die password_needs_rehash() erg handig ;-)
Weer wat geleerd.
Weer wat geleerd.
> Het gaat erom dat het veilig is, en van MD5 (wat ik puur even als voorbeeldje gaf) is algemeen bekend dat dat niet meer als veilig wordt beschouwd.
Een verkeerd gebruik van welke methode dan ook is per definitie niet veilig. Gebruik maken van password_hash() en password_verify() maakt oplossingen ook niet automagisch "veilig". Dit is een complete misvatting. Stel dat jouw oplossing dit gebruikt, maar je query is vatbaar voor SQL-injectie, dan kan ik wel een wachtwoord + een hash verzinnen en meegeven zodat dit resultaat oplevert. Sterker nog, er zijn hele volksstammen die zo denken, en vervolgens het evangelie lopen te verkondigen met baggertutorials op YouTube.
> Ik vraag ook niet naar andere methodes van security, enkel naar wat een goede en gebruikelijke hashingmethode is ;-)
Actually, je vroeg (zoals vanouds?) weer naar de "beste" oplossing. Ik heb geen idee wat dit in jouw geval betekent.
Een verkeerd gebruik van welke methode dan ook is per definitie niet veilig. Gebruik maken van password_hash() en password_verify() maakt oplossingen ook niet automagisch "veilig". Dit is een complete misvatting. Stel dat jouw oplossing dit gebruikt, maar je query is vatbaar voor SQL-injectie, dan kan ik wel een wachtwoord + een hash verzinnen en meegeven zodat dit resultaat oplevert. Sterker nog, er zijn hele volksstammen die zo denken, en vervolgens het evangelie lopen te verkondigen met baggertutorials op YouTube.
> Ik vraag ook niet naar andere methodes van security, enkel naar wat een goede en gebruikelijke hashingmethode is ;-)
Actually, je vroeg (zoals vanouds?) weer naar de "beste" oplossing. Ik heb geen idee wat dit in jouw geval betekent.
@Aar
Ik denk dat die check niet nodig is als je zelf expliciet een algoritme kiest.
@Thomas
>> Een verkeerd gebruik van welke methode dan ook is per definitie niet veilig.
Dat klopt. Maar jij gaat nu uit van "als dan" situaties en dat kun je overal dan wel op toepassen. Je kunt in een heel veilige auto rijden, maar als je tijdens het rijden je autoportier wagenwijd openzet, kun je erop wachten dat je vroeg of laat uit de auto dondert ;-)
Als ik vraag wat een veilige auto is, dan zou een antwoord kunnen zijn "een Volvo vanwege een grote kreukelzone", en dan zit ik niet te wachten op / kan ik niet zoveel met een antwoord à la "geen enkele auto is veilig als je je gordel niet omdoet".
Ik hoop dat je een beetje begrijpt wat ik je probeer te zeggen. Ik snap dat een hashing methode op zichzelf geen unieke garantie biedt voor een veilige website. Dat was echter mijn vraag ook niet. Mijn vraag is wat heden ten dage wordt beschouwd als de beste manier om een wachtwoord te hashen. Niks meer en niks minder. En volgens mij valt daar best een concreet antwoord op te geven.
Ik denk dat die check niet nodig is als je zelf expliciet een algoritme kiest.
@Thomas
>> Een verkeerd gebruik van welke methode dan ook is per definitie niet veilig.
Dat klopt. Maar jij gaat nu uit van "als dan" situaties en dat kun je overal dan wel op toepassen. Je kunt in een heel veilige auto rijden, maar als je tijdens het rijden je autoportier wagenwijd openzet, kun je erop wachten dat je vroeg of laat uit de auto dondert ;-)
Als ik vraag wat een veilige auto is, dan zou een antwoord kunnen zijn "een Volvo vanwege een grote kreukelzone", en dan zit ik niet te wachten op / kan ik niet zoveel met een antwoord à la "geen enkele auto is veilig als je je gordel niet omdoet".
Ik hoop dat je een beetje begrijpt wat ik je probeer te zeggen. Ik snap dat een hashing methode op zichzelf geen unieke garantie biedt voor een veilige website. Dat was echter mijn vraag ook niet. Mijn vraag is wat heden ten dage wordt beschouwd als de beste manier om een wachtwoord te hashen. Niks meer en niks minder. En volgens mij valt daar best een concreet antwoord op te geven.
@Ozzie: Volgens mij klopt het. Maar ik gebruik, zoals ik al zei, de standaard algoritme in PHP. Ik heb geen zin om die boel opnieuw te compileren :-P
Dan is er nog wat interessants...
En wat als je tussentijds switched van algoritme?
Stel je gebruikt nog md5 en je wilt leden zonder een password-reset een veiliger password geven?
Is het dan slim om in de ledentabel een veld aan te maken hoe het wachtwoord gehashed is (md5, crypt), en bij een oude onveilige encryptie dit na het succesvol inloggen het ingevoerde wachtwoord omzetten naar de veilige variant, en het record te flaggen met 'crypt' i.p.v. 'md5'? Of zijn er nog dingen om over na te denken?
Uiteraard lijkt het mij wel handig om niet eeuwig hashes van zwakke algoritmes te gebruiken in een inlogsysteem, en op dat moment de deur tijdelijk dicht doen totdat ze een nieuw wachtwoord hebben aangemaakt.
Dan is er nog wat interessants...
En wat als je tussentijds switched van algoritme?
Stel je gebruikt nog md5 en je wilt leden zonder een password-reset een veiliger password geven?
Is het dan slim om in de ledentabel een veld aan te maken hoe het wachtwoord gehashed is (md5, crypt), en bij een oude onveilige encryptie dit na het succesvol inloggen het ingevoerde wachtwoord omzetten naar de veilige variant, en het record te flaggen met 'crypt' i.p.v. 'md5'? Of zijn er nog dingen om over na te denken?
Uiteraard lijkt het mij wel handig om niet eeuwig hashes van zwakke algoritmes te gebruiken in een inlogsysteem, en op dat moment de deur tijdelijk dicht doen totdat ze een nieuw wachtwoord hebben aangemaakt.
Het lijkt me dat ze niet een nieuw wachtwoord hoeven in te geven, maar dat je het bestaande wachtwoord opnieuw hasht en opslaat. Daar is die password_needs_rehash() volgens mij precies voor bedoeld. Die kan blijkbaar detecteren of het algoritme gewijzigd moet worden, en zo ja ... dan opnieuw genereren en opslaan.