nicht angemeldet
Clientseitige verschlüsselung ? (gibt es alternativen?)
Hi,
Will Passwort per Formular an CGI-Script übertragen.
Beim durchsuchen bin ich auf folgende Tips gestoßen.
1. SSL : fällt für mich weg das es zu teuer is
2. Java : fällt ja auch weg da es leicht zu durchschauen ist ( und man es deaktivieren kann)
3. PGP : Clientseitig bei einem Formular geht ja nicht (das is ja eher für das Verschlüsseln von Texten/E-Mails da
Also was gibt es denn da überhauptnoch für alternativen ?
Danke für Eure Hilfe.
mfG
Steffen
-
Hi auch,
Will Passwort per Formular an CGI-Script übertragen.
...
Also was gibt es denn da überhauptnoch für alternativen ?muß es ein Formular sein? Was spricht gegen Server Authentication? http://www.teamone.de/selfaktuell/artikel/schroepl02.htm#a7
mfG - Michael
-
muß es ein Formular sein? Was spricht gegen Server Authentication? http://www.teamone.de/selfaktuell/artikel/schroepl02.htm#a7
Verschluesselt uebertragen wird dadurch aber nichts. Wenn man's vernünftig machen will, braucht man eine SSL. Ansonsten kann die Daten auch gleich unverschluesselt uebertragen.
Peter
-
Hi,
muß es ein Formular sein? Was spricht gegen Server Authentication? http://www.teamone.de/selfaktuell/artikel/schroepl02.htm#a7
Verschluesselt uebertragen wird dadurch aber nichts.
Wenn man's vernünftig machen will, braucht man eine SSL.... oder AuthType Digest (und einen Browser, der das unterstützt).
Apache könnte es ... (http://www.apache.org/docs/mod/mod_digest.html)mFG - Michael
-
... oder AuthType Digest (und einen Browser, der das unterstützt).
Apache könnte es ... (http://www.apache.org/docs/mod/mod_digest.html)Waere eine Alternative. Weisst Du, welche Clienten das unterstuetzen?
Peter
-
... oder AuthType Digest (und einen Browser, der das unterstützt).
Apache könnte es ... (http://www.apache.org/docs/mod/mod_digest.html)Waere eine Alternative. Weisst Du, welche Clienten das unterstuetzen?
Peter
Jo, das wäre interessant zu wissen welche Clienten das unterstützen...
aber so richtig sehe ich da nich nicht richtig durch (mein englisch is nicht so gut)
Dieses MD5 is das denn dann nun ne Clientseitige verschlüsselung ?cu
Steffen -
Hi,
... oder AuthType Digest (und einen Browser, der das unterstützt).
Apache könnte es ... (http://www.apache.org/docs/mod/mod_digest.html)
Waere eine Alternative. Weisst Du, welche Clienten das unterstuetzen?*kein* mir bekannter. Netscape 3.0 und 4.7 nicht (im Server-Log findet man jeweils die Meldung, daß sie "Basic" an den Server schicken, was nicht paßt), M$IE4 auch nicht (überhaupt keine Reaktion auf der Server-Seite, jedenfalls kein Log-Eintrag, im Browser erscheint ein Fehler 401). Neuere Browser habe ich nicht zur Hand.
mfG - Michael
-
-
Hi,
habe jetzt mal was über MD5 im Forum-Archiv gesucht, auch einiges gefunden.
Aber leider nur einiges wie man es mit Java einbindet.
und nix wie mit CGI...
aber das kann ja auch nicht richtig funktionieren, da es ja dann noch nicht Clientseitig verschlüsselt wäre...Also irgendwie finde ich hier gleube ich keine richtige Lösung :(((
.htacess is nicht die richtige, da ich meine eigene passwd.txt verwenden möchte...
wenn Ihr noch andere Tips habt wäre ich dankbar
cu
Steffen-
Bei MD5 is ja auch das größte problem welches ich darin sehe das man ja Java Script deaktivieren kann, und einige haben das ja deaktiviert... das is einfach mal blöd
2. da man den Quelltext der m5d.js zur Verfügung hat, is es auch wiederum leichter knackbar...
Aber mal was anderes: mein Bruder hat mir jetzt mal was von OPEN-SSL erzählt...
Dies muß doch aber auch wiederrum der Provider unterstüzen ... oder ?-
Tach auch!
Bei MD5 is ja auch das größte problem welches ich darin sehe das man ja Java Script deaktivieren kann, und einige haben das ja deaktiviert... das is einfach mal blöd
Du scheinst da grundlegend was misszuverstehen. Also mal der Reihe nach.
MD5 steht fuer Message Digest, das ist eine Art Checksumme (128 bit breit). Das wesentliche daran ist, dass bei minimaler Aenderung der Input-Daten (1 Bit reicht schon) ein voellig anderes Ergebnis herauskommt. Auf [/selfaktuell/artikel/md5.htm] am Ende der Seite kannst Du schauen, wie sowas aussieht.
Eine MD5-Checksumme kann man natuerlich nicht nur in JavaScript berechnen! Bei der HTTP-Kommunikation macht das der Browser selbst, also nix JS. Aber dazu muss es der Browser eben unterstuetzen. Der Browser berechnet also die Checksum ueber das vom Benutzer eingegebene Passwort zusammen mit einigen weiteren Daten (Username, HTTP-Method, URL, vom Server gesendete Nonce-Value) und schickt das Ergebnis an den Server. Der macht genau dasselbe, naemlich die Checksumme ueber das Passwort, das er *erwartet*, und die weiteren Dinge bilden, und vergleicht dann das Ergebnis mit dem vom Browser gesendeten Ergebnis. Und wenn beides gleich ist, dann war das vom Benutzer eingegebene Passwort richtig (mit einer Wahrscheinlichkeit von 2^128 == 3.40E+38). Mehr dazu in http://rfc.fh-koeln.de/rfc/html/rfc2617.html.
Das Problem sind halt die Browser, die das unterstuetzen muessen. Die Aussage auf http://www.apache.org/docs/mod/mod_digest.html stammt von Juli 96, hat also keine Bedeutung mehr.
- da man den Quelltext der m5d.js zur Verfügung hat, is es auch wiederum leichter knackbar...
Eine Checksumme ist nicht de-crypt-bar, d.h. die Originaldaten koennen nicht aus der Checksumme restauriert werden. Der Quelltext ist sowieso bekannt, ob nun in JS oder C oder irgendeiner anderen Sprache, das Verfahren ist naemlich schlicht und einfach bekannt und weit verbreitet http://rfc.fh-koeln.de/rfc/html/rfc1321.html.
Aber mal was anderes: mein Bruder hat mir jetzt mal was von OPEN-SSL erzählt...
Dies muß doch aber auch wiederrum der Provider unterstüzen ... oder ?http://www.openssl.org/, http://www.apache.org/related_projects.html#modssl
So long
-
-
-
-
-