[PHP] MD5 -probleem

[edwin.pw]

Ik ben nu al enkele uren aan het strijden met MD5.
Via een PHP-sript haal ik gegevens uit een .dbf bestand van een server en zet ik naar mij mySQL-database.
Echter moeten een aantal van deze gegevens niet even gauw te achterhalen zijn, dus wil ik deze via MD5 gehashed in de database plaatsen.

Hier een stukje code:

PHP: naardb.php

 echo "<br/> $arr[$a]";
$var = $arr[$a];
$arrayvar = mysql_real_escape_string(md5($var));
echo "<br/> $arrayvar <br/>";
echo md5('3959 AM');

echter krijg ik bij het laden de volgende output:

code: naardb.php

3959 AM
81a87e3e9e462ab3d5c43f63546357a3 
f94254fe839b304e104dc595a922d841

ik kom er maar niet uit waarom dit niet overeenkomt, weet iemand hier raad mee of heeft er iemand tips om dit op te lossen?

[Verwijderd]

mysql_real_escape_string hoef je NIET te gebruiken, omdat md5 toch alleen maar a-z en 0-9 als uitkomst geeft.

Doe es een var_dump($var);.

[Osiris]

Grote kans dat d'r misschien nog een trailing \r of \n of \r\n of iets dergelijks achteraan komt. (Achter $var that is)

[ Voor 10% gewijzigd door Osiris op 25-09-2009 16:06 ]

[YopY]

Ik zou zeggen: Probeer eerst eens je testcase te versimpelen:

* Wat gebeurt er als je:

PHP:

$mijnarr = array('3959 AM');
echo md5(mijnarr[0]);
echo md5('3959 AM');

doet?

Wat zegt

PHP:

echo $arr[$a] === '3959 AM';

?

* Wat doet mysql_real_escape_string met een MD5 hash? Is dit echt nodig? (Antwoord: nee, een MD5 hash bevat geen karakters die geescaped hoeven te worden)

Etc.

[NMe]

Osiris schreef op vrijdag 25 september 2009 @ 16:06:
Grote kans dat d'r misschien nog een trailing \r of \n of \r\n of iets dergelijks achteraan komt. (Achter $var that is)

Lijkt me ook.

Los daarvan, het lijkt erop dat je postcodes aan het hashen bent. Weet je zeker dat dat is wat je wil? Hashes zijn niet omkeerbaar, je kan hooguit een andere hash van een postcode ermee vergelijken, maar dat lijkt me bij iets als een postcode niet echt bruikbaar omdat die sowieso niet uniek is.

[edwin.pw]

Verwijderd schreef op vrijdag 25 september 2009 @ 16:04:
mysql_real_escape_string hoef je NIET te gebruiken, omdat md5 toch alleen maar a-z en 0-9 als uitkomst geeft.

Doe es een var_dump($var);.

de var_dump geeft me: string(10) "3959 AM "
Hier klopt iets niet, er lijkt zowiezo een spatie te staan na AM
En klopt dat 10 wel of betekend dit dat de aanhalingstekens in de array zitten?

@YopY
Deze werkt wel gewoon

[Verwijderd]

De quotes tellen niet mee . Er staan inderdaad (meerdere) spaties achter. Met $var = trim($var) verwijder je deze, succes!

[ Voor 5% gewijzigd door Verwijderd op 25-09-2009 16:16 ]

[japaveh]

Er staat nog een space achter die postcode.

edit: spuit 11

[ Voor 17% gewijzigd door japaveh op 25-09-2009 16:16 ]

[MueR]

string (10). Dat geeft aan dat er 10 tekens in zitten. in "3959 AM" tel ik er 7. Je hebt dus witruimte voor/achter de postcode zitten. Gooi daar eens trim() langs.

[edwin.pw]

Verwijderd schreef op vrijdag 25 september 2009 @ 16:16:
De quotes tellen niet mee . Er staan inderdaad (meerdere) spaties achter. Met $var = trim($var) verwijder je deze, succes!

