Wachtwoord hash
Iemand wellicht een voorbeeldje?
Quote:
The following algorithms are currently supported:
PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).
PASSWORD_BCRYPT - Use the CRYPT_BLOWFISH algorithm to create the hash. This will produce a standard crypt() compatible hash using the "$2y$" identifier. The result will always be a 60 character string, or FALSE on failure.
PASSWORD_ARGON2I - Use the Argon2i hashing algorithm to create the hash. This algorithm is only available if PHP has been compiled with Argon2 support.
PASSWORD_ARGON2ID - Use the Argon2id hashing algorithm to create the hash. This algorithm is only available if PHP has been compiled with Argon2 support.
PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).
PASSWORD_BCRYPT - Use the CRYPT_BLOWFISH algorithm to create the hash. This will produce a standard crypt() compatible hash using the "$2y$" identifier. The result will always be a 60 character string, or FALSE on failure.
PASSWORD_ARGON2I - Use the Argon2i hashing algorithm to create the hash. This algorithm is only available if PHP has been compiled with Argon2 support.
PASSWORD_ARGON2ID - Use the Argon2id hashing algorithm to create the hash. This algorithm is only available if PHP has been compiled with Argon2 support.
Controleren moet je doen met password_verify
Gewijzigd op 12/02/2019 16:34:26 door - Ariën -
Om de veiligheid van applicaties te waarborgen werk je met lagen. Het hashen van je wachtwoord is daar slechts één van, die meer garandeert dat iemand zijn/haar originele wachtwoord niet achterhaald kan worden dan dat dit de applicatie nu echt veiliger maakt.
Het zou bijvoorbeeld al meer helpen wanneer je afdwingt dat een wachtwoord aan bepaalde criteria zou moeten voldoen (lengte, karaters, case), en dat deze eens in de zoveel tijd veranderd zou moeten worden. In die zin maakt een ingewikkeld(er) hashing mechanisme je applicatie niet veiliger.
Er is ook geen "beste manier". Er is misschien wel een "beste (of op zijn minst goede/acceptabele) manier voor situatie X".
Thanks. Bedoel je dan deze? PASSWORD_BCRYPT
@Thomas
Ik snap dat er meer lagen zijn, maar ik wil specifiek weten wat de beste hashing methode is op dit moment. Bijvoorbeeld MD5 is geen aanrader.
WAAROM niet :p.
Ik ken de redenen wel een beetje, en de "industrie" plaatst dit mechanisme in het verdomhoekje, maar als MD5 als hashingmethode een probleem vormt, wil dat dan niet zeggen dat er op een andere plek iets mis is?
Brute force: dan zit er geen limiet op het aantal inlogpogingen?
Collisions/toevalstreffers: wachtwoord te zwak?
Toegang tot database verkregen: ik denk dat het ontcijferen van wachtwoorden dan het minste van je problemen is.
> de beste hashing methode
Bestaat niet. Security is ook een tradeoff versus oa gebruikersgemak. Zo levert een hogere cost dan wellicht een betere versleuteling (?) op, maar wil je dan seconden langer wachten als je inlogt?
Je bent in je vraagstukken vaak op zoek naar "het beste" zonder dat je dit toepast op een concrete situatie.
Dit is zoiets als "wat is de beste manier om drukwerk op te bergen"? Who knows? Een kartonnen doos? Een gelakte eikenhouten boekenkast? Een vitrine met klimaatcontrole? Wat voor drukwerk betreft het uberhaupt? Een kopie van een meesterwerk met zeer beperkte oplage? Een antieke geillustreerde bijbel? De Donald Duck? Hoe kun je in hemelsnaam zo'n vraagstuk eenduidig beantwoorden?
Ik denk dat je veel te veel leunt op theorie, en te weinig op een praktische toepassing.
Gewijzigd op 12/02/2019 19:30:00 door Thomas van den Heuvel
Zelf gebruik ik het niet voor wachtwoorden, en enkel voor plekken waarbij een unieke code van belang is. Zoals mijn CMS waarbij ik nieuwe en niet-opgeslagen nieuwsitems toch een tijdelijk ID meegeef voor het koppelen/uploaden van afbeeldingen.
Kun je mijn vraag nog even beantwoorden?
@Thomas
Ik snap je wel, maar er bestaat ook zoiets als algemeen gangbaar. En MD5 is dat zeker niet. Ik denk / mag hopen dat je snapt wat ik bedoel. Ik wil gewoon een fatsoenlijke en veilige hashingmethode en of iemand dan een tiende van een seconde moet wachten om in te loggen, boeit me eerlijk gezegd geen @!w#@!. 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. Ik vraag ook niet naar andere methodes van security, enkel naar wat een goede en gebruikelijke hashingmethode is ;-)
Als je PASSWORD_BCRYPT meegeeft aan de functie wordt er Blowfish Crypt gebruikt, maar de standaard Bcrypt is er enkel van afgeleid.
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?
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?
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.
Toevoeging op 12/02/2019 22:31:41:
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?
Gewijzigd op 12/02/2019 22:31:59 door - Ariën -
"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 ...
Weer wat geleerd.
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.
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.
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.
Gewijzigd op 13/02/2019 00:54:27 door - Ariën -