password_verify werkt niet

    • Binnen de SQL database heb ik de volgende gegevens van de kolom: password varchar(200).

      Lijkt mij genoeg voor een versleuteld wachtwoord. aangezien het wachtwoord 60 karakters bevat.

      Bij het aanmelden of opvragen van het wachtwoord wordt het wachtwoord versleuteld door de hash. Bij het inloggen heb ik enkel de code password_verify() staan.

      Ja ik gebruik dezelfde algoritme en ook dezelfde opties.

      Ik begrijp je conclusie, ik begrijp wat de functies en functionaliteiten zijn. niet alleen omdat het nu functioneert maar ook waarom.

      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.

    • Kevin wrote:

      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 Source Code

      1. <?php
      2. // levert bijvoorbeeld $2y$10$zrgHKhyvih.WoEt5mB85X.zG1/TOOyN1xJURjQXhfTGis4JvbncbC
      3. echo password_hash('test', PASSWORD_DEFAULT);
      4. // levert bijvoorbeeld $2y$10$8EbRJ99.CHc0vkdinYD8uOuOiQ2ZETvzCIW6IT1NTvSrCvosOzXaO
      5. echo password_hash('test', PASSWORD_BCRYPT);
      6. ?>
      (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 :/.

    • @FangorN ik heb wel degelijk mijn testen uitgevoerd. zowel met en zonder tussenkomst van de database.

      Zonder database werkt het naar behoren, met database niet.

      Ik heb gecontroleerd welke waarden uit alle koppelingen komen, zowel van de gebruikersnaam als de wachtwoorden zonder hash en met hash.

      Het begin van de algoritmes en cost zijn beide $2y$10$.

      De login-functionaliteit was opgebouwd met md5, dus werkte hiermee naar behoren, ik bouw de functionaliteit om van md5 naar password_hash().

      @Ferhat.Remory Bedankt voor je opmerking dit heb ik inderdaad al eens getest en geeft geen verschil, gebruikersnaam wordt als 1 waarde opgepakt.


      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.

      Bedankt voor jullie hulp.

    • Kevin wrote:

      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.