YES, hartelijk bedankt
het leuke is dat ik vannacht het probleem zocht bij verschillende MD5-classes voor Flash..
Kan ik in ieder geval weer verder, bedankt allemaal !

[NMe]

Krieky schreef op vrijdag 25 september 2009 @ 16:20:
[...]

YES, hartelijk bedankt
het leuke is dat ik vannacht het probleem zocht bij verschillende MD5-classes voor Flash..
Kan ik in ieder geval weer verder, bedankt allemaal !

Ik zou me eerder druk maken over hoe die extra tekens daar komen voordat ik blij zou zijn met de oplossing.

Had je mijn eerdere reply nog gelezen?

[.oisyn]

NMe schreef op vrijdag 25 september 2009 @ 16:08:
Hashes zijn niet omkeerbaar, je kan hooguit een andere hash van een postcode ermee vergelijken, maar dat lijkt me bij iets als een postcode niet echt bruikbaar omdat die sowieso niet uniek is.

Hashes van postcodes zijn zo goed als omkeerbaar. Je hebt 2¹²⁸ verschillende hashes, maar maar 10.000 * 26 * 26 verschillende postcodes. De kans dat daar een collision tussen zit is ontiegelijk klein, en een brute force is natuurlijk binnen een seconde gepiept

Ik ben dus ook wel benieuwd wat je doel nu is

[ Voor 4% gewijzigd door .oisyn op 25-09-2009 16:55 ]

[NMe]

.oisyn schreef op vrijdag 25 september 2009 @ 16:54:
[...]

Hashes van postcodes zijn zo goed als omkeerbaar. Je hebt 2¹²⁸ verschillende hashes, maar maar 10.000 * 26 * 26 verschillende postcodes. De kans dat daar een collision tussen zit is ontiegelijk klein, en een brute force is natuurlijk binnen een seconde gepiept

De kans is ontiegelijk klein maar niet afwezig. Los daarvan is het omkeren van een hash niet de bedoeling van hashen, dus zelfs als het kán doordat je met wat vaste parameters werkt is het nog steeds geen good practice.

[.oisyn]

Euh, nu draai je de boel om. Je zegt dat het niet de bedoeling is dat je de hash omkeert. Helemaal waar, maar als je input set louter uit postcodes bestaat kun je 'm wel omkeren (ergo, hashes zijn niet geschikt). Je kunt als iemand dat doet dan niet zeggen "ja, maar ho eens even, dat mag niet, want daar zijn hashes niet voor bedoeld"

[ Voor 5% gewijzigd door .oisyn op 25-09-2009 17:07 ]

[NMe]

.oisyn schreef op vrijdag 25 september 2009 @ 17:07:
Euh, nu draai je de boel om. Je zegt dat het niet de bedoeling is dat je de hash omkeert. Helemaal waar, maar als je input set louter uit postcodes bestaat kun je 'm wel omkeren (ergo, hashes zijn niet geschikt). Je kunt als iemand dat doet dan niet zeggen "ja, maar ho eens even, dat mag niet, want daar zijn hashes niet voor bedoeld"

Ik bedoelde eigenlijk dat hij dat zelf niet moet willen proberen te doen. Ik heb het nog niet eens over mensen met kwade bedoelingen. Voor die laatste groep is deze hash inderdaad een onterecht gevoel van veiligheid.

[.oisyn]

NMe schreef op vrijdag 25 september 2009 @ 17:18:
[...]

Ik bedoelde eigenlijk dat hij dat zelf niet moet willen proberen te doen.

Oh op die manier. Nee, idd, helemaal mee eens

[edwin.pw]

Haha de reden waarom ik postcodes aan het hashen ben:

