password_verify werkt niet

Allereerst, heb je vastgesteld dat je PHP-versie nieuw genoeg is? Minimale versie is 5.5.0.

Vervolgens, heb je al het een en ander gedebugged? Is het loginscript verder foutvrij?

En dan maak je je het jezelf wel erg moeilijk met het kopiëren van allerlei variabelen.

Ook lijkt het mij niet nodig dat je $_POST['ww'] escaped (en trimt?) omdat je deze variabele toch niet in een SQL-passage stopt.

Daarnaast controleer je niet of je query wel resultaten heeft (of liever gezegd, precies één resultaat oplevert).

Het ophalen van alle kolommen is wellicht ook overkill als je enkel het wachtwoord en/of enkele andere kolommen nodig hebt.

Maak anders eerst eens een heel simpel test scriptje:

<?php
$hash = password_hash('test', PASSWORD_BCRYPT, ['cost' => 12]);


if (password_verify('test', $hash)) {
    echo 'cake';
} else {
    echo 'no cake';
}
?>[end]

Hier zou:

Citaat

cake[end]

Uit moeten rollen.

Dat klopt ook want je krijgt een gehashde variant retour waar een salt op is toegepast. Je berekent dus een eindresultaat op grond van een aantal cryptografische bewerkingen. Vervolgens test password_verify() of er een gelijkwaardig (maar dus mogelijk verschillend) resultaat berekend kan worden met behulp van het oorspronkelijke wachtwoord en een hash hiervan waar deze functie ook weer informatie uit kan halen zodat deze weet hoe er met het oorspronkelijke wachtwoord gerekend dient te worden.

Zet het maar eens in een loop:

<?php
for ($i=0; $i < 10; $i++) {
    $hash = password_hash('test', PASSWORD_BCRYPT, ['cost' => 12]);
    echo $hash.'<br>';
    if (password_verify('test', $hash)) {
        echo 'cake<br>';
    } else {
        echo 'no cake<br>';
    }
}
?>[end]

Dit levert bijvoorbeeld:

$2y$12$Ge6qV1J4r9HjcTe4oIgzsO5ZIIyWTFMNQb676T.u638FKVBsDA.Xa
cake
$2y$12$XnzXjpNecdXnrvnRdIibGOK5cKPBPnDLz24GaGcnaRSgpT8rzTzla
cake
$2y$12$2G302P20vFq.SFuv5GrLw.6KeXVePjZE8Wg7HTalYdDv1stJXsKhK
cake
$2y$12$VLP2U1Tz1Cfxa37UkpNewe.QfGB4z.6QU9gilP4C/4dXKm7PhHf32
cake
$2y$12$5dNoalz/vcPZ4ZG8hLv6geu85yahCrPWu3AOz4TpjFEJZG4Cozj4y
cake
$2y$12$lgSfDga67v605rAqK5wghuhiRmfiY.GU.gTSI5Uf.i..1y9JkJSqi
cake
$2y$12$Z1owJcJNHdXUtE6S7S..zua9nXLhvmdig9Bs7To0IU1JEnmXj7wOm
cake
$2y$12$SFtBrblTprcYiTVtfifbAusvi1KcDVzyDuvcJsjDRMa8jTODWIX3.
cake
$2y$12$eg1prXKjujZiIpKoEdjbKe6UU7c6EfuNFRlTblhKqMGcdYH5Civ6O
cake
$2y$12$xg8RzhNVqkvYuls.M6tKTuZTmRkTxlMIvtBEN63hg233Vo4FRQzN.
cake
[end]

Laten we het eens over een andere boeg gooien. Waaruit blijkt dat je login-functionaliteit niet werkt, je zegt dat je een melding krijgt dat de wachtwoorden niet overeenkomen? Het enige wat je hoeft te doen is te kijken wat password_verify() teruggeeft. Als dit true is, dan was het (oorspronkelijk) ingevoerde wachtwoord juist.

De hashes verschillen als het goed is dus altijd, maar password_verify() toetst of deze gelijkwaardig zijn.

Okay, dat werkt misschien, maar dat verklaart niet waarom het voorheen niet werkte.

Er begint mij al iets te dagen.

Hoe was het wachtwoord opgeslagen in de database?
Hoe luidt de kolomdefinitie voor deze wachtwoord-hash? (heeft deze genoeg ruimte?)
Genereer je de hash (gegenereerd met behulp van het wachtwoord uit het loginformulier) op dezelfde manier als bij de opgeslagen wachtwoord-hash het geval was? Dat wil zeggen, met hetzelfde algoritme en ook dezelfde opties?
Escape je de DATA-delen in de SQL-query met de daarvoor bestemde escaping-functies?
Komen overal (database, database-connectie, formulier-data, HTML-bestand en -headers?) de gebruikte character encoderingen overeen?

