Verschlüsselung

[kati]

hallo zusammen,
vielleicht habe schon viele diese Frage gestellt, ich konnte aber trotzdem nichts passendes finden, da ich mich mit dem Codieren nur sehr wenig auskenne. Daher frage ich direkt hier. Also ich möchte ganz normal Passwörter verschlüsseln. Da gibt es eine java-Variante, ein sehr häufiges Algorithmus base64s. Kann mir jemand genauer erklären, wie es funktioniert - bzw. welche Variante ich bevorzugen sollte.
Da das javascript-Beispiel:
http://www.ideenreich.com/javascript/codieren_javascript.shtml

Vielen Dank
kati

[TOM]

Hi allgemein is dazu mal zu sagen, dass egal wie du das in JavaScript verschlüsselst, es einfach entschlüsselt werden kann weil man ja den Quelltext sieht. Warum machst du das alles nicht in PHP oder ASP. Dann sendest du dein Form an den Server ob das passwort stimmt und dan brauchste auch nix verschlüsseln.

Solche serverseitigen Scriptsprachen haben nat. noch viele andere Vorteile. Würd ich mir ma angucken :)

MfG TOM

[Christoph Zurnieden]

Hallo,

Hi allgemein is dazu mal zu sagen, dass egal wie du das in JavaScript verschlüsselst, es einfach entschlüsselt werden kann weil man ja den Quelltext sieht.

Nein, das läßt sich allgemein nicht sagen.
Dann müßte ja GnuPGP auch einfach zu entschlüsseln sein, da der Quelltext offen ist. Warum macht man dann sogar eben jene Öffentlichkeit des Codes zur Bedingung für Sicherheit?

Warum machst du das alles nicht in PHP oder ASP. Dann sendest du dein Form an den Server ob das passwort stimmt und dan brauchste auch nix verschlüsseln.

Sehr schön. Und wie wird das Passwort dann übertragen?
Aha, dacht' ich mir's doch ;-)

Solche serverseitigen Scriptsprachen haben nat. noch viele andere Vorteile. Würd ich mir ma angucken :)

Diesen Vorteil haben sie nicht, aber die ganzen anderen schon, das stimmt.

so short

Christoph Zurnieden

[TOM]

Hi

Solche serverseitigen Scriptsprachen haben nat. noch viele andere Vorteile. Würd ich mir ma angucken :)

Diesen Vorteil haben sie nicht, aber die ganzen anderen schon, das stimmt.

Ja mag schon sein, aber mit solchen Sprachen kann niemand das Passwort aus dem Quelltext kopieren ;-) Das meinte ich.

so short

Christoph Zurnieden

Mfg TOM

[kati]

Hi,

erstmal vielen Dank für eure (langen :-)) Antworten auf meine Frage. Damit ich gleich die Frage "es kommt drauf an..." beantworte: also es gibt zwei Textfelder - kennung und password, mit dem sich der User in einer mysql-DB einloggen kann. Zum Abschicken dieser Daten nutzte ich zuerst einen submit-Button (post), die Daten - sobald sie auf dem Server eingelangt sind - habe ich mit $HTTP_POST_VARS ausgelesen, Cookies gesetzt und die entsprechenden Operationen in der mysql-DB durchgeführt. Jetzt habe ich den Button durch einen Link ersetzt, in welchem ich beim Abschicken auch die content-Variable setzten möchte und die kennung mit dem zuvor mit javascript verschlüsselten Password anhängen möchte. Ob es (von Verfahren her) so richtig ist, weiß ich nicht, bin newbie hinsichtlich der Webprogrammierung und versuche ich mich ein bisschen in die Materie einzuarbeiten, nachdem mir an der Uni XOTcl aufgezwungen wurde *heul*
Also wenn ich den Sinn der Sache auch richtig verstanden habe, muss ich den Password am Client verschlüsseln (also mit javascript) und an den Server (auch mit dem Schlüssel usw.) schicken. Am Server wird dies entschlüsselt. Ist es so, oder erzähle ich da nen Schmarrn ? Es wurden mir da mehrere Verfahren empfohlen, was eignet sich nun am besten für diese Problemstellung ?

Vielen Dank.
kati

Hi

Solche serverseitigen Scriptsprachen haben nat. noch viele andere Vorteile. Würd ich mir ma angucken :)

Diesen Vorteil haben sie nicht, aber die ganzen anderen schon, das stimmt.

Ja mag schon sein, aber mit solchen Sprachen kann niemand das Passwort aus dem Quelltext kopieren ;-) Das meinte ich.

so short

Christoph Zurnieden

Mfg TOM

[TOM]

Hi

Axoo meinst du das.

Also ich versuchs zu erklären wie ichs verstanden hab. Du willst bevohr er das Passwort vom Formular zum Server schickt dieses verschlüsseln und am Server entschlüsseln. Also benutzt du bereits eine Serverseitige Programmierprache.

Wenn mir mal die Frage erlaubt ist, warum da eine Verschlüsselung von Nöten ist!?

Wer soll die Daten bei post in der Zwischenzeit abfangen??

Da hockt doch keiner mit nem Sniffer dazwischen und fischt dir dein Passwort raus - lol.

Is mir jetzt net klar oder programmierst du für die NSA? ggg

MfG TOM

[kati]

hallo TOM,

naja, das mit NSA war gut. Es geht nur ums Prinzip - sonst nichts.

cu kati

Hi

Axoo meinst du das.

Also ich versuchs zu erklären wie ichs verstanden hab. Du willst bevohr er das Passwort vom Formular zum Server schickt dieses verschlüsseln und am Server entschlüsseln. Also benutzt du bereits eine Serverseitige Programmierprache.

Wenn mir mal die Frage erlaubt ist, warum da eine Verschlüsselung von Nöten ist!?

Wer soll die Daten bei post in der Zwischenzeit abfangen??

Da hockt doch keiner mit nem Sniffer dazwischen und fischt dir dein Passwort raus - lol.

Is mir jetzt net klar oder programmierst du für die NSA? ggg

MfG TOM

[TOM]

Hi Kati

naja, das mit NSA war gut. Es geht nur ums Prinzip - sonst nichts.

Danke :-P. Naja wenn's nur darum geht hört sich plausiebel an. Hab's aber noch nie gemacht....

cu kati

greets from Erlangen Central -- TOM

[kati]

hallo zusammen,

hmm, ich habe nicht erwartet, dass ich so eine Diskussion veranlasse. ;-)
Vielen Dank für eure Beiträge

cu kati

Hi Kati

naja, das mit NSA war gut. Es geht nur ums Prinzip - sonst nichts.

Danke :-P. Naja wenn's nur darum geht hört sich plausiebel an. Hab's aber noch nie gemacht....

cu kati

greets from Erlangen Central -- TOM

[Christoph Schnauß]

hi kati,

hmm, ich habe nicht erwartet, dass ich so eine Diskussion veranlasse. ;-)

du hast halt eine durchaus interessante Frage angesprochen, und dann entwickeln sich eben manchmal solche Threads. Man kann das bloß niemals vorauswissen, ob es eine solche Debatte geben wird, wer sich daran beteiligt, und wieviel "Substanz" drinstecken wird. Diesmal ist im _gesamten_ Thread ziemlich viel Substanz enthalten.

So einfach ist das.

Vielen Dank für eure Beiträge

bittesehr. Vielleicht hilft dir ja das eine oder andre weiter oder bringt dich auf eine neue Idee

nächtliche Grüße aus Berlin

Christoph S.

[abcde]

abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde

[abcde]

abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde
abcde

http://www.xitami.com/xitami3.gif

www.xitami.com/xitami3.gif

<a href="http://www.xitami.com/xitami3.gif">Xitami</a>

mailto:[e-mail]

[Linksetzer]

http://forum.de.selfhtml.org/faq/#Q-19

[Christoph Zurnieden]

Hallo,

Axoo meinst du das.

Also ich versuchs zu erklären wie ichs verstanden hab. Du willst bevohr er das Passwort vom Formular zum Server schickt dieses verschlüsseln und am Server entschlüsseln. Also benutzt du bereits eine Serverseitige Programmierprache.

Wenn mir mal die Frage erlaubt ist, warum da eine Verschlüsselung von Nöten ist!?

Wer soll die Daten bei post in der Zwischenzeit abfangen??

Jeder, der möchte.
Z.B. der Sysadmin, wenn aus einem Intranet verhandelt wird.

Da hockt doch keiner mit nem Sniffer dazwischen und fischt dir dein Passwort raus - lol.

Ja, wer so denkt, hat schon verloren.

Im Computerbereich ist eine leicht paranoide Grundhaltung nie verkehrt.

Is mir jetzt net klar oder programmierst du für die NSA? ggg

Das ist nicht witzig. Der Schutz gilt dem Kunden, nicht ihr. (Wobei ich einfach mal annehme, das "Kati" die Kurzform von "Katharina" ist. Bitte um Entschuldigung, falls dem nicht so sein sollte)

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hallo,

