nicht angemeldet
MD5-Verschlüsslungübergabe an eine CGI
Guten Morgen allerseits,
Habt ihr schöne Weihnachten hinter euch??? ;-)
jetzt kehrt für mansche die Arbeitswelt zurück ;-(
Mein Ziel:
----------
Der Benutzername und das Passwort mit MD5-Verfahren zu verschlüsseln, dann an einer CGI schicken.
Mein Problem:
-------------
Ich habe auf SelfHTML ein JavaScript gefunden, welches die Benutzereingaben mit MD5-Verfahren verschlüsselt. super oder???
Aber, ich hab's nicht geschafft die verschlüsselten Strings an einer CGI zu übergeben :-(
Meine Frage:
------------
Hat mal jemand von euch es geschafft die Benutzereingaben Clientseitig zu verschlüsseln und diese werte dann an einer CGI über geben konnte.
Ich wäre froh um jeden Tipp.
Danke euch alle im Voraus und weiterhin schöne Feiertage wünscht euch x-VieW
-
Halihallo x-VieW
Der Benutzername und das Passwort mit MD5-Verfahren zu verschlüsseln, dann an einer CGI schicken.
Optional sollte man auch die Möglichkeit bieten, ohne MD5 "einzuloggen", nicht jeder hat
JS aktiviert. Wär natürlich mit MD5 sicherer, da das Pwd nicht im PlainText übertragen
wird.Ich habe auf SelfHTML ein JavaScript gefunden, welches die Benutzereingaben mit MD5-Verfahren verschlüsselt. super oder???
Ja ;)
Aber, ich hab's nicht geschafft die verschlüsselten Strings an einer CGI zu übergeben :-(
Quelle, bitte.
Hat mal jemand von euch es geschafft die Benutzereingaben Clientseitig zu verschlüsseln und diese werte dann an einer CGI über geben konnte.
Versucht nie, schaffen würde ich es mit grösster wahrscheinlichkeit schon irgendwie :-)
Ich wäre froh um jeden Tipp.
Was willst du denn eigentlich von uns hören? - Wo happerts denn mit der Übergabe?
Danke euch alle im Voraus und weiterhin schöne Feiertage wünscht euch x-VieW
Danke und gleichfalls.
Viele Grüsse
Philipp
-
Hi Philipp,
Danke dir dir für den Hinweis, dass nicht jeder JS aktiv hat. Und somit hat keinen sinn sowas zu programieren.
Es bleibt nach meinem Wissen nur die SSL-Verschlüsslung zu verfügung, die die gesamte leitung der Daten verschlüsselt. Oder????
Danke dir ;-)Grüsse aus Zürich
x-VieW-
Halihallo x-VieW
Danke dir dir für den Hinweis, dass nicht jeder JS aktiv hat. Und somit hat keinen sinn sowas zu programieren.
_das_ habe ich _nie_ gesagt! - Es hat durchaus Sinn sowas zu programmieren, jedoch, wie
ich gesagt habe, sollte man auch einen anderen Login zur Verfügung stellen, um auch nicht
JS-Benutzer zufriedenzustellen.Es bleibt nach meinem Wissen nur die SSL-Verschlüsslung zu verfügung, die die gesamte leitung der Daten verschlüsselt. Oder????
Das wäre sinnvoller und gar einfacher zu realisieren.
Danke dir ;-)
Für?
Viele Grüsse aus Kreuzlingen ;)
Philipp
-
Hallo,
»»Es hat durchaus Sinn sowas zu programmieren,
Ich will an dieser Stelle nur noch darauf hinweisen, dass das verfahren kaum sicherer ist, als die unverschlüsselte übertragung des Passwortes. Zwar kann man das Passwort als solches nicht herausfinden, aber es reicht ja, den md5-String abzufangen. Damit kann man sich dann genau so anmelden.Einen zusätzlichen grad an Sicherheit könnte man erreichen, wenn man noch etwas anderes mit codiert, z.B. die IP des Clients und die Uhrzeit.
Grüße
Daniel
-
Halihallo Daniel
»»Es hat durchaus Sinn sowas zu programmieren,
Ich will an dieser Stelle nur noch darauf hinweisen, dass das verfahren kaum sicherer ist, als die unverschlüsselte übertragung des Passwortes. Zwar kann man das Passwort als solches nicht herausfinden, aber es reicht ja, den md5-String abzufangen. Damit kann man sich dann genau so anmelden.Full ACK. Wir müssen nur unterscheiden von wessen Sicherheit wir sprechen. Sprechen wir von der Sicherheit der Webapplikation, dann hast du recht. Sprechen wir von der Sicherheit des Kunden, zieht meine Argumentation.
Einen zusätzlichen grad an Sicherheit könnte man erreichen, wenn man noch etwas anderes mit codiert, z.B. die IP des Clients und die Uhrzeit.
Full ACK, wenn die Kodierung auf dem Server stattfindet. Wenn die Kodierung (mit Zeitstempel, IP's lassen sich mit JS bekanntlich schlecht auslesen) clientseitig realisiert ist, bringt dies nix, da der Angreifer den Algorithmus serviert bekommt und somit kein theoretisches (praktisch vielleicht schon, weil er u. U. mit JS nix anfangen kann bzw. seine Lust daran vergeht die Kodierung nachzuvollziehen) Mehr an Sicherheit darstellt.
Viele Grüsse
Philipp
-
Hallo Philipp!
Full ACK. Wir müssen nur unterscheiden von wessen Sicherheit wir sprechen. Sprechen wir von der Sicherheit der Webapplikation, dann hast du recht. Sprechen wir von der Sicherheit des Kunden, zieht meine Argumentation.
Wieso? Hängt das nicht zusammen? Wie ich jetzt Zugriff auf Kundendaten bekomme, ob bequem über die Browseroberfläche oder halt ein wenig anders - wo ist der Unterschied? Wo soll der Kunde denn sicherer sein? Man bekommt dieselben Informationen, kann dieselben Aktionen auslösen...
Viele Grüße und einen guten Rutsch!
Andreas-
Halihallo Andreas
Full ACK. Wir müssen nur unterscheiden von wessen Sicherheit wir sprechen. Sprechen wir von der Sicherheit der Webapplikation, dann hast du recht. Sprechen wir von der Sicherheit des Kunden, zieht meine Argumentation.
Wieso? Hängt das nicht zusammen? Wie ich jetzt Zugriff auf Kundendaten bekomme, ob bequem über die Browseroberfläche oder halt ein wenig anders - wo ist der Unterschied? Wo soll der Kunde denn sicherer sein? Man bekommt dieselben Informationen, kann dieselben Aktionen auslösen...
Ja, du hast schon recht. In den Account kommt man in jedem Fall, wenn man den Pwd-String
(mal den guten Vorschlag von Daniel ausgelassen) hat. Ich dachte eben mehr daran,
dass das Passwort dann viel einfacher zu extrahieren (oder besser: überhaupt) ist und
somit die "Sicherheit" des Kunden nachlässt, da eben sein Passwort im Klartext irgendwo
im Web rumschwirrt ;)
Du kennst ja die 0815-User, die immer mit demselben Passwort unterwegs sind, stell dir
vor, dass einmal ein solches Passwort unkodiert im web abgefangen wird... Das meinte ich
mit "Sicherheit des Kunden"; nicht dessen Daten oder Accountzugang, sondern seine
Sicherheit bzgl. Interaktion mit dem Web als ganzes gesehen.Viele Grüsse
Philipp
-
-
Hallo,
Die Verschlüsselung müsste auf dem Client stattfinden. Ich stelle mir das in etwa so vor.
Der Client läd die Loginseite in der die Client-IP und die Serverzeit steht.
Der Client verschlüsselt IP, Zeitstempel und Passwort und schickt diesen String, den unverschlüsselten Benutzernamen und den unverschlüsselten Zeitstempel zurück.
Der Server nimmt nun die ClientIP, den mitgeschickten Zeitstempel und das Passwort des Benutzers, verschlüsselt die wieder und vergleicht das ergebniss. Zusätzlich überprüft er, ob der Zeitstempel ausreichend aktuell ist.Mit dem Verfahren ist es nicht mehr möglich, sich durch das Abfangen der Logindaten Zutritt zu verschaffen, da der verschlüsselte String ja nur für eine bestimmte IP und Uhrzeit gültig ist.
Grüße
Daniel
-
-
-
-
use Mosche;
Danke dir dir für den Hinweis, dass nicht jeder JS aktiv hat. Und somit hat keinen sinn sowas zu programieren.
Du kannst ja für JS-User per JS eine zusätzliche Variable belegen lassen, die deinem CGI-Script anzeigt, dass das Passwort verschlüsselt ist. Wenn diese Variable nicht gesetzt wird, dann hat der User kein Javascript aktiviert und das Passwort ist unverschlüsselt.
Dann können die Seite alle benutzen, und es gibt für JS-User ein zusätzliches SIcherheitsfeature.
use Tschoe qw(Matti);
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
-