Het lijkt mij zeer belangrijk dat je niet alleen zorgt dat iets werkt, maar ook dat je snapt wat er gebeurt en daarmee ook kunt verklaren waarom het werkt. Simpelweg omdat iets werkt, maakt het nog niet juist.

EDIT:
De bovenstaande code lijkt mij onjuist. Het lijkt erop dat je een onversleuteld wachtwoord ophaalt uit de database en het wachtwoord uit je formulier hasht? Is dit niet de omgekeerde wereld? Het hele idee van password_hash() is juist dat je wachtwoorden versleuteld opslaat en deze daardoor nooit naar het origineel te herleiden zijn. In een loginformulier zou dus ook nooit password_hash() moeten voorkomen, maar enkel password_verify() waarbij je het wachtwoord (uit het formulier) verifieert aan de hand van de hash (uit de database).

Daarnaast controleer je nog steeds niet of $inlog resultaten oplevert...

Zorg eens voor wat debugging zodat je precies achterhaalt wat er misgaat? Dit lijkt mij nogal belangrijk.

Citaat van Kevin

Ik heb debugging uitgevoerd op alle connecties en data binnen het script. De mogelijkheid die ik nu heb toegepast werkt naar behoren. Waarom PASSWORD_BCRYPT niet werkt(te) ben ik nog niet uit.

Maar heb je dat nu al in afzondering getest, zonder tussenkomst van een database?

Het doel van debugging is mede om dingen uit te sluiten. Met een test die geen database gebruikt, dus gewoon een test met password_hash() i.c.m. PASSWORD_BCRYPT en password_verify() kun je uitsluiten of het nu echt hier aan ligt. En dit lijkt mij onwaarschijnlijk, omdat PASSWORD_DEFAULT standaard ook van bcrypt gebruik maakt. Dit kun je ook aan de hash zien, hier zit namelijk het algoritme en de cost in verwerkt. En dit kun je ook testen.

<?php
// levert bijvoorbeeld $2y$10$zrgHKhyvih.WoEt5mB85X.zG1/TOOyN1xJURjQXhfTGis4JvbncbC
echo password_hash('test', PASSWORD_DEFAULT);
// levert bijvoorbeeld $2y$10$8EbRJ99.CHc0vkdinYD8uOuOiQ2ZETvzCIW6IT1NTvSrCvosOzXaO
echo password_hash('test', PASSWORD_BCRYPT);
?>

(NB in het bovenstaande fragment zijn het algoritme en de cost identiek, ondanks het feit dat je verschillende algoritme-constantes opgeeft)

Voer deze test eens uit op jouw webserver en kijk of de algoritmes ($2y$) of de cost ($10$) van elkaar verschillen.

En zelfs dat zou niet uit moeten maken, want de enige plaats waar je password_hash() gebruikt is bij het opslaan of wijzigen van het wachtwoord. Moet je wel deze zelfde hash als uitgangspunt nemen om het gehashde wachtwoord opnieuw te berekenen met password_verify() uiteraard. Dus als de bovenstaande test verschillende resultaten oplevert en je gebruikt dan een andere hash als waarmee de wachtwoord-hash is opgesteld... tja, dan ben je toch echt appels met peren aan het vergelijken.

Dus, ik vermoed nog steeds dat er iets bij het opslaan of uitlezen van je database-data misgaat.

Gewoon maar van algoritme wisselen omdat je niet weet wat er misgaat... weet niet of dat slim is :/.

Haal is de ucfirst en strtolower weg van u loggie. Misschien vindt hij de juiste gebruikersnaam niet

Citaat van Ferhat.Remory

Haal is de ucfirst en strtolower weg van u loggie. Misschien vindt hij de juiste gebruikersnaam niet

Sja hij controleert sowieso niet of er precies één resultaat is. Hij haalt meteen een resultaat op :/.

Citaat van Kevin

Ik heb wel een aanpassing gedaan in het opslaan van het wachtwoord (hash) met de database, met de aanpassing wordt het wachtwoord opgeslagen en geeft de code voor het inloggen nu een goed resultaat.

Wellicht interessant voor de kijkers thuis wat deze aanpassing nu precies was. Controleer je nu ook of je precies één resultaat hebt voordat je je query-resultaten ophaalt bij het inloggen? Het lijkt mij nogal belangrijk dat dit alles 100% correct geschiedt (vooral als het de veiligheid en beveiliging van je website betreft), hier enkel hash/verify saus overheen gooien lijkt mij onvoldoende. Misschien is het ook interessant om wat code te plaatsen hoe alles er nu ongeveer uitziet?

En bottom line was dus (inderdaad) dat het geen probleem was met password_hash() / password_verify() maar een issue ergens onderweg met je database. Het is belangrijk dat dit soort "waarheidsvinding" op een goede en grondige manier gebeurt, want hier leer je gewoon het meeste van.