erstmal vielen Dank für eure (langen :-)) Antworten auf meine Frage. Damit ich gleich die Frage "es kommt drauf an..." beantworte: also es gibt zwei Textfelder - kennung und password, mit dem sich der User in einer mysql-DB einloggen kann. Zum Abschicken dieser Daten nutzte ich zuerst einen submit-Button (post), die Daten - sobald sie auf dem Server eingelangt sind - habe ich mit $HTTP_POST_VARS ausgelesen, Cookies gesetzt

Muß das den sein mit den Cookies? *sigh*

und die entsprechenden Operationen in der mysql-DB durchgeführt. Jetzt habe ich den Button durch einen Link ersetzt, in welchem ich beim Abschicken auch die content-Variable setzten möchte und die kennung mit dem zuvor mit javascript verschlüsselten Password anhängen möchte. Ob es (von Verfahren her) so richtig ist, weiß ich nicht, bin newbie hinsichtlich der Webprogrammierung und versuche ich mich ein bisschen in die Materie einzuarbeiten, nachdem mir an der Uni XOTcl aufgezwungen wurde *heul*

*taschentuch-rüberreich*

Ist doch ganz in Ordnung so. Auch die Überlegung das gesendete Password zu verschlüsseln ist all zu selten geworden heutzutage und mehr als löblich!

Wenn es denn nur eine User/Passwort Kombination sein soll, dann reicht für die meisten Zwecke eine MD5Sum von User/Passwort + Session-ID (+ Client-IP)

Also wenn ich den Sinn der Sache auch richtig verstanden habe, muss ich den Password am Client verschlüsseln (also mit javascript) und an den Server (auch mit dem Schlüssel usw.) schicken. Am Server wird dies entschlüsselt.

Bei MD5Sum gibt es nichts zu entschlüsseln, das ist Einweg. Du mußt also auf dem Server den empfangenen String gegen eine MD5Sum aus User/Passwort + Session-ID (+ Client-IP) vergleichen, also auf dem Server das gleiche, wie auf dem Client machen.

Ich möchte es aber nicht umgehen, jetzt auch wiederholt darauf hinzuweisen, das das nicht 100% sicher ist. Nur wird die "man in the middle" Attacke jetzt schwieriger, wenn Du die Client-IP ausliest und mit reinnimmst.Dadurch, das Du sie ausliest, muß der Angreifer IP-Spoofing betreiben, das ist nicht gar so einfach.

Wenn Du also wirklich wichtige Daten hast wirst Du um ein SSL Zertifikat nicht herumkommen. Liegt so um die 1.500 EUR/anno.

BTW: Die Defaulteinstellungen von MySQL betreiben Klartextverkehr. Ich weiß nicht, ob es in den neuen Versionen jetzt direkt drin ist, aber bei den alten Versionen brauchte es einen externe Patch.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Wenn es denn nur eine User/Passwort Kombination sein soll, dann reicht für die meisten Zwecke eine MD5Sum von User/Passwort + Session-ID (+ Client-IP)

Wenn ich das richtig verstanden habe, soll aber Passwort und Benutzername zur Anmeldung an MySQL sein? Dann geht dieser Ansatz nicht, weil das MySQL-Passwort in der Datenbank selbst bereits einweg-verschlüsselt liegt.

Wenn Du also wirklich wichtige Daten hast wirst Du um ein SSL Zertifikat nicht herumkommen. Liegt so um die 1.500 EUR/anno.

Ja, HTTPS wäre die richtige[tm] Lösung. Und ja nach Anwendungsfall brauchst du auch kein kommerzielles Zertifikat sondern kannst dir selber eins machen. Kostet nichts, und der einzige Unterschied ist, dass der Benutzer das Zertifikat bei der erstmaligen Benutzung bestätigen muss.

--
Henryk Plötz
Grüße aus Berlin

[Christoph Zurnieden]

Hallo,

Wenn es denn nur eine User/Passwort Kombination sein soll, dann reicht für die meisten Zwecke eine MD5Sum von User/Passwort + Session-ID (+ Client-IP)

Wenn ich das richtig verstanden habe, soll aber Passwort und Benutzername zur Anmeldung an MySQL sein? Dann geht dieser Ansatz nicht, weil das MySQL-Passwort in der Datenbank selbst bereits einweg-verschlüsselt liegt.

Ja und?
Wer es direkt hin schickt, ist selber schuld.

Das meint, das User/Password von MySQL nie direkt herausgegeben werden darf, nur über einen Umweg, da MySQL auch direkt ansprechbar sein kann.

BTW: "Gehtnichgippsnich!" ;-)

Wenn Du also wirklich wichtige Daten hast wirst Du um ein SSL Zertifikat nicht herumkommen. Liegt so um die 1.500 EUR/anno.

Ja, HTTPS wäre die richtige[tm] Lösung. Und ja nach Anwendungsfall brauchst du auch kein kommerzielles Zertifikat sondern kannst dir selber eins machen. Kostet nichts, und der einzige Unterschied ist, dass der Benutzer das Zertifikat bei der erstmaligen Benutzung bestätigen muss.

Genau da liegt das Problem "[...] das der Benutzer das Zertifikat bei der erstmaligen Benutzung bestätigen muss".

Da läßt sich keiner drauf ein. Man beschaue sich nur die ganzen Warnungen, die die großen Browser loslassen, wenn sie auf ein Zertifikat stoßen, das nicht in ihrer Liste ist! Dem unbedarftem User kräuseln sich dabei doch die Fußnägel!

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Da läßt sich keiner drauf ein. Man beschaue sich nur die ganzen Warnungen, die die großen Browser loslassen, wenn sie auf ein Zertifikat stoßen, das nicht in ihrer Liste ist! Dem unbedarftem User kräuseln sich dabei doch die Fußnägel!

Du meinst die selben unbedarften Anwender die auf alles klicken was einen OK-Knopf hat und nicht schnell genug vom Bildschirm verschwindet? Die selben unbedarften Anwender, dank denen sich iloveyou rasend schnell verbreitet hat? Ich glaube eher nicht, dass die ein Probleme darstellen ;)

Die nicht ganz so unbedarften Anwender, die sich Meldungen auch durchlesen bevor sie sie bestätigen, wissen hoffentlich, dass die Unterschrift von Verisign oder Konsorten exakt nichts über die Vertrauenswürdigkeit des Servers aussagt und es im Falle extremer Paranoia wesentlich geeignetere Wege gibt, ein Zertifikat zu überprüfen.

Und wie gesagt, ist das alles eine Frage der Anwendung. Wenn Kati die Anwendung nur auf einer begrenzten Zahl an Rechnern nutzen will, kann sie da das Zertifikat von Vorneherein manuell installieren. Überhaupt soll die Benutzergruppe doch geschlossen sein (sonst wären die Passwörter wohl kaum nötig), da kann man jedem Benutzer doch zusammen mit dem Passwort den Fingerprint des Serverzertifikats aushändigen und ihn instruieren wie er auf die Browserwarnung zu reagieren hat (also Fingerprint überprüfen, und falls er ok ist, dann das Zertifikat dauerhaft annehmen).

--
Henryk Plötz
Grüße aus Berlin

[Christoph Zurnieden]

Hallo,

Da läßt sich keiner drauf ein. Man beschaue sich nur die ganzen Warnungen, die die großen Browser loslassen, wenn sie auf ein Zertifikat stoßen, das nicht in ihrer Liste ist! Dem unbedarftem User kräuseln sich dabei doch die Fußnägel!

Du meinst die selben unbedarften Anwender die auf alles klicken was einen OK-Knopf hat und nicht schnell genug vom Bildschirm verschwindet? Die selben unbedarften Anwender, dank denen sich iloveyou rasend schnell verbreitet hat?

Genau die meine ich. Klicken bei jedem Scheiß ihr OK an, nur wenn es wirklich mal etwas gibt, bei dem sie das dürfen, machen die das unter keinen Umständen.

Glaube es mir: oft genug erlebt *sigh*

Die nicht ganz so unbedarften Anwender, die sich Meldungen auch durchlesen bevor sie sie bestätigen, wissen hoffentlich, dass die Unterschrift von Verisign oder Konsorten exakt nichts über die Vertrauenswürdigkeit des Servers aussagt

Das wissen Du und ich und noch einige anderer Leute.
Aber sehr viele sind es leider nicht.

und es im Falle extremer Paranoia wesentlich geeignetere Wege gibt, ein Zertifikat zu überprüfen.

Es gibt keine. Irgendwo fängt das "Vertrauen" an. Es gibt für den Zweck keine Möglichkeit, das ohne "Vertrauensvorschuß" zu machen.

Es gibt noch nicht einmal eine Möglichkeit, das Risiko zu minimieren.

Und wie gesagt, ist das alles eine Frage der Anwendung. Wenn Kati die Anwendung nur auf einer begrenzten Zahl an Rechnern nutzen will, kann sie da das Zertifikat von Vorneherein manuell installieren. Überhaupt soll die Benutzergruppe doch geschlossen sein (sonst wären die Passwörter wohl kaum nötig), da kann man jedem Benutzer doch zusammen mit dem Passwort den Fingerprint des Serverzertifikats aushändigen und ihn instruieren wie er auf die Browserwarnung zu reagieren hat (also Fingerprint überprüfen, und falls er ok ist, dann das Zertifikat dauerhaft annehmen).

