Momenteel werk ik met hash('sha512', $pw) voor mijn paswoorden. Is er iets beter en is het de moeite om over te stappen bij een bestaand project.
volgens http://php.net/manual/en/function.hash.php zijn er zo veel mogelijkheden om uit te kiezen maar de sterkte is niet vermeld.
Als iemand de database heeft weten te onderscheppen, maar de code zelf niet ... heeft het dan meerwaarde om iets aan het wachtwoord toe te voegen, vraag ik me af ...
Dus stel, iemand heeft als wachtwoord 'welkom' ... heeft het dan meerwaarde als ik daar nog een vaste salt aan toevoeg zodat het wachtwoord bijvoorbeeld 'welkom_!@@#$@^_' wordt? Is dat nog een maatregel die zinvol is?
Thanks Thomas ... ik stel de vraag eigenlijk omdat password_hash zelf al een (random) salt toevoegt. Heeft het dan nog wel zin om zelf nog een vaste salt toe te voegen?
In 1e instantie zou je denken van niet, omdat er al een random salt wordt toegevoegd. Maar als het wachtwoord 'welkom' is, dan is dat nog steeds (relatief) makkelijk te herleiden.
Voegt het in dit geval dan iets toe om naast die random salt nog een stukje "vast" toe te voegen, waardoor 'welkom' dus bijvoorbeeld 'welkom_!@@#$@^_' wordt? Want dat kun je dan toch niet meer achterhalen lijkt me? (even ervan uitgaande dat de "hacker" enkel je database te pakken heeft gekregen en niet je code (zodat hij dus niet kan zien dat de salt '_!@@#$@^_' is toegevoegd). Klopt mijn verhaal? Of is dit schijnveiligheid?
Hm, interessant. Het lijkt mij geen kwaad kunnen. Het wachtwoord wordt langer en complexer. Je zult dan dus ook in password_verify() elke keer die salt moeten plakken, maar dat is niet zo ingewikkeld.
De vraag is wel of het de goede plek is om potentieel zwakke wachtwoorden daar, en op die manier, te pimpen. Ik zou zeggen dat de oorsprong van dat probleem elders ligt, en ook elders opgelost zou moeten worden, maar het is een interessant idee.
Ja, lijkt me inderdaad wel interessant. Je kunt gebruikers wel verplichten om bijv. hoofd- en kleine letters inclusief een getal en vreemd teken te gebruiken en een minimale lengte van x tekens, maar nog steeds kun je dan een wachtwoord krijgen als "aaaaaaa1!" wat prima aan de eisen voldoet, maar waarschijnlijk nog steeds vrij makkelijk te herleiden is. Als je het wachtwoord in de code wijzigt naar "aaaaaaa1!_!@@#$@^_" wordt dat een stuk lastiger (ervan uitgaande dat ze de code niet kunnen inzien).
Aan de andere kant, dit is in zekere zin nog steeds security through obscurity. Het is een bekend recept waar je een geheim ingrediënt (meer zout :p) aan toevoegt. Het zal ongetwijfeld helpen waarbij ook simpele wachtwoorden moeilijker te kraken zijn, maar het maakt de oplossing minder transparant en ook complexer (extra handeling tijdens password_verify()). Het is altijd beter om een compleet transparante oplossing te hebben zodat zelfs als die bekend is dat de constructie nog steeds veilig is.
Naar dit principe wordt ook verwezen in het artikel dat @Remco in zijn eerdere reactie linkte.
Hmm, ja ik snap wel wat je bedoelt. Je zal het extra beetje zout altijd moeten toevoegen inderdaad. Maar als dat onderdeel is van je systeem is het een kwestie van eenmalig implementeren.
Maar het is toch nog steeds wel 'veiliger'? En met veiliger bedoel ik dan dat ALS je database zou worden gehackt, en enkel je database en niet de code, het vrijwel onmogelijk wordt om de boel te herleiden. Men zou dan immers dat extra beetje zout moeten kennen, en zolang men dat niet kent is het volgens mij een onmogelijke opgave. Van een 'welkom' kunnen we immers verwachten dat het in een rainbow table / dictionary voorkomt, maar van een 'welkom_geheim_zout@#$#@!##@!@#!@' lijkt me dat erg sterk.
Heb nog even hier over na zitten denken.
Extra zout toevoegen is een idee. Je zou ook emailadres op een bepaalde plek neer kunnen zetten in de hash. Immers die is uniek per account als het goed is.
Andere mogelijkheid is, tijdens het registreren een controle uitvoeren of het wachtwoord een bekend wachtwoord is. Er zijn hele lijsten met bekende wachtwoorden te vinden op het net die je eventueel kan gebruiken voor deze controle.
Je kan ook afdwingen dat het uit een bepaalde tekenreeks moet bestaan zodat het nooit een bestaand woord kan worden. W3lj0m@1 kan wel en welkom01 niet. Het moet minimaal uit 8 tekens zijn en minimaal 1 hoofdletter bevatten, en minimaal 1 speciaal teken en 1 cijfer.
Dat extra zouten is goed, maar je gebruikers afdwingen om een fatsoenlijk wachtwoord te maken is in den beginnen nog beter.
Hey tis vroeg, en was maar een voorbeeld he. :)
Ging me meer om de beeldvorming waar een controle zou moeten worden uitgevoerd om een sterk wachtwoord te maken.
