password_hash & password_verify
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
echo password_hash('test', PASSWORD_DEFAULT, ["cost"=>11]);
// $2y$11$KrBKpBLK3lH2/M89.a6Uaua48NKkYm.6LAOGiaVsPHNqWbBUOtzM2
// $2y$11$PFprOBp3BXLL2tOI6RDwUOFl8I7lAvyUX2HFhex7FHeFcB4Ycluv2
// $2y$11$w3B.44epBSOhC57zCG6BhO9FonU4.s6U1c154Iy6wEOADhxfURpw2
?>
echo password_hash('test', PASSWORD_DEFAULT, ["cost"=>11]);
// $2y$11$KrBKpBLK3lH2/M89.a6Uaua48NKkYm.6LAOGiaVsPHNqWbBUOtzM2
// $2y$11$PFprOBp3BXLL2tOI6RDwUOFl8I7lAvyUX2HFhex7FHeFcB4Ycluv2
// $2y$11$w3B.44epBSOhC57zCG6BhO9FonU4.s6U1c154Iy6wEOADhxfURpw2
?>
Resulteerd altijd in een andere hash, daarbij staat de encryptie methode en de options gewoon in de hash vermeld.
Mijn vraag is dus eigenlijk, hoe veilig is deze methode?
Is de kans op collisions niet aanzienlijk groter?
Kan ik deze waarde gewoon zo opslaan in de database zonder enig risico?
https://packagist.org/packages/nette/security
Of de Symfony security component voor wat uitgebreidere projecten:
https://packagist.org/packages/symfony/security
Dan hoef je ook niet te klooien met custom hashing methodes en weet ik het wat.
Mocht je wat minder ervaren zijn op het gebied van objectgeoriënteerd programmeren, dan zou ik je willen adviseren je hashing niet onnodig uitgebreid te maken. Een simpele hash() functie volstaat al.
Quote:
The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.
Dus, je hash is constant anders omdat er een random salt gegenereerd word, welke in de versleutelde string "verstopt" zit.
Je kunt ook zelf een salt meegeven via de options (word sterk afgeraden!), dan zal de hash steeds het zelfde zijn. De aanwezigheid van de salt maakt voor password_verify overigens niet uit, deze zal de verschillende hashes allemaal als geldig beschouwen.
Bron: http://php.net/password_hash
Edit:
De kans op collissions is denk ik te verwaarlozen, bcrypt is een prima algorithme mits goed gebruikt. (zie hier voor tips)
Opslaan in de database? ja. Zonder risico? helaas onmogelijk, er is niets zonder risico. Hoewel het in dit geval wel een erg klein risico is.
Gewijzigd op 12/08/2015 17:00:08 door Thom nvt
Richard Snijders op 12/08/2015 16:38:07:
Je zou eens op Packagist kunnen kijken of hier een library voor jou tussen zit. Denk dat deze wel cool is voor simpele projectjes:
https://packagist.org/packages/nette/security
Of de Symfony security component voor wat uitgebreidere projecten:
https://packagist.org/packages/symfony/security
Dan hoef je ook niet te klooien met custom hashing methodes en weet ik het wat.
Mocht je wat minder ervaren zijn op het gebied van objectgeoriënteerd programmeren, dan zou ik je willen adviseren je hashing niet onnodig uitgebreid te maken. Een simpele hash() functie volstaat al.
https://packagist.org/packages/nette/security
Of de Symfony security component voor wat uitgebreidere projecten:
https://packagist.org/packages/symfony/security
Dan hoef je ook niet te klooien met custom hashing methodes en weet ik het wat.
Mocht je wat minder ervaren zijn op het gebied van objectgeoriënteerd programmeren, dan zou ik je willen adviseren je hashing niet onnodig uitgebreid te maken. Een simpele hash() functie volstaat al.
Ik ben geen fan van frameworks omdat:
- Als er een fout in een framework is gevonden, is jouw website automatisch ook vatbaar.
- Je vaak meer dan de helft van de code van een framework niet gebruikt.
- Je iets niet leert als je iemand anders het laat doen.
- Je het framework moet bijhouden voor updates.
OOP is geen probleem, ik had alleen deze vraag aangezien ik deze gegevens anders behandelde. Dit zit er gewoon heel simpel uit.
Termination nvt op 12/08/2015 16:57:05:
Volgens php.net:
Dus, je hash is constant anders omdat er een random salt gegenereerd word, welke in de versleutelde string "verstopt" zit.
Je kunt ook zelf een salt meegeven via de options (word sterk afgeraden!), dan zal de hash steeds het zelfde zijn. De aanwezigheid van de salt maakt voor password_verify overigens niet uit, deze zal de verschillende hashes allemaal als geldig beschouwen.
Bron: http://php.net/password_hash
Edit:
De kans op collissions is denk ik te verwaarlozen, bcrypt is een prima algorithme mits goed gebruikt. (zie hier voor tips)
Opslaan in de database? ja. Zonder risico? helaas onmogelijk, er is niets zonder risico. Hoewel het in dit geval wel een erg klein risico is.
Quote:
The used algorithm, cost and salt are returned as part of the hash. Therefore, all information that's needed to verify the hash is included in it. This allows the password_verify() function to verify the hash without needing separate storage for the salt or algorithm information.
Dus, je hash is constant anders omdat er een random salt gegenereerd word, welke in de versleutelde string "verstopt" zit.
Je kunt ook zelf een salt meegeven via de options (word sterk afgeraden!), dan zal de hash steeds het zelfde zijn. De aanwezigheid van de salt maakt voor password_verify overigens niet uit, deze zal de verschillende hashes allemaal als geldig beschouwen.
Bron: http://php.net/password_hash
Edit:
De kans op collissions is denk ik te verwaarlozen, bcrypt is een prima algorithme mits goed gebruikt. (zie hier voor tips)
Opslaan in de database? ja. Zonder risico? helaas onmogelijk, er is niets zonder risico. Hoewel het in dit geval wel een erg klein risico is.
Hmm, het zal dan wel even wennen voor mij zijn zoals hierboven ook al gezegd, het ziet er gewoon te simpel uit. Ik ga het erin bouwen en hou rekening met een update zodat ik het gebruikt algoritme en de cost uit de hashed string knip en dus alleen de hash op sla. Ik vind het te gevoelige gegevens om deze open en bloot weer te geven mocht er een database dump gebeuren. Zonder deze gegevens word het nog een stap moeilijker om het uit te lezen.
Normaliter gebruik je ook een salt. Nu is de salt echter verwerkt in de complete hash. Bij iedere hash is de salt nu anders waardoor het voor een hacker veel en veel lastiger is om de wachtwoorden te kraken.
Het mooie van dit systeem is dat wanneer wij allebei als wachtwoord "aap" zouden hebben, dit uit de hash niet kan worden afgeleid, omdat we allebei een verschillende salt hebben. Zou je slechts 1 salt hebben, dan zou onze hash er hetzelfde uitzien. Dit hele systeem is dus slimmer dan je denkt ;)
Johan K op 12/08/2015 18:05:26:
Ik vind het te gevoelige gegevens om deze open en bloot weer te geven mocht er een database dump gebeuren.
Euh, als je er niet van uit kunt gaan dat de gegevens in je database niet veilig zijn dan ben je hoe dan ook nergens meer veilig?
En anders bouw je een ondergrondse atoombunker met 2m dikke loodgevoerde muren waarin je een ontkoppeld netwerk hebt waarbij alle data + de verzending encrypted is via een draadje... ik bedoel, hoe ver wil je gaan?
Je moet beveiliging ook niet willen regelen met een single line of defense maar met lagen. Ook al heb je nog zo'n mooie oplossing met _hash() en _verify() functies (daarbij: komt PHP eens een keer met een simpele oplossing omdat de community steen en been klaagt dat het allemaal te moeilijk is, is het nog niet goed?) maar is je site vatbaar voor XSS of wat dan ook dan ga je waarschijnlijk alsnog de boot in.
En als je je zelf met security gaat bezig houden is het zaak dat je van de hoed en de rand weet. Als je niet precies weet hoe bovengenoemde functies werken, zoek er eens wat op en lees (verschillende) artikelen en kijk wat deze zeggen...
Daarnaast gebruik je waarschijnlijk al meerdere frameworks. Denk aan het besturingssysteem, PHP zelf, de webserver en alle modules die daarop inhaken, alle native PHP libraries die je waarschijnlijk gebruikt, etc.
Kan me wel voorstellen dat je voor educatieve doeleinden zoveel mogelijk zelf wil schrijven, maar goed.
Tot zover :P Succes met je security dingetje. Houd het in elk geval maar klein en simpel ;)