Klar ist das eine Möglichkeit. Aber dann erklär das mal dem Durchschnittsdau, wie er das machen soll ;-)

Zweites Problem: wie stellst Du sicher, das der Fingerprint auch korrekt ist? Wieder mit einem Zertifikat? Dafür dann wieder eine Fingerprint? Ad infinitum?

Nein, die Identität des Gegenübers festzustellen ist kein zu 100% lösbares Problem.

Ich habe hier ein ähnlich gelagertes Problem mit einem byzantinischem Voting.
Wenn man das ganz abstrahiert kann man nur annehmen, das es nicht möglich ist herauszufinden, ob einer der beteiligten Knoten lügt oder die Wahrheit sagt. Es funktioniert nur unter der Annahme, das es weniger Lügner als Wahrheitsliebende gibt. Das ist sogar relativ, hauptsache das Verhältnis Lügner/Wahrheitsliebende ist kleiner 1.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Genau die meine ich. Klicken bei jedem Scheiß ihr OK an, nur wenn es wirklich mal etwas gibt, bei dem sie das dürfen, machen die das unter keinen Umständen.

Stimmt auch wieder.

und es im Falle extremer Paranoia wesentlich geeignetere Wege gibt, ein Zertifikat zu überprüfen.

Es gibt keine. Irgendwo fängt das "Vertrauen" an. Es gibt für den Zweck keine Möglichkeit, das ohne "Vertrauensvorschuß" zu machen.

Das mag sein. Aber in vielen Fällen in denen die Verbindung sicher sein muss, gibt es eine andere Möglichkeit mit dem Anbieter in Kontakt zu treten. Dann schnappt man sich halt das Telefon und fragt den anderen freundlich nach dem Fingerprint. (Mehr Wege sind denkbar. Die c't veröffentlicht den Fingerprint ihres CA-Schlüssels zum Beispiel in jeder Ausgabe. Wenn man mehrere verschiedene Ausgaben hat (natürlich bei verschiedenen Händlern gekauft ;) und die Abdrücke alle übereinstimmen, ist die Wahrscheinlichkeit, dass einem ein falscher Schlüssel untergejubelt wird, sehr, sehr gering.)

Zweites Problem: wie stellst Du sicher, das der Fingerprint auch korrekt ist? Wieder mit einem Zertifikat? Dafür dann wieder eine Fingerprint? Ad infinitum?

Ich sagte doch: Wenn sie ihr Passwort und die Benutzerkennung erhalten, kriegen sie ausserdem einen Zettel mit dem Fingerprint. Je nach Anwendung müssen die Anwender eh geschult werden. (Das kann jetzt nur Kati klären, indem sie mehr über ihre Anwendung verrät.)

--
Henryk Plötz
Grüße aus Berlin

[Christoph Zurnieden]

Hallo,

und es im Falle extremer Paranoia wesentlich geeignetere Wege gibt, ein Zertifikat zu überprüfen.

Es gibt keine. Irgendwo fängt das "Vertrauen" an. Es gibt für den Zweck keine Möglichkeit, das ohne "Vertrauensvorschuß" zu machen.

Das mag sein. Aber in vielen Fällen in denen die Verbindung sicher sein muss, gibt es eine andere Möglichkeit mit dem Anbieter in Kontakt zu treten. Dann schnappt man sich halt das Telefon und fragt den anderen freundlich nach dem Fingerprint. (Mehr Wege sind denkbar. Die c't veröffentlicht den Fingerprint ihres CA-Schlüssels zum Beispiel in jeder Ausgabe. Wenn man mehrere verschiedene Ausgaben hat (natürlich bei verschiedenen Händlern gekauft ;) und die Abdrücke alle übereinstimmen, ist die Wahrscheinlichkeit, dass einem ein falscher Schlüssel untergejubelt wird, sehr, sehr gering.)

Das funktioniert so nicht, das ist eine Milchmädchenrechnung.
Das ursprünglich vorrausgesetzte ist ein Vertrauensvorschuß. Du setzt nämlich vorraus, das es mehr Wahrheitsliebende als Lügner gibt.
Die Wahrscheinlichkeit ist 1/2, da ändert sich nichts, auch wenn Du noch soviele Beteiligte dazu heranziehst. Wenn Du nicht vorraussetzen kannst, das es eben mehr Wahrheitsliebende als Lügner gibt, kommst Du so auf keinen grünen Zweig.

Ja, das macht Kopfschmerzen.
Mir vor allem, da sich auf das in meinem letztem Posting angesprochene byzantinische Voting bezogen eine ganzes System wie ein Kartenhaus zusammenfallen läßt. Ein System, das bereits verkauft und in Produktion ist.

Das einzige Glück, das ich dabei habe, ist, das ich damit finanziell und verantwortlich nichts zu tun habe. Ich sollte nur die Mathematik machen. Und jetzt steh ich da und weiß nicht, wie ich ihm das beibringen soll.

Aber auch Mathematik läßt sich ja zurechtbiegen, gelle? ;-)

Zweites Problem: wie stellst Du sicher, das der Fingerprint auch korrekt ist? Wieder mit einem Zertifikat? Dafür dann wieder eine Fingerprint? Ad infinitum?

Ich sagte doch: Wenn sie ihr Passwort und die Benutzerkennung erhalten, kriegen sie ausserdem einen Zettel mit dem Fingerprint. Je nach Anwendung müssen die Anwender eh geschult werden. (Das kann jetzt nur Kati klären, indem sie mehr über ihre Anwendung verrät.)

Ja, das basiert dann wieder auf Vertrauensvorschuß, ist also eigentlich unnötig.

Aber wir sollten die Diskussion hier mal sein lassen (privat gerne weiter, falls Interesse an Details besteht), das könnte nur eine Panik verursachen ;-)

In praxo funktioniert es zumindest, das ist ja die Hauptsache.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Das ursprünglich vorrausgesetzte ist ein Vertrauensvorschuß. Du setzt nämlich vorraus, das es mehr Wahrheitsliebende als Lügner gibt.

Das verstehe ich nicht, an welcher Stelle das eine Rolle spielt. Es geht hierbei doch nicht um die Identifikation a la "Ich bin Max Mustermann" sondern darum sicherzustellen, dass man mit dem richtigen Partner kommuniziert. Wenn der Fingerprint zusammen mit dem Passwort herausgegeben wird, ist doch sichergestellt, dass ich den Fingerprint von demjenigen erhalte, der mir den Dienst anbietet. Ähnlich mit dem c't-Beispiel: Wenn der Fingerprint aus der c't kommt (wie gesagt, dass muss man evt. mit Zufallsstichproben überprüfen), ist doch sichergestellt, dass er von der c't rausgegeben wurde. Die einzige Möglichkeit bei diesen beiden Wegen an einen falschen Fingerprint zu kommen, wäre wenn mir derjenige einen falschen Fingerprint gibt. Das ist doch ein sehr schöner Kreis:
Wenn ich demjenigen der mir den Dienst anbietet, vertraue (so, dass ich da dann auch Daten eingebe), dann gehe ich davon aus, dass er mir den richtigen Fingerprint gibt. Wenn ich ihm nicht vertraue, dann ist doch auch egal ob der Fingerprint der richtige ist.

Die Wahrscheinlichkeit ist 1/2, da ändert sich nichts, auch wenn Du noch soviele Beteiligte dazu heranziehst.

Ich will ja keine Beteiligten heranziehen, sondern das ist eine Sache zwischen mir und dem Partner.
(Gut, im Falle der Zeitschriftenhändler habe ich noch Partner herangezogen, da reicht dann aber ein Fingerprint der aus der Reihe tanzt, um mich stutzig werden zu lassen. Und daran, dass alle Examplare die ich in verschiedenen Bundesländern zu verschiedenen Zeiten gekauft habe, manipuliert sind, will ich nicht so recht glauben.)

Anderes Beispiel: Wenn ich mich per SSH auf einem Uni-Rechner einlogge, könnte ich vorher den Fingerprint des SSH-Servers direkt auf dem Rechner überprüfen. Wenn ich dem Rechner nicht vertraue, dann nützt mir der Fingerprint auch nichts, da ich mich dann dort tunlichst nicht einlogge.

Mir vor allem, da sich auf das in meinem letztem Posting angesprochene byzantinische Voting bezogen eine ganzes System wie ein Kartenhaus zusammenfallen läßt.

Kannst du das ein bisschen ausführen? Mit 10 min Googlen habe ich nicht sehr viel relevantes dazu gefunden.

Aber wir sollten die Diskussion hier mal sein lassen (privat gerne weiter, falls Interesse an Details besteht), das könnte nur eine Panik verursachen ;-)

Erst mal hier weitergemacht, da ich prinzipiell davon ausgehen muß, dass ich nicht der einzige bin der dich nicht verstanden hat.

