nicht angemeldet
PHP - JavaScipt - verschlüsselt
0 0 0 0 0 0
1 0 0 1 0 
Der Martin
0 1 0 Der Martin
0 0 Der Martin
0 0
1
PHP - JavaScipt - verschlüsselt
Hi,
ist es möglich, per PHP einen String verschlüsselt auszugeben.
Cleintseitig soll dann per JavaScript und nach Eingabe des richtigen Verschlüsselungsschlüssels der von PHP ausgegebene String entschlüsselt werden.
Geht soetwas?
verti
p.s.
Am besten noch so, dass das Skript nicht eingebunden ist sondern per Browserplugin auf die Website angewendet wird ...
-
Cleintseitig soll dann per JavaScript und nach Eingabe des richtigen Verschlüsselungsschlüssels der von PHP ausgegebene String entschlüsselt werden.
Geht soetwas?
Sicher - suche dir einen Algorithmus der sowohl in PHP alsauch in JavaScript zur Verfügung steht oder implementiere selbst einen.
Am besten noch so, dass das Skript nicht eingebunden ist sondern per Browserplugin auf die Website angewendet wird ...
Warum - glaubst du dadurch würde sich die Sicherheit erhöhen?
-
Nachtrag:
Wozu soll das überhaupt gut sein?
-
-
Hi verti.
ist es möglich, per PHP einen String verschlüsselt auszugeben.
Ja :-)
Cleintseitig soll dann per JavaScript und nach Eingabe des richtigen Verschlüsselungsschlüssels der von PHP ausgegebene String entschlüsselt werden.
Geht soetwas?
Natuerlich geht das, ist aber kaum empfehlenswert. Es gibt im WWW geschaetzte 37 Zillionen Websites, die Daten bereit halten, die nicht fuer jedermann zugaenglich sind. Und in so gut wie allen Faellen ist der (vernuenftigeste) Weg, das zu realisieren, die Daten nicht-legitimerten Benutzern nicht verschluesselt, sonderen gar nicht zugaenglich zu machen, und legitimierten Nutzern (nach Identifizierung) unverschluesselt*. Das Stichwort lautet 'Login'.
Faelle, in denen Dein Vorhaben sinnvoll ist, sind vielleicht denkbar - mir wuerde was einfallen im Grossraum von Browsergames und Raetselseiten. Ein anderer naheliegender Gedanke waere eine digitale Signatur, aber dafuer gibtes wiederum ganz andere Wege als sie selbst ins HTML-Dokument einzubauen.
Was hast Du vor?
* Ggf. verschluesselt auf 'Protokoll-Ebene', aber nicht auf 'HTML-Ebene'
Viele Gruesse,
der Bademeister-
Hello,
Natuerlich geht das, ist aber kaum empfehlenswert. Es gibt im WWW geschaetzte 37 Zillionen Websites, die Daten bereit halten, die nicht fuer jedermann zugaenglich sind. Und in so gut wie allen Faellen ist der (vernuenftigeste) Weg, das zu realisieren, die Daten nicht-legitimerten Benutzern nicht verschluesselt, sonderen gar nicht zugaenglich zu machen, und legitimierten Nutzern (nach Identifizierung) unverschluesselt*. Das Stichwort lautet 'Login'.
Wie stellst Du Dir denn die Kette zwischen "Ersteller" und "legitimierter Datennutzer" vor?
zu anderen
Gangstern
zu den Gangstern ^
|
^ |
+---------+ | +-------------------+ +------------------+ +~~~~~ ~~+
|Ersteller| | |Port in der | |Primärmultiplexer | |Diverse Hobs |
|Sichere |--------------|Vermittlungsstelle |------| |-------| |---- usw.
|Zone |Kabel zum Port|(add Tags) | | | | |
+---------* +-------------------* +------------------+ +
| |
| |
v v
Zur Überwachung zu den Tag-Filtern
|
v
zur Überwachungusw.
Das Paket kommt dann vermutlich untagged beim Provider an (nächste Sicherheitslücken)
und wird von dem über eine ähnliche Kette, wie die obige, nur Rückwärts, wieder abgerufen...Wo willst Du da Sicherheit vermuten? Wenn Inhalte verschlüsselt sein sollen, müssen sie das auf der gesamten Strecke von der einen sicheren Zone in die andere.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Wenn Inhalte verschlüsselt sein sollen, müssen sie das auf der gesamten Strecke von der einen sicheren Zone in die andere.
Das passiert hoffentlich durch SSL/TSL im ausreichend Maß ;)
-
Hello,
Wenn Inhalte verschlüsselt sein sollen, müssen sie das auf der gesamten Strecke von der einen sicheren Zone in die andere.
Das passiert hoffentlich durch SSL/TSL im ausreichend Maß ;)
Du scheinst mein Posting nicht aufmerksam genug gelesen zu haben und deshalb wohl auch nicht darüber nachgedacht zu haben...
Durch SSL/TSL kannst Du nur den Datentransfer schützen, nicht aber den Speicherplatz beim Provider.
Also denk nochmal nach, und sag mir dann, ob Du das Vorhaben des verti dann immer noch für unsinnig erachtest.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Durch SSL/TSL kannst Du nur den Datentransfer schützen, nicht aber den Speicherplatz beim Provider.
Also denk nochmal nach, und sag mir dann, ob Du das Vorhaben des verti dann immer noch für unsinnig erachtest.
Wenn PHP etwas verschlüsseln soll und JavaScript am Client wieder entschlüsseln, müssen die Daten dann offenbar unverschlüsselt vorliegen - oder täusche ich mich da?
Im Grunde wird also nur der Transfer geschützt - und das mit einer selbstgestrickten, möglicherweise gefährlichen Methode.
-
Hello,
Wenn PHP etwas verschlüsseln soll und JavaScript am Client wieder entschlüsseln, müssen die Daten dann offenbar unverschlüsselt vorliegen - oder täusche ich mich da?
Es ist ja durchaus möglich, die Daten bereits am Client per PHP zu verschlüsseln ;-P
Prinzipiell kann man natürlich in diese unklare Frage Diverses hineininterpretieren.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Es ist ja durchaus möglich, die Daten bereits am Client per PHP zu verschlüsseln ;-P
Prinzipiell kann man natürlich in diese unklare Frage Diverses hineininterpretieren.Jaja, und JavaScript könnte auch am Server laufen.
"Du hast zwei Bananen: eine ist rot die andere fährt Bus. Plötzlich beginnt es zu regnen - warum?"
-
Hello,
Es ist ja durchaus möglich, die Daten bereits am Client per PHP zu verschlüsseln ;-P
Prinzipiell kann man natürlich in diese unklare Frage Diverses hineininterpretieren.Jaja, und JavaScript könnte auch am Server laufen.
"Du hast zwei Bananen: eine ist rot die andere fährt Bus. Plötzlich beginnt es zu regnen - warum?"
*ROTFL*
Ich mag aber lieber Äpfel. Beeinflusst das jetzt auch das Ergebnis?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ich mag aber lieber Äpfel. Beeinflusst das jetzt auch das Ergebnis?
Sofern du dich jetzt als Mac-User geoutet hat, rede ich nicht mehr mit dir :D
-
Hello,
Ich mag aber lieber Äpfel. Beeinflusst das jetzt auch das Ergebnis?
Sofern du dich jetzt als Mac-User geoutet hat, rede ich nicht mehr mit dir :D
*au*
Man muss wirklich _genau_ überlegen, in welchen Kontext eine Aussage hier geschoben werden kann ;-)Ich bin WinDOS und Linux-User. Die anderen Betriebssysteme, die ich benutzt habe, gibt es wohl auch gar nicht mehr. Aber seitdem der Mac BSD-Unix verwendet, ist er mir auch relativ sympathisch geworden...
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Ich bin WinDOS und Linux-User. Die anderen Betriebssysteme, die ich benutzt habe, gibt es wohl auch gar nicht mehr. Aber seitdem der Mac BSD-Unix verwendet, ist er mir auch relativ sympathisch geworden...
BSD - du Träumer :) das ist so wie wenn man sagt Ubuntu wäre Debian :p
-
-
-
-
-
-
-
-
-
Hi Tom.
Wie stellst Du Dir denn die Kette zwischen "Ersteller" und "legitimierter Datennutzer" vor?
Wenn Du mit 'Ersteller' nicht den Server meinst, der die Daten ausliefert, sondern tatsaechlich den (ggf. menschlichen) Ersteller, dann interessiert mich diese Kette bisher nicht die Bohne, weil sie weder von verti irgendwie beschrieben wurde, noch Gegenstand der Frage war.
Ist Dein Einwand so zu verstehen, dass die Daten ggf. dem Server zunaechst nur verschluesselt vorliegen? Dann koennte der genau das tun, was verti dem Client per Javaspript zumuten wollte: sie entschluesseln.
Oder was verstehe ich an Deiner Frage nicht?
|Viele Gruesse,
der Bademeister-
Hello,
Wie stellst Du Dir denn die Kette zwischen "Ersteller" und "legitimierter Datennutzer" vor?
Wenn Du mit 'Ersteller' nicht den Server meinst, der die Daten ausliefert, sondern tatsaechlich den (ggf. menschlichen) Ersteller, dann interessiert mich diese Kette bisher nicht die Bohne, weil sie weder von verti irgendwie beschrieben wurde, noch Gegenstand der Frage war.
Ist Dein Einwand so zu verstehen, dass die Daten ggf. dem Server zunaechst nur verschluesselt vorliegen? Dann koennte der genau das tun, was verti dem Client per Javaspript zumuten wollte: sie entschluesseln.
Wie soll der Server die Daten denn entschlüsseln, wenn er den Schlüssel nicht hat?
Ich verstehe jetzt Deinen Einwand nicht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi
Wie soll der Server die Daten denn entschlüsseln, wenn er den Schlüssel nicht hat?
Ich verstehe jetzt Deinen Einwand nicht.
Es ist jetzt natürlich alles etwas Raterei über das genaue Szenario hier. Aber wenn ich den Server mit (wie auch immer verschlüsselten) Daten versorge, die er einfach ungesehen ausliefern soll, dann ist bei der Server-Client-Kommunikation überhaupt kein Verschlüsselungsaspekt im Spiel: Der Server sendet einfach (aus seiner Sicht) Rohdaten, und die ursprüngliche Frage des OP, ob man mit PHP verschlüsselte Daten senden könne, ist völlig leer.
Und so liest sich die Frage
ist es möglich, per PHP einen String verschlüsselt auszugeben[?]
auch nicht, oder?
Sein Plan ist offenbar, dem Server vorliegende Klartext-Daten per PHP zu verschlüsseln, um sie dann vom Client per Javascript wieder entschlüsseln zu lassen. Und bei Verschlüsselung gilt immer: Besser, als dem Feind verschlüsselte Daten zu liefern, ist, ihm gar keine Daten zu liefern.
Natürlich mag es auch nach einer Authentifizierung des Clients noch notwendig sein, die Daten zu verschlüsseln, um sie beim Transport vor Dritten zu schützen. Aber: Ein Schlüssel ist nicht dasselbe wie ein Passwort, und muss im allgemeinen sehr viel länger sein aus Gründen, die Alexander geschildert hat: Wenn jemand den verschlüsselten Text in Händen hält, hat man keine Möglichkeit, Brute-Force-Attacken zu verhindern, der Schlüssel muss ihnen also standhalten*. Daher ist ein guter Schlüssel je nach Szenario nicht 10 Bytes lang wie ein handliches Passwort, sondern vielleicht 500 oder dergleichen. Und eignet sich daher nicht, um den Client händisch damit hantieren zu lassen.
* Dieser Aspekt kommt ein bisschen auf die Natur der Daten an: es kann theoretisch sein, dass man nach einer Dechiffrierung mit einem geratenen Schlüssel nicht entscheiden kann, ob der erzeugte Klartext der richtige ist oder nicht. Das ist aber sehr sehr sehr sehr unwahrscheinlich: Bei irgendwelchem Text (im Sinne von: natürliche Sprache) im Klartext ohnehin, aber auch bei jeder anderen Art von (nicht zufällig generierten) Daten ist es praktisch nie der Fall.
Viele Grüße,
der Bademeister-
Hello,
Sein Plan ist offenbar, dem Server vorliegende Klartext-Daten per PHP zu verschlüsseln, um sie dann vom Client per Javascript wieder entschlüsseln zu lassen. Und bei Verschlüsselung gilt immer: Besser, als dem Feind verschlüsselte Daten zu liefern, ist, ihm gar keine Daten zu liefern.
Das war mir klar, darum habe ich ja darauf hingewiesen:
"Wenn Inhalte verschlüsselt sein sollen, müssen sie das auf der gesamten Strecke von der einen sicheren Zone in die andere."
Und wenn ich das an Dich gerichtet hatte, war es auch in der Annahme/Hoffnung, dass der OP überhaupt noch mitliest. Das weiß man ja leider nur selten. Dass Du das Szenario eigentlich kennst, ist mir auch klar :-))
Das Ansinnen des OP war also in sich schon unvollständig durchdacht.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Moin Moin!
Und bei Verschlüsselung gilt immer: Besser, als dem Feind verschlüsselte Daten zu liefern, ist, ihm gar keine Daten zu liefern.
Klar, aber manchmal muß man Daten übertragen, Feind hin oder her.
Da bietet es sich an, den Datenübertragungsweg zu 100% mit Rauschen vollzumüllen, so dass der Feind kaum eine Chance hat, die Nutzdaten zu finden. Man setzt die härtestmögliche Verschlüsselung ein, mit oft wechselnden Schlüsseln, und verschlüsselt irgendwelchen "Müll". Linux Kernel Sources, Bibel- und Korantexte, das komplette Projekt Gutenberg, meinetwegen die kompletten Debian- und BSD-Sources, und so weiter, gibt ja genügend Text im Netz. Immer in Häppchen der typischen Nachrichtengröße. Und irgendwo zwischen den Gigabytes an Datenmüll sind dann mal 500 Bytes Geheimnachricht unterwegs.
Der Feind sieht verschlüsselte Daten, in riesigen Mengen, und muß jede einzelne Nachricht mit sehr viel Aufwand knacken, BEVOR er die Nachricht als Müll oder echte Nachricht klassifizieren kann.
Der Empfänger dagagen hat es einfacher, sein Schlüssel paßt ohnehin nur zur echten Nachricht, alles andere kann er vollautomatisch aussortieren.
Manchmal reicht es sogar aus, ein oder zwei Bit zu übertragen. Und dann kann man richtig gemein werden: Man vereinbart, eine bestimmte Nachricht zu senden. Stammt ihr Müll-Inhalt aus Projekt Gutenberg, zählt das als Bit = 0, stammt sie aus den Kernel Sources, zählt das als Bit = 1. Und der Feind sieht nur noch Müll. Oder man definiert das Eintreffen einer entschlüsselbaren Nachricht innerhalb eines gewissen Zeitraums als Bit = 1, ihr Ausbleiben als Bit = 0. (Die Müll-Sende-Automatik sorgt dafür, dass stattdessen eine Müll-Nachricht ihren Platz einnimmt.) Die Nachricht selber enthält den gleichen "Müll" wie die Müll-Nachrichten.
Wenn der Sender-Standort ein Geheimnis sein soll, ist natürlich jede anpeilbare Sendung eine Sendung zu viel. Aber das ist eine völlig andere Geschichte.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hi Alexander.
Da bietet es sich an, den Datenübertragungsweg zu 100% mit Rauschen vollzumüllen, so dass der Feind kaum eine Chance hat, die Nutzdaten zu finden. Man setzt die härtestmögliche Verschlüsselung ein, mit oft wechselnden Schlüsseln, und verschlüsselt irgendwelchen "Müll". Linux Kernel Sources, Bibel- und Korantexte, das komplette Projekt Gutenberg, meinetwegen die kompletten Debian- und BSD-Sources, und so weiter, gibt ja genügend Text im Netz. Immer in Häppchen der typischen Nachrichtengröße. Und irgendwo zwischen den Gigabytes an Datenmüll sind dann mal 500 Bytes Geheimnachricht unterwegs.
Klingt gut. Dann würde ich zwischendurch noch die Mutter des potentiellen Angreifers beleidigen. Wenn es jemand entschlüsselt, kann er mich ja verklagen, wenn er will... ;-)
Viele Grüße,
der Bademeister-
Hello,
Klingt gut. Dann würde ich zwischendurch noch die Mutter des potentiellen Angreifers beleidigen. Wenn es jemand entschlüsselt, kann er mich ja verklagen, wenn er will... ;-)
Interessante Überlegung. Zählt die Beleidung dann nicht, wenn man sie verschlüsselt?
Dann werde ich mir jetzt mal ein paar heftige Dinger ausdenken und hier veröffentlichen. Ich hoffe nur, dass Henryk dann nicht gerade mal eine freie Minute hat ;-))Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Interessante Überlegung. Zählt die Beleidung dann nicht, wenn man sie verschlüsselt?
Ich vermute schon, dass sie zaehlt (um mal im juristischen Fachjargon zu bleiben ;-)).
Meine Ueberlegung ging eher in die Richtung, dass es vom Angreifer sowohl in strategischer als auch in rechtlicher Hinsicht nicht gerade ne Meisterleistung waere, zum Richter zu rennen und zu sagen: 'Ich habe seinen Code geknackt!' :-)Viele Gruesse,
der Bademeister
-
-
Moin Moin!
Klingt gut.
Ja, ist leider nur nicht auf meinem Mist gewachsen...
Dann würde ich zwischendurch noch die Mutter des potentiellen Angreifers beleidigen. Wenn es jemand entschlüsselt, kann er mich ja verklagen, wenn er will... ;-)
Und als Seiteneffekt weißt Du gleich, wer Dich abhört, und dass Dein Verschlüsselungsalgorithmus oder wenigstens der für die Nachricht benutzte Schlüssel gekackt ist. Du kannst daraus sogar eine Obergrenze für die Zeit ableiten, die Dein Feind brauchte, um den Schlüssel zu knacken (vom Zeitpunkt der ersten Schlüsselnutzung bis zum Zeitpunkt der Anklageschrift). Entsprechend häufiger wechselst Du dann die Schlüssel.
Blöd nur, wenn der Bösewicht Dich nicht verklagt, sondern stumpf erschießt, weil Du es mit seiner vermeindlichen Abstammungsgeschichte aus großen Teilen des Tierreichs und seinen anatomischen Besonderheiten "etwas" übertrieben hast. ;-)
Fast passend dazu: Einen Schweden einen Schweden nennen (via)
Im Ernst: Feind in diesem Fall ist jemand, der über sehr viel sehr teure Technik verfügt. Harte Verschlüsselungen knackt man nicht mit dem Taschenrechner, dafür stellt man Spezialhardware und/oder Großrechner und/oder Rechner-Cluster hin. Und irgendwie muß der Feind auch an die Daten herankommen. Wenn Du eine 100 MBit/s-Leitung rund um die Uhr mit verschlüsseltem Müll sättigen kannst, hat Dein Feind einiges an Infrastruktur aufzufahren, nur um überhaupt mit dem Aufzeichnen mithalten zu können. Denn er muß aufzeichnen, weil das Knacken wesentlich länger dauert als das Übertragen der Daten. Dein Feind ist dann wohl eher kein Einzelkämpfer, sondern eine größere Organisation mit entsprechenden Mitteln.
Und weil Du das weißt, sättigst Du nicht nur eine Leitung, sondern ein ganzes Bündel von unterschiedlichen Providern mit Müll, und packst die Nutzdaten mal in die eine, mal in die andere Leitung.
Das läßt sich noch beliebig weiter spinnen: Steganographie (die Nachricht steht z.B. in den Leerzeichen und/oder Rechtschreibfehlern), mehrfach geschachtelte Verschlüsselung (mit unterschiedlichen Verfahren und unterschiedlichen Schlüsseln), Codewörter statt Klartext. Das steigert nicht unbedingt die Sicherheit, aber es steigert den Aufwand der Auswertung.
Und an ganz sadistischen Tagen, wenn Du lange genug verschieden tief verschachtelte Nachrichten gesendet hast, fügst Du gelegentlich echtes, aus einem Hardware Random Number Generator (z.B. thermisches Rauschen eines Halbleiters) erzeugtes Rauschen als Nachricht ein, so dass es aussieht wie eine weitere Verschlüsselungsebene. Gerne auch "versehentlich" mit einem bereits geknackten Schlüssel.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Und an ganz sadistischen Tagen, wenn Du lange genug verschieden tief verschachtelte Nachrichten gesendet hast, fügst Du gelegentlich echtes, aus einem Hardware Random Number Generator (z.B. thermisches Rauschen eines Halbleiters) erzeugtes Rauschen als Nachricht ein, so dass es aussieht wie eine weitere Verschlüsselungsebene. Gerne auch "versehentlich" mit einem bereits geknackten Schlüssel.
Ich seh schon: wenn Du was verschluesselt, dann meinst Du's ernst :-)
Aber eins ist mir nicht ganz klar:
Der Empfänger dagagen hat es einfacher, sein Schlüssel paßt ohnehin nur zur echten Nachricht, alles andere kann er vollautomatisch aussortieren.
Was meinst Du damit genau? 'Vollautomatisch' heisst doch immer noch: alles entschluesseln (oder zumindest einen Teil jedes Nachrichteblocks) und dann entscheiden, ob es die Nachricht ist oder 'Rauschen', oder? Oder geht das effizienter?
Viele Gruesse,
der Bademeister-
Moin Moin!
Ich seh schon: wenn Du was verschluesselt, dann meinst Du's ernst :-)
Zumindest weiß ich, wie man Abhörern das Leben schwer machen kann.
Aber eins ist mir nicht ganz klar:
Der Empfänger dagagen hat es einfacher, sein Schlüssel paßt ohnehin nur zur echten Nachricht, alles andere kann er vollautomatisch aussortieren.
Was meinst Du damit genau? 'Vollautomatisch' heisst doch immer noch: alles entschluesseln (oder zumindest einen Teil jedes Nachrichteblocks) und dann entscheiden, ob es die Nachricht ist oder 'Rauschen', oder? Oder geht das effizienter?
Das sollte effizienter gehen, wenn man typische Public-Key-Verfahren benutzt. In der Regel läuft das so ab:
Der Sender erzeugt einen relativ großen, zufälligen, symmetrischen Schlüssel. Symmetrisch heißt: Der selbe Schlüssel kann die Nachricht ver- und entschlüsseln. Der Schlüssel selbst ist aber meistens wesentlich kleiner als die Nachricht.
Mit dem symmetrischen Schlüssel wird die Nachricht verschlüsselt.
Dann wird der Schlüssel selbst mit dem Public Key des Empfängers asymmetrisch verschlüsselt (d.h. man kann nur mit dem zum Public Key gehörenden Private Key wieder entschlüsseln) und der verschlüsselten Nachricht hinzugefügt.
Der Empfänger entschlüsselt dann den symmetrischen Schlüssel mit seinem Private Key, und mit dem symmetrischen Schlüssel die verschlüsselte Nachricht.
Wenn der Private Key nicht paßt, sollte das sehr viel schneller auffallen als wenn man versucht, mit brutaler Gewalt den symmetischen Schlüssel zu raten oder aus der asymmetrisch verschlüsselten Form herauszurechnen (siehe auch weiter unten).
Warum so ein umständliches Verfahren mit "doppelter" Verschlüsselung?
Die ganze aktuelle Verschlüsselungstechnik basiert darauf, dass Angreifern nicht unbegrenzt viel Rechenleistung zur Verfügung steht. Man sucht Klassen von Funktionen, die relativ leicht konstruieren lassen (z.B. Multiplikation von zwei großen Primzahlen), deren Umkehrfunktionen aber um mehrere Größenordnungen mehr Aufwand erfordern (z.B. Primfaktoren richtig großer Zahlen ermitteln).
Alice und Bob, den beiden Muster-Usern bei Verschlüsselungsaufgaben, steht leider auch nicht unbegrenzt Rechenleistung zur Verfügung. Genauer gesagt haben sie sogar weniger Rechenleistung als der Bösewicht. Die asymmetrische Verschlüsselung macht leider ungleich mehr Mühe als symmetrische Verfahren. Der einzige Haken bei den symmetrischen Verfahren ist ja "nur", dass man "irgendwie" den geheimen Schlüssel von Alice zu Bob bringen muß, ohne dass jemand erfolgreich den Schlüssel abgreifen kann. Der ist aber, verglichen mit der Nachricht, recht klein, da ist der Aufwand der asymmetrischen Verschlüsselung längst nicht so problematisch wie bei einer asymmetrischen Verschlüsselung der gesamten Nachricht. Und anders als bei einer rein symmetrischen Verschlüsselung, bei der man den Schlüssel fast zwangsläufig mehrfach benutzen muß, wird hier für jede einzelne Nachricht ein neuer Schlüssel generiert, der nur ein einziges Mal benutzt wird.
Selbst wenn der Bösewicht also erfolgreich einen symmetrischen Schlüssel aus einer Nachricht rausgefummelt hat, nützt ihm der für die nächste Nachricht exakt gar nicht, weil für die automatisch ein völlig anderer symmetrischer Schlüssel genutzt wird.
Er muß den Private Key des Empfängers bekommen oder aus den Nachrichten herausrechnen. Letzteres ist extrem viel Aufwand, der nach gängiger Therorie daran scheitert, dass vorher das Universum den Wärmetod stirbt oder wenigstens unsere Sonne zu einem weißen Zwerg zusammengefallen ist. Daher greift man gelegentlich zu Rubber-hose Cryptanalysis, Einbruch, Spyware und anderen Techniken. Oder man verbietet den Einsatz von Verschlüsselung komplett oder beschränkt ihn auf relativ leicht knackbare Varianten. Oder man sorgt dafür, dass die Crypto-Software eine Hintertür hat, quasi einen Master-Key, der ALLE Nachrichten entschlüsseln kann, bzw. einen guten Tip, wie der zur Entschlüsselung benötigte Schlüssel aussehen muß.
Genau deswegen reiten übrigens die Crypto-Experten so darauf herum, dass sie alle Sources sehen und prüfen wollen und am liebsten selbst aus den Sources compilieren. Ein fertiges Binary könnte irgendein Bösewicht so verändert haben, dass es für eine leichtere Entschlüsselbarkeit sorgt.
Gegenmaßnahme: Testsuite für das fertige Binary, die Eingabe und Sollwert für die Ausgabe mit der echten Ausgabe vergleicht. Gegen-Gegenmaßnahme: Sonderfall-Regelung, die die Testsuite erkennt und in dem Fall die Backdoor-Funktionen lahmlegt.
Wenn man das weiter treibt, muß man das gesamte Betriebssystem, Libraries und Compiler im Source sehen und prüfen können. Und natürlich auch die Firmware (BIOS) und den Bootloader.
Soweit sind wir schon.
Und auch die Hardware selbst, schließlich könnte man auch Backdoor-Funktionen in Silizium gießen.
Daran (Open Source Hardware) arbeitet man noch. Nicht zuletzt, weil nicht in jeder Garage eine Chip-Fabrik steht.
Irgendwo muß die Paranoia allerdings auch Grenzen haben. Ich möchte nicht vom antiken Microsoft-Code im MBR über Syslinux, Linux-Kernel, glibc/dietlibc/uclibc, Shell, gcc bis hin zur Krypto-Software jede einzelne Code-Zeile durchanalysieren müssen. Daher verlasse ich mich darauf, dass meine "Zulieferer" das schon erledigt haben.
Mit digitalen Signaturen könnte man zumindest einige Teile in der Kette als "überprüft und sauber" markieren, das geschieht auch schon teilweise.
MD5 ist dafür allerdings nicht geeignet, dafür war es auch nie gedacht. MD5 ist eine gute Sicherung gegen zufällig auftretende Bitfehler in der Übertragung, aber keine Signatur, die auf einen oder mehrere vertrauenswürdigen Menschen zurückführbar ist.
So, Schluß für dieses Posting, sonst nörgelt die Forumssoftware wieder rum, dass ich geschwätzig bin. Nur noch ein paar Stichworte: Digitale Signatur, Web of Trust, Plausible Deniability.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
[...]
Ich hab die Antwort mit Vergnuegen gelesen, aber meine Frage bezog sich eigentlich wirklich nur auf das, was in der Frage stand :-) Ich praezisire mal. Bitte sage mir, ob und wo ich falsch liege:
Szenario: Du schickst mir eine Million Datenpakete, eins davon ist die echte Nachricht, der Rest ist Muell, d.h. nicht mit meinem Public Key verschluesselt, und natuerlich darin auch nicht mit demselben symmetrischen Key, mit dem die echte Nachricht verschluesselt ist.
Damit der Zweck des Ganzen nicht verloren geht, darf das ganze Ding keine expliziten Informationen darueber preisgeben, wo die echte Nachricht steckt. D.h., ich muss jedes Datenpaket mit meinem private key (zumindest teilweise) entschluesseln, um den (vermeindlichen) symmetrischen Schluessel zu kriegen, dann die Nachricht dieses Paketes mit dem symmetrischen Schluessel (zumindest teilweise) entschluesseln, um entscheiden zu koennen, dass es nicht die echte Nachricht ist.
Das heisst, der Aufwand des Entschluesselns wird auch erheblich hoeher. Nicht notwendigerweise um den Faktor 1Mio, das haengt von der Laenge der Teilnachricht ab, die ich brauche, um das jeweils entscheiden zu koennen, ob ich Muell habe oder nicht, und vom Algorithmus, genauer davon, wie komplex das Entschluesseln von Teilen der Nachricht ist - die Einsparung muesste da im allgemeinen sehr viel schlechter als linear sein. Aber dennoch um einen erheblichen Faktor.
Wenn das bis hierhin stimmt, dann heisst das natuerlich nicht, dass das Prinzip nicht funktioniert - natuerlich ist der Mahraufwand gering gegenueber dem Mehraufwand des Angreifers fuer Brute-Force-Attacken. Aber es ist dennoch ein Aspekt. Und *ob* das stimmt, das war meine Frage :-)
Viele Gruesse,
der Bademeister-
Moin Moin!
[...]
Ich hab die Antwort mit Vergnuegen gelesen, aber meine Frage bezog sich eigentlich wirklich nur auf das, was in der Frage stand :-) Ich praezisire mal. Bitte sage mir, ob und wo ich falsch liege:
Szenario: Du schickst mir eine Million Datenpakete, eins davon ist die echte Nachricht, der Rest ist Muell, d.h. nicht mit meinem Public Key verschluesselt, und natuerlich darin auch nicht mit demselben symmetrischen Key, mit dem die echte Nachricht verschluesselt ist.
Damit der Zweck des Ganzen nicht verloren geht, darf das ganze Ding keine expliziten Informationen darueber preisgeben, wo die echte Nachricht steckt. D.h., ich muss jedes Datenpaket mit meinem private key (zumindest teilweise) entschluesseln, um den (vermeindlichen) symmetrischen Schluessel zu kriegen, dann die Nachricht dieses Paketes mit dem symmetrischen Schluessel (zumindest teilweise) entschluesseln, um entscheiden zu koennen, dass es nicht die echte Nachricht ist.
So ist die Theorie.
Ich denke aber (ohne es geprüft zu haben), dass die gängigen Implementationen nicht nur den nackten symmetrischen Schlüssel asymmetrisch verschlüsseln, sondern auch noch einige weitere Informationen. Zum Beispiel die Information, welcher der möglichen symmetrischen Algorithmen benutzt wurde.
Wenn Du mit dem falschen Private Key versuchst, dass wieder zu entschlüsseln, bekommst Du bestenfalls Müll, wo eigentlich eine Angabe zum Algorithmus stehen sollte.
Damit könnte nach dem Versuch, den symmetrischen Schlüssel zu entpacken, schon erkannt werden, dass der Schlüssel nicht paßt, und der ganze Vorgang abgebrochen werden.
Oder man erkennt bereits beim Entschlüsseln anhand der grundlegenden Mathematik, dass es für die Kombination aus Public Key und falschem Private Key keine Lösung geben kann; man also beim Crypto-Equivalent von x+1=x-1 landet.
Das heisst, der Aufwand des Entschluesselns wird auch erheblich hoeher. Nicht notwendigerweise um den Faktor 1Mio, das haengt von der Laenge der Teilnachricht ab, die ich brauche, um das jeweils entscheiden zu koennen, ob ich Muell habe oder nicht, und vom Algorithmus, genauer davon, wie komplex das Entschluesseln von Teilen der Nachricht ist - die Einsparung muesste da im allgemeinen sehr viel schlechter als linear sein. Aber dennoch um einen erheblichen Faktor.
Ich denke, die gängigen Crypto-Algorithmen sind so aufgebaut, dass sie relativ schnell bemerken, dass ein Schlüssel nicht paßt. Alles andere wäre für die Benutzer extrem unerfreulich. Wenn mir jemand z.B. eine verschlüsselte Mail mit 20 MByte Anhang schickt, will ich nicht erst anhand der zehntausend Seiten Binärdurchfall im Mail-Client erkennen, dass mein Schlüssel nicht paßt, sondern ich will "sofort" eine Meldung darüber haben.
Das klint natürlich erst einmal nach einem Angriffsvektor. Ich habe eine Box, in die werfe ich eine verschlüsselte Nachricht und einen geratenen Private Key rein und raus fällt nach relativ kurzer Bedenkzeit ein "paßt" oder "paßt nicht".
Der Haken ist die Anzahl der möglichen Private Keys. RSA beispielsweise benutzt 1024, 2048 oder 4096 Bits, d.h. es gibt 2^1024, 2^2048 oder 2^4096 mögliche Private Keys. Schafft man es, die Hälfte dieser Keys durch qualifiziertes Raten von vorne herein auszuschließen, muß man sich immer noch mit 2^1023, 2^2047, 2^4095 möglichen Keys herumschlagen. Um auf handhabbare Größen zu kommen, muß man 1000 bis über 4000 mal richtig gut qualifiziert raten.
RSA mit 1024 Bit gilt als "bald" geknackt. RSA mit 2048 und 4096 Bit gilt als auf absehbare Zeit sicher, so lange niemand RSA mit einem Quantencomputer auf die Pelle rückt, der dank der Quantenphysik alle Schlüssel gleichzeitig ausprobieren kann.
Wenn das bis hierhin stimmt, dann heisst das natuerlich nicht, dass das Prinzip nicht funktioniert - natuerlich ist der Mahraufwand gering gegenueber dem Mehraufwand des Angreifers fuer Brute-Force-Attacken. Aber es ist dennoch ein Aspekt. Und *ob* das stimmt, das war meine Frage :-)
Eine sehr berechtigte Frage. Ich habe so ein System noch nie aufgebaut oder auch nur geplant, weil es dazu noch nie die Notwendigkeit gab. Von daher habe ich keine endgültige Antwort.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
-
-
-
-
-
-
-
-
-
-
Moin Moin!
ist es möglich, per PHP einen String verschlüsselt auszugeben.
Cleintseitig soll dann per JavaScript und nach Eingabe des richtigen Verschlüsselungsschlüssels der von PHP ausgegebene String entschlüsselt werden.
Geht soetwas?
Am besten noch so, dass das Skript nicht eingebunden ist sondern per Browserplugin auf die Website angewendet wird ...
Bademeister hat Dir schon gesagt, dass der Ansatz nicht gut ist.
Ergänzend:
1. Nicht jeder Browser implementiert Javascript, nicht jeder Browser hat Javascript freigeschaltet, und selbst wenn der Browser Javascript implementiert und freigeschaltet hat, ist noch lange nicht gesagt, dass Deiner Site das Javascript-Privileg auch eingeräumt wird.
2. Wie lang soll der eingegebene Schlüssel sein? Größenordnung Passwort, irgendwas um 8 bis 10 Zeichen? Das ist noch ansatzweise benutzbar, und mit relativ wenig Aufwand knackbar. Da der Schutz in Deinem Ansatz KOMPLETT beim Client liegt, und der Server davon nichts mitbekommt, hast Du keine Möglichkeit, massiv parallele Angriffe abzuwehren. Und weil Javascript selbst immer im Klartext vorliegt (Microsofts sogenannte Verschlüsselung ist geknackt!), kann jeder nicht komplett verblödete Bösewicht alle Schutzmaßnahmen dagegen ausbauen. Den Rest schmeißt man in irgendeine Cloud, Amazon Services, oder notfalls in ein Botnet. Das Prinzip dürfte spätestens seit SETI@home bekannt sein. Oder denkst Du an einen mehrere Kilobyte großen Schlüssel (One-time Pad)? Wer will den eintippen? Und wie willst Du den verteilen?
3. Plugin? Ich brauche ein obskures Plugin, um an Inhalte Deiner Website zu kommen? Wohl möglich auch noch ausschließlich als ActiveX? Warum sollte ich Dir Vollzugriff auf meinen Rechner einräumen wollen? Und selbst wenn ich wollte, würde mich eine kompetente EDV-Abteilung das nicht tun lassen.
Obligatorischer Link zum Thema selbstgemachte Verschlüsselung: Kann teuer werden!
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Und weil Javascript selbst immer im Klartext vorliegt (Microsofts sogenannte Verschlüsselung ist geknackt!), kann jeder nicht komplett verblödete Bösewicht alle Schutzmaßnahmen dagegen ausbauen.
Das ist ein schwaches Argument - die Sicherheit einer Verschlüsselung darf nicht dadurch beeinträchtigt werden, wenn der Algorithmus bekannt wird. Period.
Dabei spielt es dann auch keine Rolle ob das ganze am Client oder am Server läuft - den verschlüsselten Text habe ich und den kann ich dann versuchen zu entschlüsseln - dafür kann ich mir zur Not eine eigene Umgebung bauen.
Wenn hingegen die Sicherheit darauf beruht dass der Algorithmus geheim bleiben muss und jemand nur den Schlüssel bekommt, läuft am Sicherheitskonzept ohnehin schon einiges schief.
-
Moin Moin!
Und weil Javascript selbst immer im Klartext vorliegt (Microsofts sogenannte Verschlüsselung ist geknackt!), kann jeder nicht komplett verblödete Bösewicht alle Schutzmaßnahmen dagegen ausbauen.
Das ist ein schwaches Argument - die Sicherheit einer Verschlüsselung darf nicht dadurch beeinträchtigt werden, wenn der Algorithmus bekannt wird. Period.
Vollkommen richtig. Ich will ja auch nichts gegen den Entschlüsselungsalgorithmus unternehmen (wäre ja auch blöd ...). Mir ging es darum, dass sich Javascript in dieser Situation nicht dagegen wehren kann, massiv parallel mit Passwort-Kandidaten versorgt zu werden. Ein Server dagegen kann irgendwann (per Regel) entscheiden, dass ein Bösewicht versucht, das Passwort per Brute Force zu knacken, und stumpf die weitere Zusammenarbeit für eine Weile verweigern. (Beispiel)
Dabei spielt es dann auch keine Rolle ob das ganze am Client oder am Server läuft - den verschlüsselten Text habe ich und den kann ich dann versuchen zu entschlüsseln - dafür kann ich mir zur Not eine eigene Umgebung bauen.
Ja, und mit einer reinen Javascript-Lösung, die einen vom Server gelieferten, verschlüsselten String entschlüsseln soll, ist genau das das große Problem. Es ist extrem einfach, eine eigene Umgebung zu bauen -- weil genau das der Normalfall der Anwendung ist. Seite mit allen Resourcen speichern, in 10^n automatisierten Browser-(Simulator-)Instanzen öffnen, parallel verschiedene Passworte eingeben lassen, Ergebnis abgreifen.
Wenn hingegen die Sicherheit darauf beruht dass der Algorithmus geheim bleiben muss und jemand nur den Schlüssel bekommt, läuft am Sicherheitskonzept ohnehin schon einiges schief.
Richtig. Die Idee, ein eigenes Plugin für die Entschlüsselung zu verteilen, damit der Algorithmus nicht ganz so offensichtlich ist wie in nacktem Javascript, ist ein ganz deutliches Zeichen dafür.
Nicht, dass man Plugins nicht analysieren könnte, ganz im Gegenteil: Sie haben eine (mehr oder weniger) klar definierte Schnittstelle zum Browser, da kann man recht schmerzfrei ein "T-Stück" zwischenbasteln, dass sämtliche ausgetauschten Daten und Funktionsaufrufe mitschneidet. Oder man jagt das Plugin stumpf durch einen Disassembler wie IDA Pro. Oder beides.
Wirkluch hart geschützte Programme wie Skype sind schwieriger, aber auch nicht unmöglich zu zerlegen. Es macht eben nur deutlich mehr Mühe als ein 08/15-Compilat, das irgendwann mal aus einer Standard-Installation einer gängigen IDE herausgefallen ist.
(Gerade Skype macht zu viel Mühe. Mit dem Ergebnis, dass viele Admins Skype nicht trauen und es stumpf verbieten, oft unterstützt durch entsprechende Policies.)
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Ja, und mit einer reinen Javascript-Lösung, die einen vom Server gelieferten, verschlüsselten String entschlüsseln soll, ist genau das das große Problem. Es ist extrem einfach, eine eigene Umgebung zu bauen -- weil genau das der Normalfall der Anwendung ist. Seite mit allen Resourcen speichern, in 10^n automatisierten Browser-(Simulator-)Instanzen öffnen, parallel verschiedene Passworte eingeben lassen, Ergebnis abgreifen.
Mit eigener Umgebung bauen meinte ich eher eine Lösung die simpel zur entschlüsselung dient ungeachtet der verwendeten einbindung.
Wenn bekannt ist, dass RC4 verwendet wird, ist es unerheblich ob das in JavaScript passiert ist oder am Server in PHP geschrieben wurde - ich kann mir meine eigene Brute-Force-Umgebung bauen, meinetwegen in Perl oder Pyton und verschiedene Schlüssel gegen den verschlüsselten Text jagen. Dabei bin ich dann nichtmal durch irgendwelche Limits der ursprünglich verwendeten Sprache beschränkt.
(Gerade Skype macht zu viel Mühe. Mit dem Ergebnis, dass viele Admins Skype nicht trauen und es stumpf verbieten, oft unterstützt durch entsprechende Policies.)
Bei Skype und dem verwendeten Protokoll kommt ja noch dazu dass man nicht weiß was die da treiben - das ist auch bei anderen IM-Protokollen so. Oscar (ICQ) z.B. ändert alle paar Monate irgendwas am Protokoll, dann funktionieren ein paar Tage wieder sämtliche Drittanbieterclients nicht und dann ist gut.
-
-
-
-
Folgende Überlegungen stecken dahinter:
Dem Nutzer ist bekannt, dass JavaScript für die Nutzung des Dienstes notwendig ist.
SSL kann sich der Kunde nicht leisten.
Sicherheit soll erhöht werden.
Ein User muss sich zunächst einloggen. Hierfür bekommt er ein Formular mit 2 sichtbaren und 2 unsichtbaren Feldern:
sichtbar: (wie bei einem üblichen LogIn)
Name
Passwortunsichtbar:
zufälliger von JavaScript generierter String -> späterer Verschlüsselungs-Key
Hash des Passworts; wird von JavaScipt aktuell gehalten bei Eingabe des PasswortesZum Login wird per JavaScipt/AJAX der Name, der Verschlüsselungs-Key und der Hash des Passwortes an ein PHP-Skript geleitet.
Das PHP-Skript prüft wie üblich Name und Passworthash. Konnte sich der User erfolgreich einloggen wird der User serverseitig in einer Datenbank als eingeloggt vermerkt und der zeitlich begrenzt gültige Verschlüsselungs-Key gespeichert.
Per AJAX lassen sich nun vom Server die Daten nur mit diesem Verschlüsselungs-Key verschlüsselt nachladen. Das aufgerufene JavaSkript kennt jedoch diesen Key auch und kann die Daten Client-Seitig entschlüsseln.
-
Dem Nutzer ist bekannt, dass JavaScript für die Nutzung des Dienstes notwendig ist.
SSL kann sich der Kunde nicht leisten.
SSL/TSL kostet nichts, nur das Zertifikat sofern man ein signiertes möchte - und die sind für Wirtschaftsunternehmen wo es um Datensicherheit geht ein Butterbrot 200 Euro pro Jahr zahlt man idR. aus der Portokassa, da geht bei einem KMU mehr für Bleistifte und Kugelschreiber pro Jahr drauf.
Wenn es bei SSL um Sicherheit der Transaktion der Daten geht und nicht darum einen durch dritte abgesicherten vertrauenswürdigen sicheren Transfer zu gewährleisten kann man das SSL-Zertifikat auch selbst erstellen, wenn der Endkunde dem Anbieter vertraut, spricht nichts dagegen.
Sicherheit soll erhöht werden.
Dem Nutzer sollte bekannt sein, dass Sicherheit idR. Geld kostet - besonders das Know-How dahinter.
Deine weiteren Ausführungen klingen Blauäugig betrachtet sicher schlüssig, ansonsten aber eher potentiell gefährlich weil man an zu vielen Ecken und Enden an Sicherheit(slücken) denken muss.
Und der Programmieraufwand dafür? Mehrere Stunden, wenn nicht Tage - dafür kann man sich eine Menge SSL-Zertifikate kaufen.
-
Dem Nutzer ist bekannt, dass JavaScript für die Nutzung des Dienstes notwendig ist.
SSL kann sich der Kunde nicht leisten.
SSL/TSL kostet nichts, nur das Zertifikat sofern man ein signiertes möchte - und die sind für Wirtschaftsunternehmen wo es um Datensicherheit geht ein Butterbrot 200 Euro pro Jahr zahlt man idR. aus der Portokassa, da geht bei einem KMU mehr für Bleistifte und Kugelschreiber pro Jahr drauf.
Man benötigt einen HTTPS-fähigen Server, oder? Der kostet Geld.
Deine weiteren Ausführungen klingen Blauäugig betrachtet sicher schlüssig, ansonsten aber eher potentiell gefährlich weil man an zu vielen Ecken und Enden an Sicherheit(slücken) denken muss.
Und der Programmieraufwand dafür? Mehrere Stunden, wenn nicht Tage - dafür kann man sich eine Menge SSL-Zertifikate kaufen.
Vielleicht hat sich jemand diese Mühe schon einmal gemacht?
SSL/TLS per PHP und JavaScript nachzubilden; https-Ersatz?Welche Verschlüsselungsstandards kann ich mit PHP und JavaScript standardkonform verwenden?
-
Dem Nutzer ist bekannt, dass JavaScript für die Nutzung des Dienstes notwendig ist.
SSL kann sich der Kunde nicht leisten.
SSL/TSL kostet nichts, nur das Zertifikat sofern man ein signiertes möchte - und die sind für Wirtschaftsunternehmen wo es um Datensicherheit geht ein Butterbrot 200 Euro pro Jahr zahlt man idR. aus der Portokassa, da geht bei einem KMU mehr für Bleistifte und Kugelschreiber pro Jahr drauf.
Man benötigt einen HTTPS-fähigen Server, oder? Der kostet Geld.
Und ein "nicht HTTPS-fähiger Server" ist kostenlos oder wie?
Vielleicht hat sich jemand diese Mühe schon einmal gemacht?
Ja, Netscape mit SSL und jetzt die IETF mit TSL.
SSL/TLS per PHP und JavaScript nachzubilden; https-Ersatz?
Warum? Das ist völlig absurd, ich bezweifle dass das jemand schon ausserhalb eines Proof-of-Concept gemacht hat.
Welche Verschlüsselungsstandards kann ich mit PHP und JavaScript standardkonform verwenden?
Wenn du jetzt diese Frage zu stellen beginnst, ist ohnehin Hopfen und Malz verloren. Die Wahl des Algorithmus sollte Primär auf den Anforderungen der Sicherheitsstufe basieren nicht auf dem kleinsten gemeinsamen Nenner der verwendten Sprachen. Zudem was meinst du mit Standardkonform? Meinst du sowas wie "Konform zu ISO/IEC 27002"? Dann kannst du mit deiner Lösung sowieso baden gehen, wenn du nicht erstmal ein paartausend Euro investierst um dich Zertifizieren zu lassen.
-
Welche Verschlüsselungsstandards kann ich mit PHP und JavaScript standardkonform verwenden?
Wenn du jetzt diese Frage zu stellen beginnst, ist ohnehin Hopfen und Malz verloren. Die Wahl des Algorithmus sollte Primär auf den Anforderungen der Sicherheitsstufe basieren nicht auf dem kleinsten gemeinsamen Nenner der verwendten Sprachen. Zudem was meinst du mit Standardkonform? Meinst du sowas wie "Konform zu ISO/IEC 27002"? Dann kannst du mit deiner Lösung sowieso baden gehen, wenn du nicht erstmal ein paartausend Euro investierst um dich Zertifizieren zu lassen.
Mit standardkonform meine ich lediglich, dass der Verschlüsselungsalgorithmus wie spezifiziert umgesetzt sein soll.
Bei PHP kann ich z. B. mit mcrypt ganz konform auf AES zurückgreifen für JavaScript habe ich lediglich eine Umsetzung von AES gefunden, "die sich an der Spezifikation orientiert" - hier würden also PHP und JavaScript unterschiedlich arbeiten.Wenn man keinen https-fähigen Server hat, wie kann man dann die Verbindung >möglichst gut< zusätzlich zu einem Login sichern? Bringt mir http://php.net/manual/en/book.openssl.php etwas?
Meine Grundidee ist ja quasi, dass einmal Plaintext ein Schlüssel ausgetauscht werden muss, der dann für diese Sitzung zur Verschlüsselung auf dem Server und zur Entschlüsselung beim Client verwendet wird.-
Wenn man keinen https-fähigen Server hat, wie kann man dann die Verbindung >möglichst gut< zusätzlich zu einem Login sichern? Bringt mir http://php.net/manual/en/book.openssl.php etwas?
Sicher und es gibt auch ordentliche RSA- oder AES- Einbindungen für JavaScript - viel Spaß beim basteln.
Meine Grundidee ist ja quasi, dass einmal Plaintext ein Schlüssel ausgetauscht werden muss, der dann für diese Sitzung zur Verschlüsselung auf dem Server und zur Entschlüsselung beim Client verwendet wird.
Sagtest du bereits.
Ich verstehe aber immer noch nicht, warum du kein SSL/TSL bzw. HTTPS einsetzen kannst - so dämlich kann der Server garnicht sein dass er (wenns kein Apache ist) kein mod_ssl hat oder es sich nicht einfach nachinstallieren ließe.
-
Ich verstehe aber immer noch nicht, warum du kein SSL/TSL bzw. HTTPS einsetzen kannst - so dämlich kann der Server garnicht sein dass er (wenns kein Apache ist) kein mod_ssl hat oder es sich nicht einfach nachinstallieren ließe.
Das Hostingangebot kommt so wie ich das sehe ohne SSL-Unterstützung daher auch wenn nirgends explizit gesagt wird, dass es https unterstützt oder nicht.
Habe noch nie eine https-Verbindung aufbauen müssen und wüsste nicht, wie das bei diesem Hoster gehen soll, wenn es nirgends ein https-Document-Root gibt und ich auch nirgends Zertifikate o.ä. ablegen kann.-
Das Hostingangebot kommt so wie ich das sehe ohne SSL-Unterstützung daher auch wenn nirgends explizit gesagt wird, dass es https unterstützt oder nicht.
Wenn der Zertifikat vorhanden ist dauert das Einrichten unter Apache etwa 10 Minuten - wenn der Host dazu nicht in der Lage ist bzw. nicht kompetent dafür ist, ist das ein Grund mehr einen anderen zu suchen.
Dass HTTPS/SSL meistens nicht explizt erwähnt wird liegt schlichtweg daran, dass idR. auch keine Zertifikate gebraucht werden - ausser vielleicht man betreibt einen Shop.
Und alle anderen die Zertifikate benötigen - z.B. Banken, Versicherungen, Finanzämter usw gehen sicher nicht zu 1&1 und sagen "Hey, 1x Business-Webspace bitte. Aber dünn aufschneiden wenns geht!"
Habe noch nie eine https-Verbindung aufbauen müssen und wüsste nicht, wie das bei diesem Hoster gehen soll, wenn es nirgends ein https-Document-Root gibt und ich auch nirgends Zertifikate o.ä. ablegen kann.
Den Namen des Hosters verrätst du uns aber nicht?
Ein HTTPS-Document-Root gibt es nicht, das ist dasselbe nur dass man idR. über einen anderen Port daherkommt. Das Zertifikat wird auch nicht im Document-Root des Webs abgelegt sondern außerhalb. Bei Apache liegen die Zertifikate unterhalb von /etc/apache2/ssl/ oder sonstwo
Ein VirtualHost wird mit Port 443 (idR.) angelegt
SSL wird eingeschaltet und mit SSLCertificateKeyFile und SSLCertificateFile zeigt man auf die entsprechenden Files.
Die eigentliche Frontendseite darf nur noch mit https daherkommen (wenn nicht, per mod_rewrite (wenn HTTPS "off" beinhaltet oder nicht "on" ist).
Wenn du das kommerziell bei einem Host machen lässt kostet das ggf. ein paar Euro an Arbeit - wenn er es nicht gar Kostenlos macht - Zertifikate gibts bei GeoTrust ab etwa 150 und bei Verisign und Thawte ab 200 Dollar.
Aber ohne zu wissen was du eigentlich machen willst und welche Möglichkeiten du hast - die du sehr gekonnt verschweigst - ist eigentlich jedes Weiterreden oder besser Weiterraten total unsinnig.
-
-
-
-
-
Hi,
Vielleicht hat sich jemand diese Mühe schon einmal gemacht?
SSL/TLS per PHP und JavaScript nachzubilden; https-Ersatz?Nein, so blöd ist niemand.
SSL lautet die Lösung für das Problem, dass Mithörer nicht an die Daten kommen sollen.
Wer dafür zu geizig ist, der hat kein ernsthaftes Interesse an Sicherheit in diesem Punkt. Punkt.MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
-
-
-
Hi,
SSL kann sich der Kunde nicht leisten.
Sicherheit soll erhöht werden.
Fachkundige Beratung kann sich der Kunde also ganz offensichtlich auch nicht leisten, wenn so etwas dabei heraus kommt.
Ein User muss sich zunächst einloggen. Hierfür bekommt er ein Formular mit 2 sichtbaren und 2 unsichtbaren Feldern:
sichtbar: (wie bei einem üblichen LogIn)
Name
Passwortunsichtbar:
zufälliger von JavaScript generierter String -> späterer Verschlüsselungs-Key
Hash des Passworts; wird von JavaScipt aktuell gehalten bei Eingabe des PasswortesDass dieses „unsichtbar“ absolut total sichtbar ist, wenn der Benutzer sich nur die Mühe macht, nachzuschauen, ist dir hoffentlich bewusst.
Per AJAX lassen sich nun vom Server die Daten nur mit diesem Verschlüsselungs-Key verschlüsselt nachladen. Das aufgerufene JavaSkript kennt jedoch diesen Key auch und kann die Daten Client-Seitig entschlüsseln.
Und welche Stelle in der Datenübertragung glaubst du jetzt mit dieser „Verschlüsselung“ abgesichert zu haben, und wo gegen?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
SSL kann sich der Kunde nicht leisten.
Sicherheit soll erhöht werden.
Fachkundige Beratung kann sich der Kunde also ganz offensichtlich auch nicht leisten, wenn so etwas dabei heraus kommt.
Ja.
Ein User muss sich zunächst einloggen. Hierfür bekommt er ein Formular mit 2 sichtbaren und 2 unsichtbaren Feldern:
sichtbar: (wie bei einem üblichen LogIn)
Name
Passwortunsichtbar:
zufälliger von JavaScript generierter String -> späterer Verschlüsselungs-Key
Hash des Passworts; wird von JavaScipt aktuell gehalten bei Eingabe des PasswortesDass dieses „unsichtbar“ absolut total sichtbar ist, wenn der Benutzer sich nur die Mühe macht, nachzuschauen, ist dir hoffentlich bewusst.
Ja. Sollte aber keine Rolle spielen. Wenn er den Passwort-Hash oder den Verschlüsselungs-Key händisch ändert kann er nicht eingeloggt werden. Wenn dieser ausgelesen wird, dann habe ich den gleichen Angriffspunkt wie auch bei TLS, nämlich beim initialen Schlüsselaustausch.
Per AJAX lassen sich nun vom Server die Daten nur mit diesem Verschlüsselungs-Key verschlüsselt nachladen. Das aufgerufene JavaSkript kennt jedoch diesen Key auch und kann die Daten Client-Seitig entschlüsseln.
Und welche Stelle in der Datenübertragung glaubst du jetzt mit dieser „Verschlüsselung“ abgesichert zu haben, und wo gegen?
Nach dem Schlüsselaustausch kommen die Daten nur noch verschlüsselt vom Server und können nur noch von demjenigen, der eingeloggt ist überhaupt erst abgerufen werden und von diesem nur entschlüsselt werden, wenn er den Verschlüsselungskey kennt.
-
Hi,
Wenn dieser ausgelesen wird, dann habe ich den gleichen Angriffspunkt wie auch bei TLS, nämlich beim initialen Schlüsselaustausch.
Eben.
Nach dem Schlüsselaustausch kommen die Daten nur noch verschlüsselt vom Server und können nur noch von demjenigen, der eingeloggt ist überhaupt erst abgerufen werden und von diesem nur entschlüsselt werden, wenn er den Verschlüsselungskey kennt.
Oder von jedem anderen, der den Schlüsselaustausch mitgehört hat.
Noch mal die Frage: Gegen *was* genau willst du überhaupt absichern?
MfG ChrisB
--
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?-
Moin Moin!
Noch mal die Frage: Gegen *was* genau willst du überhaupt absichern?
Aus einiger Erfahrung im Umgang mit 5-Sekunden-Experten, die schon einmal irgendwo aufgeschnappt haben, dass es sowas wie Verschlüsselung, SSL, HTTPS gibt: Es ist sch...egal, ob die Verschlüsselung irgendetwas bewirkt, die Sicherheit des Gesamtsystems auch nur um Prozentbruchteile anhebt, Hauptsache "es ist verschlüsselt". Das gibt ein schönes warmes Gefühl im Bauch und so lange kein böser Mensch dieses Kartenaus anpustet, ist ja auch alles in Ordnung.
Technisch UND wirtschaftlich ist diese Frickelei mit JS natürlich völliger Unsinn.
Technisch scheitert es schon daran, dass sich der Server nicht sauber identifizieren kann (im Gegensatz zu HTTPS). Weitere Probleme wurden schon angesprochen.
Wirtschaftlich ist es völlig Unsinn, mehr Kosten für die Arbeitszeit zu investieren, das Rad komplett neu zu erfinden, als ein Hosting-Angebot mit HTTPS-fähigem Server und ein Zertifikat für die geplante Projektlaufzeit kostet. Sagen wir mal ganz großzügig 500 Euro für beides zusammen. Geteilt durch einen Stundensatz, bei dem man ohne Hartz IV auskommt, sagen wir mal 100 €, sind das 5 Stunden. In der Zeit baut und dokumentiert niemand ein auch nur ansatzweise ernstzunehmendes Verschlüsselungssystem.
HTTPS. Punkt. Ende. Wenn das Hosting-Paket das nicht kann, upgraden. Wenn der Hoster das nicht kann, Hoster wechseln.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
-
-
-
Schick dem Nutzer eine E-Mail mit einem "Private Key".
Du bietest eine "Private Key"-Setzen-Seite an, auf der in eine Textarea der "Private Key" aus der E-Mail eingegeben wird und dann per JavaScript ein Cookie gesetzt wird.
Der Server liefert nach einem erfolgreichen Login eines Nutzers die Daten immer mit dem entsprechenden "Public Key" verschlüsselt aus. Nur der Nutzer mit dem "Private Key", der in einem Cookie gespeichert ist, kann die Daten Clientseitig entschlüsseln.
Das ganze dann noch mit einem Schlüsselpaar für den Server.
Müsste doch gehen und eigentlich auch recht zuverlässig sicher sein. So sicher wie eben der "Private Key" im Cookie ist.
Auf welche PHP- und JavaScript-Funktionien Du dabei zurückgreifen kannst weiß ich leider nicht.
-
Popcorn!
Schick dem Nutzer eine E-Mail mit einem "Private Key".
Jetzt kommen wir schon zu asynchronen Verfahren wo ein Key an den Benutzer per Mail verschickt wird. Warum glaubst du wohl, darf man im elektronischen Zahlungsverkehr Kreditkartennummern nur über HTTPS übermitteln und auf keinen Fall auch nur in irgend einer Weise per Mail verschicken?
Der Server liefert nach einem erfolgreichen Login eines Nutzers die Daten immer mit dem entsprechenden "Public Key" verschlüsselt aus. Nur der Nutzer mit dem "Private Key", der in einem Cookie gespeichert ist, kann die Daten Clientseitig entschlüsseln.
Und jeder andere der den Key zuvor mitgeschnitten hat, das E-Mail findet oder einfach das Cookie klaut. Ein Cookie - gehts noch? Da wird der Key ja wild und unverschlüsselt bei jedem Request mitgeschickt - super Plan ;) Local Storage würde ich mir noch eingehen lassen, aber auch das wäre in anbetracht der Sicherheit absolutes Gehirnbluten.
Das ganze dann noch mit einem Schlüsselpaar für den Server.
Wozu braucht der Server ein Schlüsselpaar? Ein Schlüsselpaar ist für Client und Server (oder umgekehrt gedacht) wenn einer allein ein Paar hat bringt das nichts.
Müsste doch gehen und eigentlich auch recht zuverlässig sicher sein. So sicher wie eben der "Private Key" im Cookie ist.
Also garnicht, den jeder kann Cookies beliebig von der Platte lesen. Da die dort im Klartext vorliegen.
Auf welche PHP- und JavaScript-Funktionien Du dabei zurückgreifen kannst weiß ich leider nicht.
Hoffentlich auf gar keine - und wenn, würde ich auf ROT13 setzen - da kann man die Schuld danach auf den zu schwachen Algorithmus schieben ;)
-
Hallo,
und wenn, würde ich auf ROT13 setzen - da kann man die Schuld danach auf den zu schwachen Algorithmus schieben ;)
obwohl, doppelt angewendet ...?
*duck und weg*
Martin--
Ein guter Lehrer muss seinen Schülern beibringen können,
eine Frage so zu stellen, dass auch der Lehrer lernen muss,
um die Frage beantworten zu können.
(Hesiod, griech. Philosoph, um 700 v.Chr.)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
[latex]Mae govannen![/latex]
und wenn, würde ich auf ROT13 setzen - da kann man die Schuld danach auf den zu schwachen Algorithmus schieben ;)
obwohl, doppelt angewendet ...?
Reicht noch nicht. Ich verschlüssele immer vierfach (Quad-ROT13), dann ist's absolut sicher ;)
Cü,
Kai
--
~~~ ken SENT ME ~~~
Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
in Richtung "Mess up the Web".(suit)
SelfHTML-Forum-Stylesheet
-
-
Schick dem Nutzer eine E-Mail mit einem "Private Key".
Jetzt kommen wir schon zu asynchronen Verfahren wo ein Key an den Benutzer per Mail verschickt wird. Warum glaubst du wohl, darf man im elektronischen Zahlungsverkehr Kreditkartennummern nur über HTTPS übermitteln und auf keinen Fall auch nur in irgend einer Weise per Mail verschicken?
Warum glaubst Du ist auch für eine https-Verbindung ein anfänglicher Handshake nötig, bei dem jeder, der diesen mitliest, angegriffen werden kann?
Der Server liefert nach einem erfolgreichen Login eines Nutzers die Daten immer mit dem entsprechenden "Public Key" verschlüsselt aus. Nur der Nutzer mit dem "Private Key", der in einem Cookie gespeichert ist, kann die Daten Clientseitig entschlüsseln.
Und jeder andere der den Key zuvor mitgeschnitten hat, das E-Mail findet oder einfach das Cookie klaut. Ein Cookie - gehts noch? Da wird der Key ja wild und unverschlüsselt bei jedem Request mitgeschickt - super Plan ;) Local Storage würde ich mir noch eingehen lassen, aber auch das wäre in anbetracht der Sicherheit absolutes Gehirnbluten.
Wie bei https. Wer den Handshake als Man-In-The-Middle mitbekommt kann alles tun.
Wer schickt Cookies bei jedem Request mit?Das ganze dann noch mit einem Schlüsselpaar für den Server.
Wozu braucht der Server ein Schlüsselpaar? Ein Schlüsselpaar ist für Client und Server (oder umgekehrt gedacht) wenn einer allein ein Paar hat bringt das nichts.
Der Server hat einen eigenen Private Key und einen Public Key, mit dem der Client Daten an den Server verschlüsseln kann.
Und umgekehrt hat der Client einen eigenen Private Key und einen Public Key, mit dem der Server Daten an den Client verschlüsseln kann.Müsste doch gehen und eigentlich auch recht zuverlässig sicher sein. So sicher wie eben der "Private Key" im Cookie ist.
Also garnicht, den jeder kann Cookies beliebig von der Platte lesen. Da die dort im Klartext vorliegen.
Wer kann denn alles meine Cookies auslesen? Jeder der physischen Zugriff auf meinen PC hat. Aber nicht andere Webistes auf anderen Domains?
Der Handshake liegt auch im Klartext vor, bis dann die verschlüsselte Verbindung aufgebaut ist. Also warum darf ich über https Bankgeschäfte abwickeln?-
Warum glaubst Du ist auch für eine https-Verbindung ein anfänglicher Handshake nötig, bei dem jeder, der diesen mitliest, angegriffen werden kann?
Aber der läuft nicht per E-Mail über womöglich 5 öffentlich Mail-Relays wo jeder bequem den Key mitlesen kann.
Zudem ist der Schlüssel bei SSL/TSL nicht für alle Ewigkeit gegossen - da war sogar der Vorschlag des OP weniger Haarsträubend.
Wie bei https. Wer den Handshake als Man-In-The-Middle mitbekommt kann alles tun.
Genau aus dem Grund ist Online-Banking nur mit HTTPS allein und den Zugangsdaten auch nicht zulässig - dafür gibts dann noch weitere Sicherheitshürden wie etwa TAN (die optional sogar per SMS verschickt werden) die nur dem autorisierten Kunden vorliegen können. Wird eine TAN-Liste verschickt und nicht binnen einer wenigtätigen Frist vom Empfänger bestätigt wird sofort sämtlicher zugang zu den Transaktionen gesperrt.
Wer schickt Cookies bei jedem Request mit?
Der Browser bei einem Request.
Der Server hat einen eigenen Private Key und einen Public Key, mit dem der Client Daten an den Server verschlüsseln kann.
Und umgekehrt hat der Client einen eigenen Private Key und einen Public Key, mit dem der Server Daten an den Client verschlüsseln kann.
Wozu - der OP wollte nur Daten vom Server ZUM Client verschicken.
Zudem hat dann der Server kein Key-Paar sondern je eine Hälfte eines unterschiedlichen Paars, das ist etwas völlig anders.
Wer kann denn alles meine Cookies auslesen? Jeder der physischen Zugriff auf meinen PC hat. Aber nicht andere Webistes auf anderen Domains?
Von Firesheep hast du gehört? Damit kann bis auf weiteres jeder Vollidiot mithören.
Der Handshake liegt auch im Klartext vor, bis dann die verschlüsselte Verbindung aufgebaut ist. Also warum darf ich über https Bankgeschäfte abwickeln?
Siehe oben.
In Summe laufen deine Ausführungen jedenfalls darauf nach HTTPS nachzubauen - und das mehr schlecht als recht.
Natürlich lässt sich auch bei HTTPS nicht umgehen, dass 1x der Schlüssel übermittelt werden muss, aber zumindest haben sich über die Systematik einen Haufen Experten Jahrzehte lang die Köpfe zerbrochen.
Wenn es wirklich um sichere Kommunikation geht ist vermutlich VPN oder IP over Avian Carriers schlauer.
Aber was denn nun genau für Verschlussachen über das Internet gejagt werden sollen, verrät der OP nicht.
"Es geht um Kreditkartendaten" wäre z.B. ein klare Aussage und es gibt dafür von den Kreditkartenunternehmen auch klare Richtlinien - und wenn die selbstgebaute Lösung 10x besser ist als HTTPS, bei einer Sicherheitslücke hat man den Arsch sowas von offen, das würde ich nie im Leben riskieren.
-
Hi,
Wird eine TAN-Liste verschickt und nicht binnen einer wenigtätigen Frist vom Empfänger bestätigt wird sofort sämtlicher zugang zu den Transaktionen gesperrt.
das wäre schlecht - ich weiß ja nicht, wie zuverlässig die Postzustellung in AT ist. Hier in DE kann eine Briefsendung aber durchaus schon mal eine Woche unterwegs sein. Das ist natürlich nicht die Regel, aber auch keine Seltenheit.
Die Postbank macht das mit der Validierung daher intelligenter: Die neue TAN-Liste wird aktiviert, wenn ich im Onlinebanking-System einen 8stelligen Code eingebe, der auf der *alten* TAN-Liste steht. Das mach ich natürlich sinnvollerweise erst, wenn ich die neue Liste auch wirklich habe. Fängt jemand meine Post mit der neuen Liste ab, hilft ihm das also gar nichts, er braucht noch den Aktivierungscode von der bisherigen Liste.
Von Firesheep hast du gehört?
Bisher nicht. Scheint aber hochinteressant.
Aber was denn nun genau für Verschlussachen über das Internet gejagt werden sollen, verrät der OP nicht.
Nein. In den meisten Fällen steckt auch mehr Getue dahinter als die Sache wert wäre. Ich rege mich beispielsweise jedesmal über die Paranoia bei Online-Steuerangelegenheiten auf. Als ob da auch nur im Entferntesten etwas Geheimhaltungswürdiges übermittelt würde! Wenn sie den ganzen Zauber wenigstens nur optional machen würden, so dass die ganz Paranoiden mit ihren digitalen Signaturen und signierten Java-Applets rumspielen können, und die anderen über ein normal benutzbares HTML-Formular und HTTP(S) ihre Daten übermitteln können.
Ciao,
Martin--
Die letzten Worte des Privatdetektivs:
Jetzt wird es mir klar: SIE sind der Mörder!
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Wird eine TAN-Liste verschickt und nicht binnen einer wenigtätigen Frist vom Empfänger bestätigt wird sofort sämtlicher zugang zu den Transaktionen gesperrt.
das wäre schlecht - ich weiß ja nicht, wie zuverlässig die Postzustellung in AT ist. Hier in DE kann eine Briefsendung aber durchaus schon mal eine Woche unterwegs sein. Das ist natürlich nicht die Regel, aber auch keine Seltenheit.
Die Post ist bei uns mit Briefen extrem schnell - die brauchen im Schnitt 1 bis 2 Tage.
Der Haken: die Bonzen verbraten Geld und sperren reihenweise Postämter zu. Beispielsweise haben sie eine Unmenge Geld erhalten um sich auf die kommende Privatisierung und Liberalisierung des Versandmarktes vorzubereiten und das erste was sie machen ist eigene Aktien zurückkaufen, Postämter schließen und jährlich 1000 Mitarbeiter feuern.
Wie lange die Frist jetzt genau ist, weiß ich nicht - aber vermutlich wird sie wohl mehr sein als ein "paar Tage" ;) zudem ist die neue Liste meiner Bank erst gültig, wenn ich den Abschnitt unterschieben persönlich hingebracht habe UND der die letzte TAN auf der alten verbraucht ist.
Die Postbank macht das mit der Validierung daher intelligenter: Die neue TAN-Liste wird aktiviert, wenn ich im Onlinebanking-System einen 8stelligen Code eingebe, der auf der *alten* TAN-Liste steht. Das mach ich natürlich sinnvollerweise erst, wenn ich die neue Liste auch wirklich habe. Fängt jemand meine Post mit der neuen Liste ab, hilft ihm das also gar nichts, er braucht noch den Aktivierungscode von der bisherigen Liste.
Auch nicht blöd.
Nein. In den meisten Fällen steckt auch mehr Getue dahinter als die Sache wert wäre. Ich rege mich beispielsweise jedesmal über die Paranoia bei Online-Steuerangelegenheiten auf. Als ob da auch nur im Entferntesten etwas Geheimhaltungswürdiges übermittelt würde! Wenn sie den ganzen Zauber wenigstens nur optional machen würden, so dass die ganz Paranoiden mit ihren digitalen Signaturen und signierten Java-Applets rumspielen können, und die anderen über ein normal benutzbares HTML-Formular und HTTP(S) ihre Daten übermitteln können.
Das österreichische Finanzamt hat ein HTML-Formular und nutzt HTTPS - das deutsche Finanzamt scheint immer noch Zustände zu haben, wie sie bei uns hier vor 10 Jahre geherrscht haben ;)
-
Hallo,
Die Post ist bei uns mit Briefen extrem schnell - die brauchen im Schnitt 1 bis 2 Tage.
in den meisten Fällen ist ein Brief hier in DE auch am nächsten Werktag da. Aber es gibt halt ab und zu Fälle, wo's mal etwas länger dauert. Deswegen garantiert die Post auch nie einen Zustelltermin.
Der Haken: die Bonzen verbraten Geld und sperren reihenweise Postämter zu. Beispielsweise haben sie eine Unmenge Geld erhalten um sich auf die kommende Privatisierung und Liberalisierung des Versandmarktes vorzubereiten und das erste was sie machen ist eigene Aktien zurückkaufen, Postämter schließen und jährlich 1000 Mitarbeiter feuern.
Kommt mir irgendwie bekannt vor.
Ich rege mich beispielsweise jedesmal über die Paranoia bei Online-Steuerangelegenheiten auf. Als ob da auch nur im Entferntesten etwas Geheimhaltungswürdiges übermittelt würde! Wenn sie den ganzen Zauber wenigstens nur optional machen würden, so dass die ganz Paranoiden mit ihren digitalen Signaturen und signierten Java-Applets rumspielen können, und die anderen über ein normal benutzbares HTML-Formular und HTTP(S) ihre Daten übermitteln können.
Das österreichische Finanzamt hat ein HTML-Formular und nutzt HTTPSNa also, es geht doch. Warum können unsere das nicht? Wenn ich dran denke, wie viele Tage ich vor gut zwei Jahren verbraten habe, um Java zu installieren - und zwar so, dass unser deutsches Elster-Online-System diese Java-Umgebung auch als funktionstüchtig akzeptiert.
Windows fiel als Hostsystem also schon mal aus; ich wollte mir keinen Windows-Rechner mit der Installation von Sun Java kompromittieren (und die Microsoft-JVM erfüllte wohl die Voraussetzungen nicht). Auf Linux wollte ich gern Opera für den Zweck verwenden; Opera hat sich aber hartnäckig geweigert, ein installiertes JRE zur Kenntnis zu nehmen. Blieb also nur noch Firefox.das deutsche Finanzamt scheint immer noch Zustände zu haben, wie sie bei uns hier vor 10 Jahre geherrscht haben ;)
Und das wahrscheinlich nicht nur bei der EDV.
Ciao,
Martin--
Man sollte keinen Senf von sich geben, wenn man nicht auch das Würstchen dazu liefern kann.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
Auf Linux wollte ich gern Opera für den Zweck verwenden; Opera hat sich aber hartnäckig geweigert, ein installiertes JRE zur Kenntnis zu nehmen. Blieb also nur noch Firefox.
Bei meinem Online-Banking-Anbieter wird sogar Opera unterstützt ;)
-
Hallo,
Auf Linux wollte ich gern Opera für den Zweck verwenden; Opera hat sich aber hartnäckig geweigert, ein installiertes JRE zur Kenntnis zu nehmen. Blieb also nur noch Firefox.
Bei meinem Online-Banking-Anbieter wird sogar Opera unterstützt ;)was heißt "unterstützt"? Es sollte mit jedem HTTP-Client funktionieren, ganz gleich wie der aussieht und wie er heißt!
Aber ich hatte bei der Postbank vor einigen Jahren auch etwas zum Lachen: Nach deren eigener Info sollten IE ab Version 5, Firefox ab Version 1 und irgendeine Netscape-Version unterstützt werden. Opera nicht. Mit IE6 wurde ich aber immer abgewiesen, ich würde einen nicht unterstützten Browser verwenden. Als ich dann auf Opera 8-irgendwas umgestiegen bin (der sich als IE6 ausgab), war alles in Butter!
Ciao,
Martin--
Lache, und die Welt wird mit dir lachen.
Schnarche, und du schläfst allein.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(-
was heißt "unterstützt"? Es sollte mit jedem HTTP-Client funktionieren, ganz gleich wie der aussieht und wie er heißt!
Traumwelt :)
Aber ich finde es beeindruckend, dass sie nicht "optimiert für Internet Explorer und Firefox" hinschreiben :D
-
-
-
Hello,
Die Post ist bei uns mit Briefen extrem schnell - die brauchen im Schnitt 1 bis 2 Tage.
in den meisten Fällen ist ein Brief hier in DE auch am nächsten Werktag da. Aber es gibt halt ab und zu Fälle, wo's mal etwas länger dauert. Deswegen garantiert die Post auch nie einen Zustelltermin.
Da hat dann wohl der Mitleserplatz etws viel zu tun gehabt?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
Hi.
Warum glaubst Du ist auch für eine https-Verbindung ein anfänglicher Handshake nötig, bei dem jeder, der diesen mitliest, angegriffen werden kann?
Darf ich mal fragen: fuer wie scheisse haeltst Du https (bzw. SSL/TLS) eigentlich? :-)
Beim Handshake wird kein Schluessel im Klartext uebertragen (und das hast Du auch nicht ernsthaft gedacht, oder?), sondern nur Daten, mit denen beide unabhaengig voneinander, zusammen mit jeweils geheimen Daten, einen gemeinsamen Schluessel berechnen koennen. Wenn Du den Handshake abhoerst, weisst Du vom Schluessel erstmal gar nichts. Und da anzugreifen ist ungleich schwieriger als eine Email auszulesen, in der der Schluessel drinsteht.
Viele Gruesse,
der Bademeister-
Darf ich mal fragen: fuer wie scheisse haeltst Du https (bzw. SSL/TLS) eigentlich? :-)
Beim Handshake wird kein Schluessel im Klartext uebertragen (und das hast Du auch nicht ernsthaft gedacht, oder?), sondern nur Daten, mit denen beide unabhaengig voneinander, zusammen mit jeweils geheimen Daten, einen gemeinsamen Schluessel berechnen koennen.
Und genau da kann man sich dazwischenhängen und einen MITM-Angriff fahren ...
... Und da anzugreifen ist ungleich schwieriger als eine Email auszulesen, in der der Schluessel drinsteht.
... und das ist wie du sagst ungleich schwieriger. Um nicht zu sagen fast unmöglich.
Auf dem 25C3 (vor 2 Jahren) wurde so ein Angriff durchgeführt - dabei wurde ein gefälschtes Zertifikat erstellt, das war aufgrund einer Kollision in MD5 möglich. Aber allein das Finden der Kollision hat schon ein paar Tage gedauert.
Bei den EV-Zertifikaten die man heutzutage für Online-Banking oder vergleichbares verwendet, kommt aber MD5 nicht mehr zu Einsatz - und auch diese Zertifikate gibts mittlerweile schon für unter 250 Euro pro Jahr.
-
-
-
-