nicht angemeldet
Einfaches Passwort unverschlüsselt im PHP-Code?
suit
Der MartinHallo,
nachdem ich gerade bei einem CMS eine sehr aufwändige Kennwort-Verschlüsselung mit "Salz" angeschaut habe, mal die Frage, warum es nicht ganz einfach gehen mag: Passwort und Name unverschlüsselt im PHP-Code, Vergleich mit den Eingaben und gut ist es. Dazu noch die zu schützenden Dateien oder Verzeichnisse noch per htaccess absichern.
Worum geht es bei den aufwändigen Geschichten? Eine brute force Eingabe aller möglicher Namen und Kennwörter könnte doch so oder so irgendwann, Jahre später, Erfolg haben. Und wer den ftp-Zugang knackt, kann auch in beiden Fällen Unfug anstellen.
Geht es besonders um den Fall, dass es durch irgendwelche Lücken, etwa Suchfunktion oder Dateiausgabe, gelingt, doch an den PHP-Code (oder z.B. an htpwd) zu kommen?
Grüsse
Cyx23
-
Geht es besonders um den Fall, dass es durch irgendwelche Lücken, etwa Suchfunktion oder Dateiausgabe, gelingt, doch an den PHP-Code (oder z.B. an htpwd) zu kommen?
Genau das - das Hauptproblem ist nicht technischer natur sondern sozial. Sobald einem Administrator, Programmierer oder sonstjemandem das Klartextpasswort bekannt ist, besteht die Gefahr, dass es kompromitiert ist.
Besonders bei großen, strukturierten Daten ist da die Verlockung groß - E-Mail-Adressen in Kombination mit Passwörtern sind sehr begehrt, da es bei einem normalen Menschen sehr wahrscheinlich ist, dass er überall dasselbe Passwort verwendet.
Ob du nun ein CSV mit 20 Passwörtern hat oder eine Datenbanktabelle mit 25.000 ist da egal. Jeder Mensch hat seinen Preis, diese Daten dann am Schwarzmarkt zu verkaufen scheint garnicht so schwierig zu sein.
Darum ist es essentiell, dass bis auf den Benutzer selbst keiner das Passwort kennt und es eben nur als Prüfsumme vorliegt.
-
Hello,
Darum ist es essentiell, dass bis auf den Benutzer selbst keiner das Passwort kennt und es eben nur als Prüfsumme vorliegt.
Und wenn man will, dass es auch der gesamten Übertragungsstrecke unbekannt bleibt, sollte diese ebenfalls verschlüsslet werden, also als Tunnel aufgebaut werden.
Ich habe mir da ja neulich selber einen abgebrochen, ein Selbstzertifikat für den Apache aufzubauen, aber es ist wirklich ganz einfach, wenn man weiß wie es geht. Da gab's doch so eine Spuch:
Ulkig, kaum macht man's richtig, klappts.
Alle Anmeldedialoge, übermittlung persönlicher Daten, etc würde ich inzwischen nur noch über SSL/TLS anbieten, auch wenn man dafür nur ein Eigenzertifikat bereitstellt. Die verbleibenden Lücken liegen dann beim (korrupten) Staat, dem Provider und dem gut organisierten Verbrechen...
Liebe Grüße aus Syburg
Tom vom Berg
-
-
nachdem ich gerade bei einem CMS eine sehr aufwändige Kennwort-Verschlüsselung mit "Salz" angeschaut habe, mal die Frage, warum es nicht ganz einfach gehen mag: Passwort und Name unverschlüsselt im PHP-Code, Vergleich mit den Eingaben und gut ist es. Dazu noch die zu schützenden Dateien oder Verzeichnisse noch per htaccess absichern.
Dagegen sprechen mehrere Gründe.
a) Dein PHP-Code wird selbst zum schützenswerten Geheimnis
b) bei einem kaputten Server landet dein Passwort auf dem Bildschirm von irgend einem Request.
c) Du kannst das Passwort nicht ändern, wenn du es am schnellsten notwendig hättest.
d) Dein php liegt wohl innerhalb von http root. Ein ausgelagertes Passwortfile kann ausserhalb von http root liegen.Worum geht es bei den aufwändigen Geschichten?
Um Sicherheit und Flexibilität.
Eine brute force Eingabe aller möglicher Namen und Kennwörter könnte doch so oder so irgendwann, Jahre später, Erfolg haben. Und wer den ftp-Zugang knackt, kann auch in beiden Fällen Unfug anstellen.
Versicherungen verlangen, dass du deine Haustüre abschiesst, auch wenn das einen Einbrecher nicht abschreckt.
Geht es besonders um den Fall, dass es durch irgendwelche Lücken, etwa Suchfunktion oder Dateiausgabe, gelingt, doch an den PHP-Code (oder z.B. an htpwd) zu kommen?
Ein Server kann mal falsch funktionieren und flutsch.... da ist dein Code.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
SCNR
Versicherungen verlangen, dass du deine Haustüre abschiesst, auch wenn das einen Einbrecher nicht abschreckt.
Ach das steht wohl im Allerkleinstgedruckten, hatte ich noch gar nicht entdeckt.
Muss ich prophylaktisch schießen, oder erst wenn der Einbrecher das Brecheisen ansetzt?mfg
cygnus--
Die Sache mit der Angel und dem ><o(((°> hat immer einen Haken ...-
Hallo,
»» Versicherungen verlangen, dass du deine Haustüre abschiesst, auch wenn das einen Einbrecher nicht abschreckt.
sehr nett, ja. *g*
Ach das steht wohl im Allerkleinstgedruckten, hatte ich noch gar nicht entdeckt.
Muss ich prophylaktisch schießen, oder erst wenn der Einbrecher das Brecheisen ansetzt?Am besten genau dann, wenn der Brecher (oder ein Brecher) vor der Tür steht. Dann hört er die Schüsse, bekommt Muffensausen und flüchtet. Zweck erfüllt. ;-)
Gibt allerdings 'ne Sauerei, wenn er dann aus lauter Angst vor der Tür bricht.So long,
Martin--
Denken ist wohl die schwerste Arbeit, die es gibt. Deshalb beschäftigen sich auch nur wenige damit.
(Henry Ford, amerikanischer Industriepionier)-
»» Versicherungen verlangen, dass du deine Haustüre abschiesst, auch wenn das einen Einbrecher nicht abschreckt.
sehr nett, ja. *g*
Ach das steht wohl im Allerkleinstgedruckten, hatte ich noch gar nicht entdeckt.
Muss ich prophylaktisch schießen, oder erst wenn der Einbrecher das Brecheisen ansetzt?Am besten genau dann, wenn der Brecher (oder ein Brecher) vor der Tür steht. Dann hört er die Schüsse, bekommt Muffensausen und flüchtet. Zweck erfüllt. ;-)
Gibt allerdings 'ne Sauerei, wenn er dann aus lauter Angst vor der Tür bricht.Jaja, immer diese Schüsselkinder...
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hallo :)
Gibt allerdings 'ne Sauerei, wenn er dann aus lauter Angst vor der Tür bricht.
Jaja, immer diese Schüsselkinder...
So, Kinder hat der also auch.
Ich erinnere mich genau, da war doch diese Frühstücksaffäre mit Schüssel?mfg
cygnus--
Die Sache mit der Angel und dem ><o(((°> hat immer einen Haken ...
-
-
-
-
-
Ein Punkt wurde noch nicht genannt. Falls auch Paßwörter für andere Leute gespeichert werden, sollen die im Nachhinein nicht unbedingt leicht ausgelesen werden können.
-
Hallo,
danke für die Antworten.
Ein einfache Verschlüsselung und das Passwort vielleicht noch in eine eigene Datei - mal schauen, was als Minimalstrategie für kleine Projekte noch taugt.
Grüsse
Cyx23
-
Ein einfache Verschlüsselung
Nein, keine Verschlüsselung - eine Prüfsumme. Bei einer Verschlüsselung ist die gefahr zu groß, dass der Text wieder entschlüsselt werden kann, besonders bei einem "einfachen" Algorithmus.
Zudem spielt es keine Rolle, ob der Mechanismus einfach ist oder nicht - er muss sicher und eben idealerweise unumkehrbar sein.
-
Hallo,
Zudem spielt es keine Rolle, ob der Mechanismus einfach ist oder nicht - er muss sicher und eben idealerweise unumkehrbar sein.
Ein md5 Hash sollte doch üblicherweise reichen, obwohl, wenn ich es recht verstehe, jedem Passwort genau ein hash zugeordnet werden kann, was doch nicht nur Vorteile haben dürfte.
Grüsse
Cyx23
-
Ein md5 Hash sollte doch üblicherweise reichen, obwohl, wenn ich es recht verstehe, jedem Passwort genau ein hash zugeordnet werden kann, was doch nicht nur Vorteile haben dürfte.
Mit einem md5-Hash tust du zuminst deiner Sorgfaltspflicht genüge ;) da kann man dir jedenfalls keine Fahrlässigkeit unterstellen, sollte mal etwas abhanden kommen.
Wobei der md5-Hash bei Benutzerdaten idealerweise noch mit einem Salt versehen werden sollte.
-
Hello,
Mit einem md5-Hash tust du zuminst deiner Sorgfaltspflicht genüge ;) da kann man dir jedenfalls keine Fahrlässigkeit unterstellen, sollte mal etwas abhanden kommen.
Du meinst damit sicher, so wie bei der Telebum, oder?
Liebe Grüße aus Syburg
Tom vom Berg
-
Du meinst damit sicher, so wie bei der Telebum, oder?
Ach, da ist auch etwas abhanden gekommen? Das passiert in letzter Zeit so oft, da verliert man den Überblick xD
-
-
Hallo,
Ein md5 Hash sollte doch üblicherweise reichen, obwohl, wenn ich es recht verstehe, jedem Passwort genau ein hash zugeordnet werden kann, was doch nicht nur Vorteile haben dürfte.
Mit einem md5-Hash tust du zuminst deiner Sorgfaltspflicht genüge ;)
Ich würde eher zu gesalteten SHA-1 raten, wegen den ganzen bisherigen Angriffen auf MD5. Es gibt zwar noch keinen Angriff auf MD5, der Passwort-Hashes direkt betrifft, aber wer weiß... Ideal wäre natürlich sowas wie SHA-256 oder RIPEMD-160, da für SHA-1 zumindest theoretische Angriffe existieren (die aber weit davon entfernt sind, praktikabel zu sein). Da SHA-256 oder RIPEMD-160 aber in PHP zumindest eine zusätzliche Erweiterung benötigen, ist in Deinem Fall keine so gute Idee. Daher wäre SHA-1 (+ Salt natürlich!) die beste Wahl für Dich im Moment: Wird zum einen von PHP direkt unterstützt (Funktion sha1()) und es existieren noch keine praktikablen Angriffe.
Viele Grüße,
Christian-
Wird zum einen von PHP direkt unterstützt (Funktion sha1()) und es existieren noch keine praktikablen Angriffe.
Auch für MD5 existieren (immer noch nicht) keine praktikablen Angriffe, die es ermöglichen, einen der möglichen Klartexte eines Hashes zu berechnen. Sämtliche Möglichkeiten von Kollisionsangriffen oder gar Preimage-Angriffen sind beim "Entschlüsseln" von Passwörtern idR. zu vernachlässigen, die sind hautsächlich bei digitalen Signaturen relevant.
Nachdem es keine bekannten Preimage-Angriffsmethoden für MD5 gibt, wohlaber Kollisionen möglich sind, steht MD5 SHA-1 in diesem Punkt um nichts nach[1]. SHA-1 ist so potentiell unsicherer, da Kollisionsangriffsmöglichkeiten bestehen, wo zumindest Teile des Originaltexts übernommen werden können [2] - aber auch das spielt ansich für das unkenntlichmachen von Passwörtern keine Rolle.
Den einzigen Vorteil, den man durch SHA-1 erhält: man verschleiert den Algorithmus - dass das keine Sicherheit bedeutet, sollte aber klar sein.
[1] <http://eprint.iacr.org/2005/010 Cryptology ePrint Archive: Report 2005/010 - Update on SHA-1>
[2] SHA-1 hash function under pressure-
Hallo suit,
Wird zum einen von PHP direkt unterstützt (Funktion sha1()) und es existieren noch keine praktikablen Angriffe.
Auch für MD5 existieren (immer noch nicht) keine praktikablen Angriffe, die es ermöglichen, einen der möglichen Klartexte eines Hashes zu berechnen.
Schrieb ich ja auch. Aber MD5 hat Gegenüber SHA-1 zwei Nachteile:
1. Die Bitlänge ist geringer (128 bit vs. 160 bit). Wenn sich jetzt ein
Angriff um den Faktor 2^64 beschleunigen ließe, hätte man bei SHA-1
immer noch eine effektive Bitlänge von 2^96 bit während das bei MD5
nur noch 2^64 wären. Nur mal als Rechenbeispiel.2. Du hast natürlich vollkommen Recht, dass es keine Angriffe auf MD5
gibt, die beim Passwortknacken helfen. Mein Argument ist jedoch, dass
auf Grund der Tatsache, dass sich andere Angriffe als praktikabel
herausgestellt haben, es bei MD5 in meinen Augen viel wahrscheinlicher
ist, in naher Zukunft einen praktikablen (!) Angriff zu finden, als
bei SHA-1. Es könnte selbstverständlich auch anders herum sein, das
will ich nicht bezweifeln. Mein Wahrscheinlichkeitsargument bricht
deswegen trotzdem nicht zusammen.Natürlich hat auch SHA-1 Schwächen, Bruce Schneier hat ja schon vor Jahren davon abgeraten, deswegen verwies ich ja auch auf Alternativen. Und ich bin garantiert niemand, der jetzt aufschreit, dass man MD5 sofort ersetzen müsste, wenn es für's Passwort-Hashing verwendet wird. Mein Argument ist aber ganz simpel: Wenn man eine NEUE Software schreibt, die keine (!) Kompabilität zu alten Systemen berücksichtigen muss, dann sollte man den stärksten Hash-Algorithmus nehmen, der aktuell bekannt ist und für dieses System noch sinnvoll ist. In dem Fall wäre das vermutlich SHA-256 [1]. Allerdings ist das in diesen Gegebenheiten (PHP) problematisch, weil PHP von Haus aus keine Funktion für SHA-256 mitbringt und die Erweiterung nicht überall installiert ist. Daher muss man sich hier aus praktischen Erwägungen auf MD5 und SHA-1 beschränken. Und in dieser Situation sollte man in meinen Augen den besseren Algorithmus der beiden verwenden, nämlich SHA-1. Mehr wollte ich nicht sagen.
Den einzigen Vorteil, den man durch SHA-1 erhält: man verschleiert den Algorithmus - dass das keine Sicherheit bedeutet, sollte aber klar sein.
Warum verschleiert man den Algorithmus? SHA-1 ist doch auch öffentlich? Und ein 160bit-Hash in freier Wildbahn ist fast immer SHA-1 und sonst RIPEMD-160. Der Rest ist bei dieser Bitlänge vernachlässigbar.
Viele Grüße,
Christian[1] Sobald die SHA-3-Competition zu Ende ist, gilt diese Aussage natürlich nicht mehr.
-
Wenn man eine NEUE Software schreibt, die keine (!) Kompabilität zu alten Systemen berücksichtigen muss, dann sollte man den stärksten Hash-Algorithmus nehmen, der aktuell bekannt ist und für dieses System noch sinnvoll ist.
»» Den einzigen Vorteil, den man durch SHA-1 erhält: man verschleiert den Algorithmus - dass das keine Sicherheit bedeutet, sollte aber klar sein.Da gebe ich dir Recht, wenn man hingegen mit bestehenden Systemen kämpft, ist ein migrieren auf ein neues Hashverfahren mitunter nicht so einfach.
Warum verschleiert man den Algorithmus? SHA-1 ist doch auch öffentlich? Und ein 160bit-Hash in freier Wildbahn ist fast immer SHA-1 und sonst RIPEMD-160. Der Rest ist bei dieser Bitlänge vernachlässigbar.
Denkfehler meinerseits, ich war jetzt bei "SHA-1 = 128 bit"
-
-
-
-
-
-
-