--
Henryk Plötz
Grüße aus Berlin

[Christoph Zurnieden]

Hallo,

Das ursprünglich vorrausgesetzte ist ein Vertrauensvorschuß. Du setzt nämlich vorraus, das es mehr Wahrheitsliebende als Lügner gibt.

Das verstehe ich nicht, an welcher Stelle das eine Rolle spielt. Es geht hierbei doch nicht um die Identifikation a la "Ich bin Max Mustermann" sondern darum sicherzustellen, dass man mit dem richtigen Partner kommuniziert.

Kannst Du mir hier mal erklären, wo da der Unterschied liegt?

Wenn der Fingerprint zusammen mit dem Passwort herausgegeben wird, ist doch sichergestellt, dass ich den Fingerprint von demjenigen erhalte, der mir den Dienst anbietet.

Nein, es ist nur sichergestellt, das Du das Passwort zusammen mit dem Fingerprint bekommen hast.
Mehr nicht.
Noch nicht einmal, ob die beiden zusammengehören, ob der Absender der richtige ist usw.

Ähnlich mit dem c't-Beispiel: Wenn der Fingerprint aus der c't kommt (wie gesagt, dass muss man evt. mit Zufallsstichproben überprüfen)

Das kannst Du nicht überprüfen.
Um bei Deinem Beispiel zu bleiben: was ist mit einem Druckfehler?

»», ist doch sichergestellt, dass er von der c't rausgegeben wurde. Die einzige Möglichkeit bei diesen beiden Wegen an einen falschen Fingerprint zu kommen, wäre wenn mir derjenige einen falschen Fingerprint gibt. Das ist doch ein sehr schöner Kreis:

Nein, ist es so nicht, aber ich weiß, was Du meinst.

Wenn ich demjenigen der mir den Dienst anbietet, vertraue (so, dass ich da dann auch Daten eingebe), dann gehe ich davon aus, dass er mir den richtigen Fingerprint gibt. Wenn ich ihm nicht vertraue, dann ist doch auch egal ob der Fingerprint der richtige ist.

Damit entscheidest Du, ob Du den Vertrauensvorschuß gewährst oder nicht.
Dieser Vertrauensvorschuß fußt worauf?
Genau: auf gar nichts.

Man kann niemanden _zwingen_ zu lügen oder die Wahrheit zu sagen.

Du vertraust auf Regeln deren Einhaltung nicht kontrolliert werden kann.

Ja, ich weiß, das es ohne im Leben nicht geht.
Aber das ist nicht das Leben sondern Technik.

Die Wahrscheinlichkeit ist 1/2, da ändert sich nichts, auch wenn Du noch soviele Beteiligte dazu heranziehst.

Ich will ja keine Beteiligten heranziehen, sondern das ist eine Sache zwischen mir und dem Partner.

Welchem Partner?
Woher weißt Du, das es der Richtige ist? (no pun intended ;-)

(Gut, im Falle der Zeitschriftenhändler habe ich noch Partner herangezogen, da reicht dann aber ein Fingerprint der aus der Reihe tanzt, um mich stutzig werden zu lassen. Und daran, dass alle Examplare die ich in verschiedenen Bundesländern zu verschiedenen Zeiten gekauft habe, manipuliert sind, will ich nicht so recht glauben.)

Ja, was ist denn mit dem Druckfehler?
Zeitschriften werden meist bei mehreren Druckereien und/oder in mehreren Auflagen hergestellt. Die eine hat den Druckfehler, bei der anderen ist er stillschweigend korrigiert.

Anderes Beispiel: Wenn ich mich per SSH auf einem Uni-Rechner einlogge, könnte ich vorher den Fingerprint des SSH-Servers direkt auf dem Rechner überprüfen. Wenn ich dem Rechner nicht vertraue, dann nützt mir der Fingerprint auch nichts, da ich mich dann dort tunlichst nicht einlogge.

Als Client würde ich mir da keine Sorgen machen, eher schon als Server ;-)

Aber auch hier zieht wieder der Vertrauensvorschuß, keine nachprüfbaren Beweise.

Das System, so wie es jetzt läuft kann nicht funktionieren, es läuft aber trotzdem. Warum? Weil es ein Tauschgeschäft ist, das auf Gegenseitigkeit beruht. Mehr nicht.

Mir vor allem, da sich auf das in meinem letztem Posting angesprochene byzantinische Voting bezogen eine ganzes System wie ein Kartenhaus zusammenfallen läßt.

Kannst du das ein bisschen ausführen? Mit 10 min Googlen habe ich nicht sehr viel relevantes dazu gefunden.

Das habe ich auch mal für über 3 Stunden dort und an anderen Stellen probiert. Scheint wirklich nichts im Netz zu finden zu sein. Ich kann mich ja mal nach der entsprechenden Totbaumliteratur erkundigen.
(Ich hatte mal einen ganzen Stapel hier. Wenn man sich auch nicht jedesmal alles aufschreibt ... 'tschuldigung)
Allerdings dürfte die Bibliohek der nächstgelegenen Uni eine gute Quelle sein. Zumindest hatte ich meine Bücher daher.
Oder glaubst Du vielleicht ich gebe dafür zwischen 40-80(!)EUR aus? ;-)

Aber wir sollten die Diskussion hier mal sein lassen (privat gerne weiter, falls Interesse an Details besteht), das könnte nur eine Panik verursachen ;-)

Erst mal hier weitergemacht, da ich prinzipiell davon ausgehen muß, dass ich nicht der einzige bin der dich nicht verstanden hat.

Bitte den Smiley am Ende des Satzes zu beachten.

Aber das Du nicht der einzige bist, der mich nicht versteht, kann ich unbesehen unterschreiben. Frag' meine Gattin ;-)

Aber ich kann wirklich schlecht erklären, ich gebe es unumwunden zu.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Kannst Du mir hier mal erklären, wo da der Unterschied liegt?

Ok, hier liegt wohl ein Missverständnis meinerseits. Ich gehe momentan vor allem davon aus, dass der Kommunikationspfad vor externen Angreifern zu schützen ist, weil ich beiden Partnern zunächst mal volles gegenseitiges Vertrauen unterstelle. Daher hat es mich verwirrt, wo du denn dauernd Lügner hervorzaubern willst. Wenn man allerdings davon ausgeht, dass man niemandem ausser sich selbst trauen kann, wird klar was du meinst.

Nein, es ist nur sichergestellt, das Du das Passwort zusammen mit dem Fingerprint bekommen hast.
Mehr nicht.
Noch nicht einmal, ob die beiden zusammengehören, ob der Absender der richtige ist usw.

Ja, da ist die Stelle wieder. Ich bin jetzt mental wohl von dem Bild ausgegangen, wie ich den Account im Institutscomputerpool gekriegt habe: Ich gehe hin, zeige dem netten Herrn dort meinen Studenten- und Personalausweis, er überprüft, ob beide zusammen, zu mir und zu seinen Unterlagen passen. Dann unterschreibe ich die Nutzerordnung und eine Empfangsbestätigung für das Passwort und er händigt mir letzteres aus. Ich bin davon ausgegangen, dass es bei der von mir vorgestellten Anwendung etwa ähnlich abläuft, bloss dass ich zu dem Passwort noch einen Zettel mit dem Fingerprint kriege. Hierbei habe ich aber implizit wieder angenommen, dass die ganze Rechnerbetriebsgruppe eine Einheit bildet und inhärent vertrauenswürdig ist. Also, dass der nette Mann dort nicht derjenige ist, der mich hinters Licht führen will.

Um bei Deinem Beispiel zu bleiben: was ist mit einem Druckfehler?

Ja, da gehe ich wie gesagt davon aus, dass mich ein abweichender Fingerprint alarmiert und ich beim heise-Verlag nachfrage. Daran, dass manipulierte Zeitschriften oder Druckfehler lange überleben, ohne dass es jemand mitkriegt, glaube ich nicht. Wie gesagt, die c't ist dabei dann wieder als vollständig vertrauenswürdig angenommen und ich will mich nur vor externen Angreifern schützen.

Welchem Partner?
Woher weißt Du, das es der Richtige ist? (no pun intended ;-)

Da bin ich davon ausgegangen, dass derjenige der mir gegenüber eine Dienstleistung erbringt, derjenige ist, der mir gegenüber eine Dienstleistung erbringt ;)

Aber ich kann wirklich schlecht erklären, ich gebe es unumwunden zu.

Ich glaube ich habe es jetzt verstanden, hoffe ich...

--
Henryk Plötz
Grüße aus Berlin

[Christoph Zurnieden]

Hallo,

Kannst Du mir hier mal erklären, wo da der Unterschied liegt?

Ok, hier liegt wohl ein Missverständnis meinerseits. Ich gehe momentan vor allem davon aus, dass der Kommunikationspfad vor externen Angreifern zu schützen ist,

Ja, _das_ geht ja auch einwandfrei. Zur Not mit Papier, Bleistift und einer Münze und das auch noch sicher.

