password_hash & password_verify

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Johan K

Johan K

12/08/2015 16:26:48
Quote Anchor link
Ik ben al een tijdje bezig geweest om op te zoeken wat nou een goede manier is om wachtwoorden op te slaan en liep tegen de nieuwe PHP functies, password_hash & password_verify aan. Nu heb ik gezocht naar scriptjes om te kijken hoe deze functies gebruikt worden en natuurlijk ook even zelf mee gespeelt maar ik vat het niet helemaal.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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

?>


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?
 
PHP hulp

PHP hulp

29/03/2024 02:44:52
 
Richard Snijders

Richard Snijders

12/08/2015 16:38:07
Quote Anchor link
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.
 
Thom nvt

Thom nvt

12/08/2015 16:57:05
Quote Anchor link
Volgens php.net:

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
 
Johan K

Johan K

12/08/2015 18:05:26
Quote Anchor link
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.

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:

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.
 
Ozzie PHP

Ozzie PHP

12/08/2015 20:32:10
Quote Anchor link
>> Ik vind het te gevoelige gegevens om deze open en bloot weer te geven mocht er een database dump gebeuren.

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 ;)
 
Thomas van den Heuvel

Thomas van den Heuvel

12/08/2015 21:23:43
Quote Anchor link
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...
 
Richard Snijders

Richard Snijders

12/08/2015 21:28:52
Quote Anchor link
Het zijn libraries he, geen framework :p
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 ;)
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.