Ik ben een inlogsysteem aan het creëren voor het Flash-CMS voor mijn klant.
Deze klant heeft voor zijn administratie e.d. een database programma, de bijbehorende dbase-files heb ik zo gemaakt dat ze na wijziging automatisch online komen. Zo hoeft de klant nooit handmatig zijn voorraad of nieuwe klanten online te zetten.
Deze dbase-files zet ik m.b.v. een php-file in de mySQL-database.
Een van de dingen die ik hier uithaal zijn de alle klantengegevens.

De eerste keer kunnen de klanten inloggen met een combinatie van bedrijfsnaam,klantnummer en bijbehorende postcode. Hierna kunnen ze een account aanmaken.
Echter maakt deze eerste keer gebruik van hetzelfde inlogsysteem als het inloggen dmv accountnaam + wachtwoord.
In mijn php-file onderzoekt hij pas of de ingevulde gegevens gelijk zijn voor een nieuw account of een bestaand account. Nu besloot ik hier gister beveiliging in te bouwen, omdat zomaar alles open overgooien naar een mySQL een schande is.

Dit is de reden dat ik postcode's moest hashen

[.oisyn]

Ik zie een hele lap tekst, maar de reden om postcode's te hashen staat er niet tussen hoor

.edit: of bedoel je dat je de NAW gegevens eigenlijk helemaal niet in de MySQL database wilt hebben, maar wel nodig hebt om de accounts te koppelen?

[ Voor 44% gewijzigd door .oisyn op 25-09-2009 17:42 ]

[NMe]

Dat is alleen zinnig als je een MD5(password + postcode) doet, liefst zelfs nog met een salt. Een MD5 van een postcode alleen is absoluut niet zinnig in elk geval.

[edwin.pw]

NMe schreef op vrijdag 25 september 2009 @ 17:42:
Dat is alleen zinnig als je een MD5(password + postcode) doet, liefst zelfs nog met een salt. Een MD5 van een postcode alleen is absoluut niet zinnig in elk geval.

Nee klopt, maar stel dat ze de postcode achterhalen, dan hebben ze nog niets. Omdat dan meestal in 5 minuten een account wordt aangemaakt en de eerste methode niet meer werkt

Hoe werkt overigens zo'n salt?

[--MeAngry--]

En waarom is alles open naar een MySQL DB gooien slecht? Als PHP en MySQL op dezelfde bak draaien, maakt het al helemaal weinig uit.
De ingevulde gegevens worden toch ongecodeerd naar de server gestuurd tenzij je SSL gebruikt, dus ik zie het nut echt niet.

Dat je wachtwoorden gehashed in de database opslaat snap ik nog voor het geval dat je database 'gehackt' wordt, maar om een postcode te vergelijken...

[edwin.pw]

--MeAngry-- schreef op vrijdag 25 september 2009 @ 17:45:
En waarom is alles open naar een MySQL DB gooien slecht? Als PHP en MySQL op dezelfde bak draaien, maakt het al helemaal weinig uit.
De ingevulde gegevens worden toch ongecodeerd naar de server gestuurd tenzij je SSL gebruikt, dus ik zie het nut echt niet.

Dat je wachtwoorden gehashed in de database opslaat snap ik nog voor het geval dat je database 'gehackt' wordt, maar om een postcode te vergelijken...

Hetgeen wat ingetypt wordt in het inlogvenster binnen de flash-applicatie wordt gehashed om te voorkomen dat het open en bloot wordt gestuurd naar de php-file, dus kan de aangelinkte php-file niet meer controleren of het een postcode is of niet.

[NMe]

Krieky schreef op vrijdag 25 september 2009 @ 17:44:
[...]

Nee klopt, maar stel dat ze de postcode achterhalen, dan hebben ze nog niets. Omdat dan meestal in 5 minuten een account wordt aangemaakt en de eerste methode niet meer werkt

Waarom hash je dan nog?

Hoe werkt overigens zo'n salt?

Wikipedia: Salt (cryptography)

[edwin.pw]

