Ikzelf gebruik [php]password_hash[/php] die zelf bcrypt gebruikt. Maar er is nog meer mogelijk:
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.
Controleren moet je doen met [php]password_verify[/php]
Ik begrijp dat dit belangrijk is, maar ik durf haast te zeggen dat dit lang niet het belangrijkste (of enige belangrijke ding) is.
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".
> 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.
MD5 kent voor zover ik weet veel mogelijkheden tot collisions, waardoor het behoorlijk zwak is. Tot hoever weet ik zelf niet echt.
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.
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 ;-)
Volgens mij is het gewoon de bedoeling dat je password_hash / password_verify, en password_needs_rehash gaat gebruiken. Team-PHP zorgt er dan voor dat je altijd "de beste" hashing hebt (wat dat dan ook is). Het voorkomt in ieder geval dat ieder weer z'n eigen algoritmes moet knutselen die na een paar jaar zonder onderhoud / met nieuwe inzichten volledig achterhaald zijn.
@Ozzie: Standaard gebruikt password_hash() bcrypt.
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?