weil ich beiden Partnern zunächst mal volles gegenseitiges Vertrauen unterstelle. Daher hat es mich verwirrt, wo du denn dauernd Lügner hervorzaubern willst. Wenn man allerdings davon ausgeht, dass man niemandem ausser sich selbst trauen kann, wird klar was du meinst.

Selbst sich selber kann man nicht trauen. (Man kann sich z.B. auch irren)

Nein, es ist nur sichergestellt, das Du das Passwort zusammen mit dem Fingerprint bekommen hast.
Mehr nicht.
Noch nicht einmal, ob die beiden zusammengehören, ob der Absender der richtige ist usw.

Ja, da ist die Stelle wieder. Ich bin jetzt mental wohl von dem Bild ausgegangen, wie ich den Account im Institutscomputerpool gekriegt habe: Ich gehe hin, zeige dem netten Herrn dort meinen Studenten- und Personalausweis, er überprüft, ob beide zusammen, zu mir und zu seinen Unterlagen passen. Dann unterschreibe ich die Nutzerordnung und eine Empfangsbestätigung für das Passwort und er händigt mir letzteres aus.

Jaja, so ist das hier in D. Hauptsache Stempel und Unterschrift ;-)

Ich bin davon ausgegangen, dass es bei der von mir vorgestellten Anwendung etwa ähnlich abläuft, bloss dass ich zu dem Passwort noch einen Zettel mit dem Fingerprint kriege. Hierbei habe ich aber implizit wieder angenommen, dass die ganze Rechnerbetriebsgruppe eine Einheit bildet und inhärent vertrauenswürdig ist. Also, dass der nette Mann dort nicht derjenige ist, der mich hinters Licht führen will.

Das würde ich aber annehmen und erst später bezahlen;-)
Nein, Scherz beiseite. Auf so einem öffentlichem Server reicht kein Passwort (das ist nur die Zugangsbeschränkung für Dich selber) da mußt Du Dir schon ein verschlüsseltes Datei(system) in Deinem $HOME einrichten und ansonsten davon ausgehen, das da jeder mitlesen kann.

Das ist der Unterschied zwischen realem Leben und Computern: im Leben kannst Du einen gewissen Vertrauensvorschuß vergeben, bei Computern ist prinzipiell Mißtrauen angesagt.
Wenn man das den Benutzern einprügeln könnte, wäre ein ganzer Wirtschaftszweig ziemlich schnell Pleite ;-)

Um bei Deinem Beispiel zu bleiben: was ist mit einem Druckfehler?

Ja, da gehe ich wie gesagt davon aus, dass mich ein abweichender Fingerprint alarmiert und ich beim heise-Verlag nachfrage. Daran, dass manipulierte Zeitschriften oder Druckfehler lange überleben,

Hat Dich denn Deine Mutter nie mit Spinat gestopft "weil da viel Eisen drin ist"? ;-)

ohne dass es jemand mitkriegt, glaube ich nicht. Wie gesagt, die c't ist dabei dann wieder als vollständig vertrauenswürdig angenommen und ich will mich nur vor externen Angreifern schützen.

Der gefährlichste Feind ist meist die eigene Schusseligkeit.

Wahlspruch aus leidvoller Erfahrung ;-)

Welchem Partner?
Woher weißt Du, das es der Richtige ist? (no pun intended ;-)

Da bin ich davon ausgegangen, dass derjenige der mir gegenüber eine Dienstleistung erbringt, derjenige ist, der mir gegenüber eine Dienstleistung erbringt ;)

Ja, jetzt hat er es! ;-)

Mehr kannst Du ganz einfach nicht annehmen.
Alles weiter ist nur Risikominimierung.

Aber ich kann wirklich schlecht erklären, ich gebe es unumwunden zu.

Ich glaube ich habe es jetzt verstanden, hoffe ich...

Wenn Du von jetzt an allem mit Mißtrauem und spitzen Fingern begegnest ... ;-)

so short

Christoph Zurnieden

[Christoph Schnauß]

hi ihr beiden ;-)

Ich habe hier ein ähnlich gelagertes Problem mit einem byzantinischem Voting.

Ich habe eben mal, noch ohne den ganzen vorangegangenen Thread zu lesen, hier herein gklickt (hab das inzwischen selbstverständlich nachgeholt, und auch bis ans aktuelle Thread-Ende gelesen). Da ergibt sich ganz einfach der Eindruck, als ob ihr das Paradoxon "alle Byzantiner lügen immer" lösen wollt.

Christoph Z.: ich kann deiner Argumentation sehr viel abgewinnen, sie zeigt nahezu wörtlich das, was ich bisher kenne.

Henryk: ganz klar ist mir nicht, worauf deine "Widersprüche" beruhen.

Eigentlich redet ihr über dasselbe, bloß mit unterschiedlichen Vokabeln, und es läßt sich (noch) nicht erkennen, wo ihr zentrale sprachliche Begriffe wahrscheinlich unterschiedlich definiert.

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

hi ihr beiden ;-)

Au, verdammt, schon _wieder_ erwischt! ;-)

Aber erstmal und sowieso: Hallo,

Ich habe hier ein ähnlich gelagertes Problem mit einem byzantinischem Voting.
Ich habe eben mal, noch ohne den ganzen vorangegangenen Thread zu lesen, hier herein gklickt (hab das inzwischen selbstverständlich nachgeholt, und auch bis ans aktuelle Thread-Ende gelesen).

Jetzt gib' nicht so an, soviel war das nicht ;-)

Da ergibt sich ganz einfach der Eindruck, als ob ihr das Paradoxon "alle Byzantiner lügen immer" lösen wollt.

Ja, das alte Paradoxon.
(War das nicht mit einer anderen Stadt? Na, egal ;-)

Für die, die sich bis hierhin gewagt haben:
Das vollständige Paradoxon lautet:

"Alle Byzantiner lügen" sprach der alte Byzantiner.

Christoph Z.: ich kann deiner Argumentation sehr viel abgewinnen, sie zeigt nahezu wörtlich das, was ich bisher kenne.

Das ist ja nett, aber eigentlich bin ich ja verzweifelt auf der Suche nach jemandem, er mir das Gegenteil stichhaltig beweisen kann. *sigh*

Henryk: ganz klar ist mir nicht, worauf deine "Widersprüche" beruhen.

Mir schon, ich bin aber wohl mal wieder zu blöd, ihm das zu erklären.

Eigentlich redet ihr über dasselbe, bloß mit unterschiedlichen Vokabeln, und es läßt sich (noch) nicht erkennen, wo ihr zentrale sprachliche Begriffe wahrscheinlich unterschiedlich definiert.

Also versuch ich es noch ein..., nein zweimal.

Ja, das mit den "sprachlichen Begriffen" ist immer so eine Sache. Man kann es mit den international vereinbarten mathematischen Formeln auszudrücken versuchen. Aber das ist meist zwecklos, da "international vereinbart" leider nur unter Mathematikern zu gelten scheint.
Und da wir alle keine sind ... ;-)

Es liegt wahrscheinlich an unserer Sozialisation, das wir uns nicht vorstellen können, es nicht entscheiden zu _können_ ob der Gegenüber lügt oder nicht.
So etwas zu können ist nunmal überlebenswichtig und funktioniert auch meist, wenn wir Menschen gegenüber stehen.

Nun ist das aber nur ein Kiste, eine "black Box". Es ist ihr von außen nicht anzusehen, ob da evt eingebrochen wurde und da jetzt irgendjemand Schabernack treibt. Ja, wir können noch nicht einmal entscheiden, ob die Aufschrift auf der Kiste überhaupt stimmt.

Da wir so nicht arbeiten können, bauen wir uns einen Vertrauensvorschuß auf, der darauf fußt, das es aus Erfahrung weniger Lügner als Wahrheitsliebende gibt. Außerdem ist auch noch die Lüge mit Strafe bewehrt. Wir vertrauen darauf, das diese Strafe einen großen Teil des Restes auch abschreckt.

Daraus basteln wir uns eine Wahrscheinlichkeit zusammen, die ergibt, das es sehr unwahrscheinlich ist belogen zu werden; das es auch noch unwahrscheinlicher ist, wenn irgendjemand für jemand anderen bürgt.

Wenn die Wahrscheinlichkeit gegen Null geht, rundet der gemeine Homo Sapiens einfach und brutal ab. Und wundert sich dann, wenn er auf die Schnauze fällt.

Auch hat der Mensch bedeutend mehr Angst davor, im Meer von einem Hai angefallen zu werden, als an gleicher Stelle zu ertrinken.

Es ist dieselbe Irrationalität des Denkens, die es einem manchmal schwer macht, einfachste mathematische Zusammenhänge plausibel zu machen.

Es macht kein großes Problem das Volumen eines 5-dimensionalen Quaders zu berechnen. x*y*z*a*b. Kein Problem, oder? Wahrscheinlich auch einsichtig, zumindest, wenn man das so schreibt. Aber vorstellen? Gott bewahre!

