nicht angemeldet
mysql_real_escape_string und md5 (PHP)
Hallo zusammen,
kurze Verständnisfrage:
Bei einer Datenbankanfrage wie passwort='".mysql_real_escape_string(md5($_POST['passwort']))."'
Kann auf das mysql_real_escape_string verzichtet werden, oder?
-
Moin!
kurze Verständnisfrage:
Bei einer Datenbankanfrage wiepasswort='".mysql_real_escape_string(md5($_POST['passwort']))."'
Kann auf das mysql_real_escape_string verzichtet werden, oder?Man will nicht darauf verzichten, weil der Anblick einer Escape-Funktion einem auf den ersten Blick das Sicherheitsgefühl gibt, dass an dieser Stelle keine SQL-Injection stattfinden kann.
So ein pauschales Escaping ist viel sicherer, als wenn man sich erst im Detail überlegen muss, ob die Funktionsergebnisse von z.B. md5() in absolut jeder Situation wirklich garantiert SQL-ungefährliche Strings zurückliefern.
Stell dir einfach mal vor, im weiteren Leben der Software wird irgendwann die Funktion md5() ersetzt durch eine ganz ähnliche, aber eigene Funktion, die das Passwort verschlüsselt, z.B. hash_mich().
Und die Funktion wird dann in weiteren Entwicklungsschritten nochmal umgebaut, und durch einen dummen Fehler kommt irgendwann doch mal der String wieder im Klartext heraus, ist also dann sql-gefährlich.
Warum sollte man sich als Entwickler jetzt beim Zusammenbau des SQL auf irgendeine Diskussion einlassen wollen, ob, wann und warum die aufgerufene Funktion sichere und unsichere Strings zurückliefert? Hier pauschal Escaping anzuwenden wird NIEMALS zu Sicherheitslücken führen. Hier pauschal aus falsch verstandener Effektivitätsüberlegung auf Escaping zu verzichten wird POTENTIELL IRGENDWANN zu Problemen führen.
Als sicherheitsinteressierter Entwickler wähle ich immer die Methode, die mir NIEMALS Probleme machen wird.
- Sven Rautenberg
-
Hallo Sven,
vielen Dank, das klingt plausibel.
Gruß, Olaf
-
Hallo Sven,
So ein pauschales Escaping ist viel sicherer, als wenn man sich erst im Detail überlegen muss, ob die Funktionsergebnisse von z.B. md5() in absolut jeder Situation wirklich garantiert SQL-ungefährliche Strings zurückliefern.
Davon abgesehen, dass md5() als 'geknackt' und somit als unsicher anzusehen ist
Stell dir einfach mal vor, im weiteren Leben der Software wird irgendwann die Funktion md5() ersetzt durch eine ganz ähnliche, aber eigene Funktion, die das Passwort verschlüsselt, z.B. hash_mich().
oder die empfohlene AES-Methode.
Hier pauschal aus falsch verstandener Effektivitätsüberlegung auf Escaping zu verzichten wird POTENTIELL IRGENDWANN zu Problemen führen.
Im Prinzip vollkommen richtig, verwende ich allerdings mit Sicherheit auf eine Integer-Spalte vorher auf den Typ 'Integer' geprüfte Werte (z.B. Rechteverteilung im CMS) kann ich reinen Gewissens auf mysql_real_escape_string() verzichten.
Ganz so falsch ist der Performance-Gedanke ja nicht.
Als sicherheitsinteressierter Entwickler wähle ich immer die Methode, die mir NIEMALS Probleme machen wird.
ACK, aber das muss nicht immer mysql_real_escape_string() sein.
Grüße, Matze
-
Hi,
Davon abgesehen, dass md5() als 'geknackt' und somit als unsicher anzusehen ist
Was meinst du mit geknackt? Ist ja schliesslich nur ein Hash und kein decodierfähiger Content. Also warum sollte jemand seine üblichen Routinen mit dem, überall verfügbaren, md5() umstellen?
Die SSL Geschichte, wenn du das meinst, ist ja nun nicht gerade vergleichbar mit normaler Anwendung um zb. Passworte zu speichern.
Mario
-
Moin!
»» Davon abgesehen, dass md5() als 'geknackt' und somit als unsicher anzusehen ist
Was meinst du mit geknackt? Ist ja schliesslich nur ein Hash und kein decodierfähiger Content. Also warum sollte jemand seine üblichen Routinen mit dem, überall verfügbaren, md5() umstellen?
Weil für MD5 nun mal nicht nur theoretisch, sondern auch praktisch bewiesen wurde, dass man heute schon unter gewissen Umständen Kollisionen berechnen kann. Allein diese Tatsache sollte einen davor zurückschrecken lassen, MD5 noch ernsthaft für Sicherheitsdinge einzusetzen.
Die SSL Geschichte, wenn du das meinst, ist ja nun nicht gerade vergleichbar mit normaler Anwendung um zb. Passworte zu speichern.
Klar kann man immer argumentieren, dass die praktisch demonstrierten Angriffe ja ein ganz anderes Szenario abbilden, welches für die eigene Sicherheitsfrage irrelevant ist.
Als Gegenfrage bleibt da eigentlich nur: Wenn du die Wahl hast zwischen einem schon recht angegriffenen und bröckeligen Algorithmus wie MD5, und nach derzeitiger Kenntnis noch sehr robusten Algorithmen wie SHA1, SHA-256 etc., warum würdest du freiwillig den bröckeligen wählen wollen?
Diese Ignoranz gegenüber den theoretisch demonstrierten Angriffen hat es ermöglicht, dass der praktische Angriff bei den SSL-Zertifikaten tatsächlich durchgeführt werden konnte.
- Sven Rautenberg
-
Hi,
Weil für MD5 nun mal nicht nur theoretisch, sondern auch praktisch bewiesen wurde, dass man heute schon unter gewissen Umständen Kollisionen berechnen kann. Allein diese Tatsache sollte einen davor zurückschrecken lassen, MD5 noch ernsthaft für Sicherheitsdinge einzusetzen.
Beim Thema Passworte in DB ist sowohl der theoretische Beweis als auch der praktische Beweis völlig egal. Hier nützt das nichts, erst recht nicht wenn man das doppelt macht, md5(md5()). Ich könnte mir also kein Szenario vorstellen wo irgendein anderer Algorithmus da einen Vorteil haben könnte.
Klar kann man immer argumentieren, dass die praktisch demonstrierten Angriffe ja ein ganz anderes Szenario abbilden, welches für die eigene Sicherheitsfrage irrelevant ist.
Genau und mit eigene, beziffere ich mal den typischen Fall wo md5 eingesetzt wird, eben Passworte und sicherheitsunrelavante Sachen wie Dateinamen generieren usw...
Als Gegenfrage bleibt da eigentlich nur: Wenn du die Wahl hast zwischen einem schon recht angegriffenen und bröckeligen Algorithmus wie MD5, und nach derzeitiger Kenntnis noch sehr robusten Algorithmen wie SHA1, SHA-256 etc., warum würdest du freiwillig den bröckeligen wählen wollen?
Ganz klare Antwort, das was am häufigsten zur Verfügung steht und meine Arbeiten somit transportabler machen. Natürlich nur solange sich die MD5-Anwendungen auf die Üblichen, also bereits genannten, belaufen.
Diese Ignoranz gegenüber den theoretisch demonstrierten Angriffen hat es ermöglicht, dass der praktische Angriff bei den SSL-Zertifikaten tatsächlich durchgeführt werden konnte.
Ja, wer solche Zertifikate rausgibt und so fahrlässig handelt, ist schon ignorant zumal eine DOPPEL-MD5 vollkommen ausgreicht hätte das zu verhindern, und der chronologische Aufbau der original IDs ist auch gerade zu lächerlich gewesen das weiss schon jeder Laien-DB-Anwender, wenn er seine Daten nicht grabben lassen will. Aber der normale Webseitenersteller hat damit nichts zu tun, du baust dir ja auch keine Formel1-Sicherheits-Technik ins Auto, weil es ignorant wäre, es nicht zu tun?
Mario
-
(..)du baust dir ja auch keine Formel1-Sicherheits-Technik ins Auto, weil es ignorant wäre, es nicht zu tun?
Und was ist daran so schwer einfach AES_ENCRYPT($string, $key) zu verwenden?
Oder halt SHA...
Der Aufwand wär wohl kaum größer als bei der Verwendung von md5().
Warum also md5() und nicht gleich eine 'vernünftige' Verschlüsselung?Sicher reicht md5() für viele Aufgaben aus, es wär aber auch kein Beinbruch es sich so langsam aber sicher mal abzugewöhnen ;)
Grüße, Matze
-
Moin!
»» (..)du baust dir ja auch keine Formel1-Sicherheits-Technik ins Auto, weil es ignorant wäre, es nicht zu tun?
Und was ist daran so schwer einfach AES_ENCRYPT($string, $key) zu verwenden?
Hashing und Encryption sind zwei ganz unterschiedliche Dinge, die man nicht mischen möchte.
Oder halt SHA...
Der Aufwand wär wohl kaum größer als bei der Verwendung von md5().Das ist genau mein Argument. Warum md5() benutzen, wenn sha1() genauso simpel und einfach verfügbar ist, und nach heutigem Stand die Probleme von MD5 nicht aufweist?
- Sven Rautenberg
-
-
-
-
-
-