Volgens mij heeft zo'n salt niet echt veel zin, aangezien ik deze dan in de .as-files moet plaatsen.
Zodra er iemand kwaadaardige bedoelingen heeft kan die net zo goed mijn .swf proberen te de-compilen.,

[NMe]

Krieky schreef op vrijdag 25 september 2009 @ 18:03:
Volgens mij heeft zo'n salt niet echt veel zin, aangezien ik deze dan in de .as-files moet plaatsen.
Zodra er iemand kwaadaardige bedoelingen heeft kan die net zo goed mijn .swf proberen te de-compilen.,

Zo'n salt maak je natuurlijk account-afhankelijk en plaats je in de database.

[Orion84]

Krieky schreef op vrijdag 25 september 2009 @ 17:50:
[...]


Hetgeen wat ingetypt wordt in het inlogvenster binnen de flash-applicatie wordt gehashed om te voorkomen dat het open en bloot wordt gestuurd naar de php-file, dus kan de aangelinkte php-file niet meer controleren of het een postcode is of niet.

Je beseft je dat iemand die de verzonden hash onderschept deze net zo goed opnieuw kan sturen als wanneer hij een plain wachtwoord had onderschept?

Maargoed, een gebruiker vult dus in die flash applicatie een wachtwoord in, of een postcode, indien er nog geen wachtwoord is aangemaakt. Wachtwoord of postcode wordt gehasht en wordt op de server vergeleken met de hash van het wachtwoord, of de hash van de postcode. Tsja, opzich niet heel idioot om dat allemaal een beetje symmetrisch te houden.

[edwin.pw]

NMe schreef op vrijdag 25 september 2009 @ 18:06:
[...]

Zo'n salt maak je natuurlijk account-afhankelijk en plaats je in de database.

Dan zal ik toch op een bepaalde wijze deze salt uit mijn database binnen mijn flash-applicatie moeten krijgen, waardoor ik alsnog accountgegevens zonder salt moet oversturen naar een php, waardoor ik er niets mee opschiet.
Ik snap dat dit binnen php of een andere server-based programmeertaal makkelijk te doen is, maar aangezien flash de gegevens op een bepaalde wijze moet oversturen naar een php-file zal 'de salt' zich in de flash-applicatie moeten bevinden, waardoor deze weer makkelijk te achterhalen is.
Ik had ook graag anders gezien, maar volgens mij kan binnen flash hetgeen niet beter beveiligd worden dan enkel MD5.

[edwin.pw]

Orion84 schreef op vrijdag 25 september 2009 @ 18:12:
[...]

Je beseft je dat iemand die de verzonden hash onderschept deze net zo goed opnieuw kan sturen als wanneer hij een plain wachtwoord had onderschept?

Shit, daar had ik nog niet eens aan gedacht. Ik zie nu idd dat wanneer je deze link invoer de klanteninformatie vrijgegeven wordt (email,adres, ed), misschien dat ik het hele zooitje dan ook maar moet laten lopen via SWX, die volgens mij een eigen beveiliging heeft.

[Orion84]

Nogmaals: een MD5 hash van een wachtwoord over een onbeveiligde verbinding sturen is net zo (on)veilig als het wachtwoord zelf. Als je het echt wat serieuzer aan wilt pakken kan je het versturen van het wachtwoord beter beveiligen door een SSL verbinding te gebruiken.

Het hashen kan je hoe dan ook net zo goed aan de server overlaten en dat geeft je dan meteen de mogelijkheid om salts toe te passen, voor het onfortuinlijke geval dat de inhoud van de database op straat zou komen te liggen.

Edit: en toen had je m'n post ineens wel gezien

[ Voor 5% gewijzigd door Orion84 op 25-09-2009 18:27 ]

[Osiris]

Challenge-response kan wel though

[Orion84]

Osiris schreef op vrijdag 25 september 2009 @ 18:35:
Challenge-response kan wel though

Dat is inderdaad ook een manier om het risico van een replay-attack te beperken