Und da ich micht jetzt völlig verhaspelt habe, hör ich hier lieber erstmal auf ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hallo Kati,

Die Länge dieses Threads hängt nicht unwesentlich mit
(immer noch) fehlenden Teilen Deiner Aufgabenstellung
zusammen.

also es gibt zwei Textfelder - kennung und password,

müssen das Textfelder sein, oder hast Du nur Textfelder
verwendet, weil Du nichts anderes kennst?
(Ist HTTP Server Authentication - also das kleine
Browser-PopUp, in welches der Benutzer seine Kennung
und ein Passwort eingibt) von Deiner Aufgabenstellung
explizit verboten?)

mit dem sich der User in einer mysql-DB einloggen
kann.

Was genau steht auf Server-Seite noch zur Verfügung?
(Apache?)

Zum Abschicken dieser Daten nutzte ich zuerst einen
submit-Button (post),

Das paßt zum Textfeld - aber siehe oben.

die Daten - sobald sie auf dem Server eingelangt
sind - habe ich mit $HTTP_POST_VARS ausgelesen,

Für das, was ich vor habe, würdest Du an dieser Stelle
eine kleine Änderung vornehmen müssen.
(Server Authentication überträgt die credentials nicht
im Body, sondern in Form von HTTP-Headern.)

Cookies gesetzt

Um die Authentifizierung immer wieder mit zu senden?
Das kann der Browser bei HTTP Authentication viel
eleganter selbst.

und die entsprechenden Operationen in der mysql-DB
durchgeführt.

Welche sind das? (Nur ganz abstrakt.)
Mußt Du ein Session-Konzept umsetzen oder nur eine
Authentifizierung durchführen?

Jetzt habe ich den Button durch einen Link ersetzt,
in welchem ich beim Abschicken auch die content-
Variable setzten möchte und die kennung mit dem
zuvor mit javascript verschlüsselten Password
anhängen möchte.

Die wesentlichste offene Frage lautet: Was mußt Du mit
dem Passwort auf dem Server alles tun _können_?

Reicht es Dir, wenn Du seine Korrektheit überprüfen
kannst? In diesem Falle darfst Du das Passwort client-
seitig mit einer Falltürfunktion verschlüsseln, d. h.
so, daß der Server es _nicht_ wieder entschlüsseln
kann. Auf dem Server speicherst Du das Kennwort in
ebenfalls veschlüsselter Form und vergleichst bei de
Authentifizierung beide Strings - fertig.

Bist Du aber darauf angewiesen, das Original-Passwort
auf dem Server noch zu kennen, dann mußt Du es (ent-
weder nur, oder zusätzlich) auch unverschlüsselt im
Server speichern (um z. B. einem Anwender sein ver-
gessenes Passwort zumailen zu können etc.).

Ob es (von Verfahren her) so richtig ist, weiß ich
nicht

Das hängt von Deiner Aufgabenstellung ab - nicht von
Deinen Kenntnissen.

Also wenn ich den Sinn der Sache auch richtig
verstanden habe, muss ich den Password am Client
verschlüsseln

Ja.

(also mit javascript)

Nein! Nicht nur. Jetzt kommen wir zum nächsten offenen
Problem: Mit welchen Browsern soll das Ganze laufen?

Fast alle Browser können MD5 als fest eingebaute
Funktion - nur Netscape (bis inklusive 6.2) nicht.

Würdest Du Netscape ausnehmen dürfen, dann würde ich
Dein Problem mit Digest Authentication lösen wollen.

und an den Server (auch mit dem Schlüssel usw.)
schicken. Am Server wird dies entschlüsselt.
Ist es so, oder erzähle ich da nen Schmarrn ?

Du erzählst einen Lösungsweg. Ob der zu Deiner
Aufgabenstellung paßt, kann ich mangels Information
über Deine Aufgabenstellung nicht entscheiden.

Viele Grüße
      Michael

[Eisbär]

Hallo Michael

Sorry, wenn ich hier etwas präzisieren muss ;-)

Reicht es Dir, wenn Du seine Korrektheit überprüfen
kannst? In diesem Falle darfst Du das Passwort client-
seitig mit einer Falltürfunktion verschlüsseln, d. h.
so, daß der Server es _nicht_ wieder entschlüsseln
kann. Auf dem Server speicherst Du das Kennwort in
ebenfalls veschlüsselter Form und vergleichst bei de
Authentifizierung beide Strings - fertig.

Bei der Verschlüsselung mit einer Falltürfunktion ist _natürlich_ beim Empfänger (also auf dem Server) eine Entschlüsselung möglich. Dazu wird aber der private Schlüssel benötigt. Typische Verfahren mit Falltürfunktion sind die Public-Key-Verfahren (RSA, etc. ). Dabei meint die Falltür, dass die Verschlüsselung mit dem öffentlichen Schlüssel eigentlich eine Einwegfunktion ist, d.h diese nicht wieder zu entschlüsseln wäre, wenn es nicht einem  passenden privaten Schlüssel gäbe, mit dem die Falltürfunktion den Klartext schnell wieder herstellen kann.

Funktionen, die sich nicht entschlüsseln lassen nennt man Einwegfunktionen (z.B: crypt).

Ich weiss, dies war nur ein kleines Versehen, ich wollte es aber trotzdem nicht so stehen lassen.

Ansonsten bin absolot d'accord.

Grüsse
Eisbär

[Michael Schröpl]

Hallo Eisbär,

Ich weiss, dies war nur ein kleines Versehen, ich
wollte es aber trotzdem nicht so stehen lassen.

danke - bevor mein fehlerhaftes Posting unkommentiert
im Archiv landet und dort irgendwer es per Suchfunktion
findet ...

Viele Grüße
      Michael

[Eisbär]

Hallo Kati

Vom Verfahren her eignet sich in diesem Fall nur eine asymetrische Verschlüsselung wie z.B. RSA.
D. h. im Client verschlüsselst Du das Passwort (oder andere Angaben) mit dem öffentlichen Schlüssel in Javascript und auf dem Server wird das Ganze mit dem privaten Schlüssel entschlüsselt.

Im Javascript-Code steht nur der öffentliche Schlüssel und das Produkt r = (p-1)(q-1) zur Verfügung. Mit diesen Angaben ist die Entschlüsselung ein mathematisch schwer lösbares Problem (Primfaktorzerlegung grosser Zahlen, NP-Problem).
Bei Schlüssellängen > 1000 Bit ist dies derart aufwendig, dass alle zur Verfügung stehende Rechenpower der Erde wahrscheinlich für Jahre in Anspruch genommen werden müsste, um den Klartext zu erhalten.

Das Problem des man-in-the-middle-Angriffs bleibt aber mit der reinen RSA-Verschlüsselung bestehen, es gibt dazu aber Identifizierungsverfahren auf Basis öffentlicher Schlüssel mit denen das Problem gelöst werden kann.

Das Problem in der konkreten Umsetzung liegt darin, dass man in Javascript ein Bibliothek für Langzahl-Arithmetik implementieren muss. Insbesondere benötigt man für RSA eine effiziente Implementation des Montgommery-Algorithmus, woran ich bis jetzt gescheitert bin.

Nicht zu unterschätzen ist auch der Rechenaufwand auf dem Client. Eine Multiplikation zweier Langzahlen in dieser Grössenordnung dauert 1-2 Sekunden bei einem P5 1,3 GHz. Die Divisionen ist sicher noch aufwendiger, diese wird aber für RSA nicht zwingend benötigt, sondern eben die modulare Multiplikation und Reduktion nach Montgommery. Leider weiss ich nicht wie effizient diese im Vergleich sind, noch wie ich diese geeignet in Javascript umsetze.

Falls jemand dazu konstruktive Ideen hätte, wäre ich dankbar.

Grüsse
Eisbär

[Christoph Zurnieden]

Hallo,

Solche serverseitigen Scriptsprachen haben nat. noch viele andere Vorteile. Würd ich mir ma angucken :)

Diesen Vorteil haben sie nicht, aber die ganzen anderen schon, das stimmt.

Ja mag schon sein, aber mit solchen Sprachen kann niemand das Passwort aus dem Quelltext kopieren ;-) Das meinte ich.

Kommt auf den Server an >;->

Wie kommst Du eigentlich darauf, das das Passwort bei Javascript im Quelltext stehen muß? Hier habe ich mal was gebastelt, das zwar mit Papier und Bleistift zu knacken ist, aber das Passwort steht trotzdem nicht im Quelltext. Ich habe es sogar, um ehrlich zu sein, vergessen ;-)
Selbst diese schwache "Verschlüsselung" macht hier in D Sinn, da ein Knacken gegen §202 Stgb verstoßen würde und das reicht in diesem speziellem Fall.
http://mzurnieden.bei.t-online.de/k4.html
(Bitte entschuldige das miese Design, aber ich hatte kurz vor der Fertigstellung einfach keine Zeit und jetzt irgendwie keinen Bock mehr ;-)

so short

Christoph Zurnieden

[Christoph Schnauß]

hallo kati,

Also ich möchte ganz normal Passwörter verschlüsseln

