Ein schon ein etwas \u00e4lteres Ph\u00e4nomen, welches mir demletzt erneut \u00fcber den Weg gelaufen ist und ich es deswegen f\u00fcr „verbloggenswert“ halte:<\/p>\n
\nif (md5('240610708') == md5('QNKCDZO'))\n{\necho "yep equal";\n}\n<\/pre>\nUps? Eine MD5-Kollision<\/a>? Nein. Eine Eigenart von PHP.<\/p>\n\nvar_dump(md5('240610708')); \/\/string(32) "0e462097431906509019562988736854"\nvar_dump(md5('QNKCDZO')); \/\/string(32) "0e830400451993494058024219903391"\n<\/pre>\n2 verschiedene Strings, die aber laut PHP-Vergleich identisch sein sollen? Genau da liegt der Knackpunkt: Die Strings sind gleich<\/b>, aber nicht identisch<\/b>. Da beide mit 0e<\/i> anfangen, werden sie als Exponentialdarstellung einer Zahl aufgefasst. Und da 0irgendwas<\/sup> immer 0 ergibt, sind die beiden Hashes im Vergleich auch gleich.<\/p>\nDas „Problem“ l\u00e4sst sich einfach l\u00f6sen, indem mit ===<\/i> verglichen wird. Dann evaluiert PHP den Zahlenwert des Strings nicht mehr. Oder indem strcmp<\/a> verwendet wird:<\/p>\n\nvar_dump(strcmp(md5('240610708'), md5('QNKCDZO'))); \/\/int(-1)\n<\/pre>\nSHA und Konsorten sind f\u00fcr diese Problematik genau so anf\u00e4llig<\/a>, es ist nur entsprechend unwahrscheinlicher, dass es zu solch einem „0e“-Ph\u00e4nomen kommt. In der Praxis h\u00e4tten Angreifer also eine bessere Chance, wenn zu „0e“ evaluierende Hashes beim Bruteforcen vorrangig probiert werden. Aber auch dann ist der Angriff selbstverst\u00e4ndlich von der Nachl\u00e4ssigkeit des Entwicklers abh\u00e4ngig: Sobald mit ===<\/i> verglichen wird (bzw. ein „ordentliches“ Hash-Verfahren wie bcrypt mit Salt verwendet wird) sieht es d\u00fcsterer aus.<\/p>\n","protected":false},"excerpt":{"rendered":"Ein schon ein etwas \u00e4lteres Ph\u00e4nomen, welches mir demletzt erneut \u00fcber den Weg gelaufen ist und ich es deswegen f\u00fcr „verbloggenswert“ halte: if (md5('240610708') == md5('QNKCDZO')) { echo "yep equal"; } Ups? Eine MD5-Kollision? Nein. Eine Eigenart von PHP. var_dump(md5('240610708')); … Weiterlesen