Mein Loginscript so sicher?

Zitat von wahsaga

SELFHTML Forumsarchiv / 2009 / Mai / mysql_real_escape_string und md5 (PHP)

Mag sein ... was man argumentieren kann, kann ich schon lange ... also, wenn man davon ausgeht, dass md5() in Zukunf sich in irgendwas sonst entartet, dann kann ich genauso sagen, dass man bei mysql_real_escape_string() genauso erwarten kann ... irgendwo muss man schon darauf vertrauen können, dass die Leute, die sowas entwickelt, keine Idioten sind, ansonstens kannste alles vergessen und dein Software in die Mülltone treten.

Zitat von asp2php

Mag sein ... was man argumentieren kann, kann ich schon lange ... also, wenn man davon ausgeht, dass md5() in Zukunf sich in irgendwas sonst entartet, dann kann ich genauso sagen, dass man bei mysql_real_escape_string() genauso erwarten kann ... irgendwo muss man schon darauf vertrauen können, dass die Leute, die sowas entwickelt, keine Idioten sind, ansonstens kannste alles vergessen und dein Software in die Mülltone treten.

Du hast das Argument nicht ganz verstanden.
mysql_real_esacpe_string macht immer das, was seine Aufgabe erfordert - Sonderzeichen maskieren, so dass sie keinen Schaden anrichten. Wenn da bei MySQL irgendwann Zeichen hinzukommen sollten, wird eine der neuen API angepasste Version von mysql_real_escape_string das auch handeln, da muss ich mir keine Sorgen machen.

Aber MD5 ist vielleicht zukünftig nicht mehr das, was ich will, und SHA1 wird vielleicht auch zu "schwach" - es wird also eine neue Hashfunktion zum Einsatz kommen, deren Ergebnis vielleicht auch Zeichen enthält, die für MySQL Sonderzeichen sind. Habe ich das mysql_real_escape_string an dieser Stelle schon präventiv drinstehen, muss ich daran keinen einzigen Gedanken mehr verschwenden, ich tausche MD5() durch NEUEHASHFUNKTION() aus, und gut is'. Habe ich es da hingegen noch nicht drin stehen, muss ich erst mal überlegen, ob die neue Hashfunktion eine Behandlung erfordert. Oder schlimmer noch, ich vergesse diese Überlegung - denn Projektanpassungen müssen ja immer "schnell" gehen - und vergesse auch ein evtl. notwendig gewordenes mysql_real_escape_string hinzuzufügen. Und dann habe ich plötzlich ein neues Loch in meiner Applikation - und das ist perverserweise bei dem Versuch entstanden, dass ganze sicherer zu machen (Austausch der alten, schwachen Hashfunktion durch eine neue, "bessere".)

Ich kann den Gedanken nachvollziehen, finde ihn aber voll daneben!

"Herr vergib ihnen, denn sie wissen nicht was sie tun!"

Zitat von wahsaga

Du hast das Argument nicht ganz verstanden.
mysql_real_esacpe_string macht immer das, was seine Aufgabe erfordert - Sonderzeichen maskieren, so dass sie keinen Schaden anrichten. Wenn da bei MySQL irgendwann Zeichen hinzukommen sollten, wird eine der neuen API angepasste Version von mysql_real_escape_string das auch handeln, da muss ich mir keine Sorgen machen.

Aber MD5 ist vielleicht zukünftig nicht mehr das, was ich will, und SHA1 wird vielleicht auch zu "schwach" - es wird also eine neue Hashfunktion zum Einsatz kommen, deren Ergebnis vielleicht auch Zeichen enthält, die für MySQL Sonderzeichen sind. Habe ich das mysql_real_escape_string an dieser Stelle schon präventiv drinstehen, muss ich daran keinen einzigen Gedanken mehr verschwenden, ich tausche MD5() durch NEUEHASHFUNKTION() aus, und gut is'. Habe ich es da hingegen noch nicht drin stehen, muss ich erst mal überlegen, ob die neue Hashfunktion eine Behandlung erfordert. Oder schlimmer noch, ich vergesse diese Überlegung - denn Projektanpassungen müssen ja immer "schnell" gehen - und vergesse auch ein evtl. notwendig gewordenes mysql_real_escape_string hinzuzufügen. Und dann habe ich plötzlich ein neues Loch in meiner Applikation - und das ist perverserweise bei dem Versuch entstanden, dass ganze sicherer zu machen (Austausch der alten, schwachen Hashfunktion durch eine neue, "bessere".)

OK, schön ... aber Ausgang unsere Diskussion war ...

PHP-Code:

AND password= '".md5 (mysql_escape_string($pwd))."'" 


und daher war ich nicht einverstanden. Wenn man mysql_real_escape_string(md5($value)) anwendet, dann wäre dein Argument gefestigter und ich wäre auch zufriedener