naja, "ganz normal" kann sehr viel bedeuten ;-)

da gibt es eine java-Variante, ein sehr häufiges Algorithmus base64s

Das gibts in nahezu allen Programmiersprachen. Schau doch mal bei google nach, was du da so finden kannst, auf die Schnelle: http://www.google.de/search?q=base64&hl=de&lr=&ie=UTF-8&oe=UTF-8&start=10&sa=N
eine der bekanntesten Anwendungen, die du wahrscheinlich bereits in mehrfacher Ausführung auf deiner Festplatte hast, wird bestimmten mail-Anhängen geliefert: schau dir in Outlook Express oder Outlook einfach mal über "Eigenschaften" den Quelltext einer mail an, in der du nicht nur Text, sondern zusätzlich ein Bild geschickt bekommen hast.

Kann mir jemand genauer erklären, wie es funktioniert - bzw. welche Variante ich bevorzugen sollte.

Das hängt ganz einfach davon ab, wann du wohin und womit etwas übermitteln willst, wo die Verschlüsselung und wo die Entschlüsselung stattfinden soll, und vor allem, vor wem du du denn deine wertvollen Informationen verbergen möchtest.

Da das javascript-Beispiel:
http://www.ideenreich.com/javascript/codieren_javascript.shtml

Ja, nett gemacht. Da sieht es auch so einfach aus ... Nur: Javascript wird auf dem "Client" ausgeführt. Das heißt, wenn du mit Javascriopt irgendwelche Daten ver- und entschlüsseln willst, mußt du diese Daten trotzdem im Klartext übers "Netz" an den Client schicen, damit der dann verachlüsseln kann nach Herzenslust  -  was unter Umständen nicht sehr sinnvoll ist, wenn er hinterher dieselben Daten gleich wieder entschlsüsseln soll, um sie zu verwenden. Da kanns doch gleich bei Klartext bleiben, gelle ? Ok, du kannst ihm auch verschlüsselte Daten schicken, aber dann muß halt zusätzlich den "Schlüssel" kriegen, und den wieder mußt du dann unverschlüsselt übers Netz senden, damit er damit was anfangen kann.

Es gibt außer base64 (womit auch viele Viren verwandt zu sein scheinen, so daß manche Virenscanner Alarm schlagen) noch eine Reihe weiterer Verfahren. Alle behaupten von sich selbst gerne, zuverlässig zu sein, sind sie aber niemals hundertprozentig.

Wichtig ist bei deiner Frage nicht, _was_ und _wie_ verschlüsselt werden soll. Du mußt dir lediglich klar werden, _wozu_ du etwas verschlüsseln willst, wen deine Information erreichen soll und welchen "Angriffspunkten" deine Information unterwegs eventuell ausgesetzt ist. HTTP ist längst nicht das einzige Protokoll, über das im "Netz" Daten übertragen werden.

Schau dir einfach mal in Ruhe an, was dir die oben vorgestellte Google-Suche so alles anbietet. Gleich ist Wochenende, das Wetter ist eh nicht besonders, also hast du Zeit zum Lesen ... ein Beispiel, was sich mit base64 anstellen läßt bzw. anstellen lassen könnte, läßt sich in http://aktuell.de.selfhtml.org/artikel/grafik/inline-images/index.htm nachlesen, obwohl das ein älterer Text ist, zu dessen Entstehungszeit noch kein Netscape6 und kein mozilla veröffentlicht waren.

Grüße aus Berlin

Christoph S.

Grüße aus Berlin

Christoph S.

[Christoph Zurnieden]

Hallo,

Ah, und ich dachte, ich wäre der einzige, der unter Schlaflosigkeit leidet ;-)

Also ich möchte ganz normal Passwörter verschlüsseln
naja, "ganz normal" kann sehr viel bedeuten ;-)

Es gibt außer base64 (womit auch viele Viren verwandt zu sein scheinen, so daß manche Virenscanner Alarm schlagen) noch eine Reihe weiterer Verfahren. Alle behaupten von sich selbst gerne, zuverlässig zu sein, sind sie aber niemals hundertprozentig.

Doch das ginge durchaus, nur habe ich noch nirgendwo eine Javascriptimplementation einer kräftigen (min 1024 Bit) asymetrischen Verschlüsselung gefunden.

Wichtig ist bei deiner Frage nicht, _was_ und _wie_ verschlüsselt werden soll. Du mußt dir lediglich klar werden, _wozu_ du etwas verschlüsseln willst, wen deine Information erreichen soll und welchen "Angriffspunkten" deine Information unterwegs eventuell ausgesetzt ist. HTTP ist längst nicht das einzige Protokoll, über das im "Netz" Daten übertragen werden.

Ja, aber SSL wird nur akzeptiert, wenn auch ein Zertifikat vorhanden ist und das ist nunmal schweineteuer.

Schau dir einfach mal in Ruhe an, was dir die oben vorgestellte Google-Suche so alles anbietet. Gleich ist Wochenende, das Wetter ist eh nicht besonders,

Angeblich soll es ja richtig knallig heiß werden am Wochenende.
Na, mal abwarten ;-)

also hast du Zeit zum Lesen ... ein Beispiel, was sich mit base64 anstellen läßt bzw. anstellen lassen könnte, läßt sich in http://aktuell.de.selfhtml.org/artikel/grafik/inline-images/index.htm nachlesen, obwohl das ein älterer Text ist, zu dessen Entstehungszeit noch kein Netscape6 und kein mozilla veröffentlicht waren.

Wenn die das wieder mitmachen sollten die sich was schämen! Base64 macht die ganze Sache ja schließlich um ein sattes Drittel größer!

so short

Christoph Zurnieden

[Ed X]

Hi,

Es gibt außer base64 (womit auch viele Viren verwandt zu sein scheinen, so daß manche Virenscanner Alarm schlagen) noch eine Reihe weiterer Verfahren. Alle behaupten von sich selbst gerne, zuverlässig zu sein, sind sie aber niemals hundertprozentig.

Doch das ginge durchaus, nur habe ich noch nirgendwo eine Javascriptimplementation einer kräftigen (min 1024 Bit) asymetrischen Verschlüsselung gefunden.

http://shop-js.sourceforge.net/crypto2.htm
unglaublich, oder?

also hast du Zeit zum Lesen ... ein Beispiel, was sich mit base64 anstellen läßt bzw. anstellen lassen könnte, läßt sich in http://aktuell.de.selfhtml.org/artikel/grafik/inline-images/index.htm nachlesen, obwohl das ein älterer Text ist, zu dessen Entstehungszeit noch kein Netscape6 und kein mozilla veröffentlicht waren.

Wenn die das wieder mitmachen sollten die sich was schämen! Base64 macht die ganze Sache ja schließlich um ein sattes Drittel größer!

wenn du base64 in JS machen willst, kannst du ja hier noch mal lesen.
http://aktuell.de.selfhtml.org/artikel/javascript/utf8b64/preface.htm
hier findest du dann auch den Einsatzzweck von base64. Das ist eher
eine codierung denn eine verschlüsselung. wenn du verschlüsseln willst
solltest du RC4 in JS implementieren. Den source findest du unter dem
obigen link mit dem JS-Shop(ist da im quelletext versteckt)

bye eddie

[Christoph Zurnieden]

Hallo,

Es gibt außer base64 (womit auch viele Viren verwandt zu sein scheinen, so daß manche Virenscanner Alarm schlagen) noch eine Reihe weiterer Verfahren. Alle behaupten von sich selbst gerne, zuverlässig zu sein, sind sie aber niemals hundertprozentig.

Doch das ginge durchaus, nur habe ich noch nirgendwo eine Javascriptimplementation einer kräftigen (min 1024 Bit) asymetrischen Verschlüsselung gefunden.

http://shop-js.sourceforge.net/crypto2.htm
unglaublich, oder?

Unglaublich nicht, höchstens der Umstand, das er ausgerechnet auf Sourceforge hostet, wo ich eigentlich regelmäßig verkehre ;-)

Allerdings möchte ich auch auf die Lizenzprobleme bezüglich RC4 hinweisen.
http://download.baltimore.com/keytools/docs/v50/crypto/j-docs/html/cryptojdevguide-1.1.html

Zudem ist die Implementation auf http://shop-js.sourceforge.net/crypto2.htm kryptographisch unsauber.
Auch erfüllt es keine meiner Anforderungen.

Ich kann mich also abschließend nur wiederholen:" [...] habe ich noch nirgendwo eine Javascriptimplementation einer kräftigen (min 1024 Bit) asymetrischen Verschlüsselung gefunden."

also hast du Zeit zum Lesen ... ein Beispiel, was sich mit base64 anstellen läßt bzw. anstellen lassen könnte, läßt sich in http://aktuell.de.selfhtml.org/artikel/grafik/inline-images/index.htm nachlesen, obwohl das ein älterer Text ist, zu dessen Entstehungszeit noch kein Netscape6 und kein mozilla veröffentlicht waren.

Wenn die das wieder mitmachen sollten die sich was schämen! Base64 macht die ganze Sache ja schließlich um ein sattes Drittel größer!

wenn du base64 in JS machen willst, kannst du ja hier noch mal lesen.
http://aktuell.de.selfhtml.org/artikel/javascript/utf8b64/preface.htm

Na, danke, aber das würde ich mir nicht nehmen lassen, es selber zu machen ;-)

hier findest du dann auch den Einsatzzweck von base64. Das ist eher
eine codierung denn eine verschlüsselung. wenn du verschlüsseln willst
solltest du RC4 in JS implementieren.

RC4 kommt aus Lizenzgründen überhaupt nicht in Frage.

so short

Christoph Zurnieden

[Ed X]

Hallo Christoph,

Allerdings möchte ich auch auf die Lizenzprobleme bezüglich RC4 hinweisen.
http://download.baltimore.com/keytools/docs/v50/crypto/j-docs/html/cryptojdevguide-1.1.html

ich lehne mich mal "juristisch" aus dem Fenster. Meine Annahme:

RC4 ist "closed source". Der Quelltext, der irgenwann mal in einer
Newsgroup geposted wurde, ist zwar offensichtlich mit RC4 compatibel,
aber es AFAIK nie bestätigt oder auch bestritten wurden, dass es sich
um den RC4 Algorithmus handelt. D.h. du darfst schon mit dem Algorithmus
arbeiten, "RC4" draufschreiben darfst du nicht.
So in etwa lese ich auch das von dir angeführte Zitat.

bye eddie

[Christoph Zurnieden]

Hallo,

Allerdings möchte ich auch auf die Lizenzprobleme bezüglich RC4 hinweisen.
http://download.baltimore.com/keytools/docs/v50/crypto/j-docs/html/cryptojdevguide-1.1.html

ich lehne mich mal "juristisch" aus dem Fenster. Meine Annahme:

RC4 ist "closed source". Der Quelltext, der irgenwann mal in einer
Newsgroup geposted wurde, ist zwar offensichtlich mit RC4 compatibel,
aber es AFAIK nie bestätigt oder auch bestritten wurden, dass es sich
um den RC4 Algorithmus handelt. D.h. du darfst schon mit dem Algorithmus
arbeiten, "RC4" draufschreiben darfst du nicht.
So in etwa lese ich auch das von dir angeführte Zitat.

Ja, ist ein wenig schlecht gewählt, das Zitat. War das erste das Goggle ausspuckte ;-)

Das Problem ist aber wirklich die Lizensierung. Das sind IMHO Amerikaner und so, wie die Amerikaner drauf sind (und der Rest der Welt langsam auch mitläuft) kann es trotzdem Ärger geben. Man sollte die Verwendung solchen Codes einfach vermeiden, um jedem Ärger von Vornherein aus dem Weg zu gehen. Es gibt zudem genügend freie und vor allem bessere Alternativen.

so short

Christoph Zurnieden

[Henryk Plötz]

Moin,

Es gibt außer base64 (womit auch viele Viren verwandt zu sein scheinen, so daß manche Virenscanner Alarm schlagen) noch eine Reihe weiterer Verfahren. Alle behaupten von sich selbst gerne, zuverlässig zu sein, sind sie aber niemals hundertprozentig.

Du hast vergessen eindeutig zu erwähnen, dass base64 _keine Verschlüsselung_ ist. Base64 ist eine Kodierung die man verwendet, wenn man 8bit-Zeichen über Transportwege schicken will, die unter Umständen nur 7bit-Zeichen kennen. Dabei werden aus 24 Eingabebits 4 Ausgabezeichen gemacht: Es werden 3 8bit-Zeichen zusammengehängt, als 4 6bit-Gruppen betrachtet und jede davon auf einziges Zeichen des base64-Alphabets (A bis Z, a bis z, 0 bis 9, +, /, am Ende des Textes wird = zum Auffüllen benutzt) abgebildet. Wenn man aus dem base64-codierten Text wieder normalen Text machen will, kehrt man den Prozess einfach um.

Das ist keine Verschlüsselung, das eignet sich nicht mal wirklich zum Verschleiern.

Mails die binäre Daten enthalten, werden fast ausschliesslich base64-codiert übertragen, und da Würmer oder Viren häufig aus binärem Programmcode bestehen, dürfte das der Grund für deinen nervösen Virenscanner sein.

Der gesamte Prozess ist in RFC 1341, Abschnitt 5.2 beschrieben: http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
--
Henryk Plötz
Grüße aus Berlin

[Christoph Schnauß]

hi Henryk,

Du hast vergessen eindeutig zu erwähnen, dass base64 _keine Verschlüsselung_ ist. Base64 ist eine Kodierung die man verwendet, wenn man 8bit-Zeichen über Transportwege schicken will, die unter Umständen nur 7bit-Zeichen kennen.

ähm, du Schlaumeier ;-)
nein, hab ich keineswegs vergessen, aber bewußt ausgelassen, weil es mir so schien, daß ich damit kati doch etwas überfordern würde. Dein Hinweis kommt allerdings völlig richtig und ist sicher auch für manchen hilfreich.

Grüße

Christoph S.

[Henryk Plötz]

Moin,

nein, hab ich keineswegs vergessen, aber bewußt ausgelassen,

Sowas dachte ich mir schon. Du hast in der Vergangenheit häufiger mal "bewußt ausgelassen", habe ich den Eindruck.

weil es mir so schien, daß ich damit kati doch etwas überfordern würde.

Das ist hierbei egal, denn das muss gesagt werden. Stell dir mal vor, Kati würde ihre Passwörter jetzt base64-'verschlüsselt' durch die Gegend schicken, und an Sicherheit glauben. Das ist IMvHO kontraproduktiv.

--
Henryk Plötz
Grüße aus Berlin

[Christoph Zurnieden]

Hallo,

vielleicht habe schon viele diese Frage gestellt, ich konnte aber trotzdem nichts passendes finden, da ich mich mit dem Codieren nur sehr wenig auskenne. Daher frage ich direkt hier. Also ich möchte ganz normal Passwörter verschlüsseln. Da gibt es eine java-Variante, ein sehr häufiges Algorithmus base64s. Kann mir jemand genauer erklären, wie es funktioniert - bzw. welche Variante ich bevorzugen sollte.

Naja, base64 ist es ja wohl kaum, was? ;-)

Hier mal die kurze aber immer gültige Regel der Kryptographie:
"Security thru obscurity does not work!"

Eine meiner Ableitungen noch dazu:
"Wenn Dir einer nicht erklären kann/darf/will wie ein Schutz funktioniert, dann funktioniert er nicht!"

Aber wenn Du nur ein Passwort verschlüsseln möchtest weil Du Dir die teuren Zertifikate für die SSL Schlüssel nicht leisten kannst, dann nimm einfach md5sum, das ist meistens ausreichend.

http://aktuell.de.selfhtml.org/artikel/javascript/md5/index.htm
(Public Domain)

Außerdem ergab eine kurze Suche bei Google noch folgenden Link:

http://webdeveloper.earthweb.com/webjs/item/0,3602,12754_40991,00.html
(Public Domain)

(Der Link "see the code" ist eine Verarsche, nimm "run the code". Da stehen dann die einzelnen Links zum bequemem Download direkt verlinkt. Du brauchst übrigens alle, je nachdem, was Du machen möchtest. Ist aber sehr kurz alles.)

Wenn Du viel Text, also etwas mehr als nur ein Passwort, verschlüsseln mußt, kommst Du um SSL allerdings leider nicht herum.

Aber Vorsicht:
Es besteht beim schlichtem MD5sum Verschlüsseln die Gefahr, daß jemand die MD5sum abfangen und mit Anschrift und Absender in Zusammenhang bringen kann. Für eine regelgerechte Verschlüsselung ist das also nicht geeignet, dafür braucht es asymetrische Methoden, wie z.B. PGP. Das dürfte aber in Javascript etwas aufwendig zu implementieren sein.

Aber wäre vielleicht mal eine interessante Aufgabe ;-)

Wenn Du Scripte auf dem Server laufen lassen kannst, die eine Session-ID generieren können, dann kannst Du die inklusive der IP des Clients mit reinhängen. Das ist dann etwas aufwendiger zu umgehen und benötigt ein Wissen, das die einfachen Script-Kiddies nicht haben.
Aber richtig sicher ist das natürlich auch nicht!

Du mußt also überlegen, wofür Du die Verschlüsselung brauchst. Nur um ein paar kompromitierende Bildchen zu schützen reicht die MD5Sum + .htaccess Methode.
Für den Zugriff auf die Steuerunterlagen würde ich SSL bevorzugen und für die Pläne der Atombombe 'rm -rfv *'

so short

Christoph Zurnieden

PS:
Irgendjemand erzählte mir mal etwas von einem MiniSSL, das aus einem clientseitigem Java-Applet besteht und einem kleinem Perlscript auf der Serverseite. Ich finde es nur nicht mehr wieder.
Hat außerdem den Nachteil nicht nur Javascript sondern sogar Java zu brauchen.
CZ