Muss dann nicht das Passwort irgendwo im Quelltext der Seite mitgeliefert werden, oder vom Client an den Server gesendet werden? Und was soll das dann überhaupt bringen?
Stell dir z.B. ein bookmarklet vor (ein js script als Bookmark), das die Inhalte aller nicht versteckten Formulare auf einer Seite mit dieser Methode verschlüsselt. Als Konterpart jetzt ein bookmarklet, das ein Formular zur Passwort Eingabe aufpoppt und nach Eingabe die Daten entschlüsselt. Theoretisch kann dann auf Seiten wie z.B. facebook nurnoch derjenige Nutzer mit dem richtigen Passwort die Daten lesen.
Ob das sinnvoll ist, oder nicht sei mal dahingestellt. Eine kreative Anwendung wäre es trotzdem :)
wooza schrieb:
--------------------------------------------------------------------------------
> Stell dir z.B. ein bookmarklet vor (ein js script als Bookmark), das die
> Inhalte aller nicht versteckten Formulare auf einer Seite mit dieser
> Methode verschlüsselt. Als Konterpart jetzt ein bookmarklet, das ein
> Formular zur Passwort Eingabe aufpoppt und nach Eingabe die Daten
> entschlüsselt. Theoretisch kann dann auf Seiten wie z.B. facebook nurnoch
> derjenige Nutzer mit dem richtigen Passwort die Daten lesen.
>
Wozu gibt es SSL? Damit entfällt der Käse mit der verschlüsselten Seite, da die eh nur verschlüsselt vom Server ankommt.
> Ob das sinnvoll ist, oder nicht sei mal dahingestellt. Eine kreative
> Anwendung wäre es trotzdem :)
Ja, kreativ ist das wirklich. Sinnvoll dagegen ist es nicht. Mir will partout kein sinnvoller Use Case für eine JS-Crypto-Bibliothek einfallen. Zumal hier nur symmetrisch verschlüsselt wird. Aber irgend ein BWLer wird es sicherlich als das Größte seit Erfindung von "geschnittenen Brot" verkaufen wollen. ;)
Das Problem ist nur, dass SSL Zertifikate Geld kosten, undzwar kontinuierlich. Da lohnt sich bei kleineren Projekten eventuell eine JavaScript lösung. Einziges Manko wie bereitsangesprochen, muss bei symmetrischer Verschlusselung das geheime Passwort im Quelltext vorliegen, wodurch es nicht mehr geheim wäre...
Es geht bei meiner Anwendung nicht um eine sichere Übertragung, sondern z.B. darum auf öffentlichen Seiten Inhalte bereitzustellen, die nicht alle sehen sollen.
Beispiel:
>wooza schrieb:
>192,19,116,91,7,167,154,247,170,195,143,186,76,247,137,25
Klick auf bookmarklet > Passworteingabe >Nachricht jetzt in Klartext
>wooza schrieb:
>irgendwas
Dennoch ist es sicherlich sinnvoller Daten, die so sensibel sind eine Verschlüsselung zu benötigen, auf einem anderen Weg zu übertragen.
Ich will aber nicht behaupten, dass sowas kein Mensch braucht...
Steht kein SSL zur Verfügung, kann man sich schon ein paar sinnvolle Anwendungen vorstellen, z.B. eine sichere Authentifizierung per Challenge-Response, so dass trotz fehlendem SSL keine Klartext-Übertragung eines Passworts stattfinden muss.
Auch wenn man Daten serverseitig nur verschlüsselt speichern möchte, kann es sinnvoll sein, schon lokal am Client zu verschlüsseln (man muss dem Serverbetreiber nicht vertrauen).
Man stelle sich eine Webapplikation zur Passwortverwaltung vor.
Oder gerade noch eingefallen:
Gears verschlüsselt Daten in seiner SQLite db nicht und in dem Fall bleibt wohl nur Javascript zum verschlüsseln übrig...
Eine (sehr) sinnvolle Anwendung:
verschlüsseltes Login
Das Passwort muss in diesem Fall nicht im Quellcode stehen, da es vom User eingetippt wird. Username und Passwort werden verschlüsselt zum Server übertragen (ohne SSL) und der Server "meldet" den User an und gibt 'ne Session zurück o.ä. Von da an, ist der User über eine automatisch generierte ID angemeldet ohne je eine SSL-Seite "betreten" zu haben.
Das wäre allerdings auch der einzige nützliche Fall, der mir eingefallen ist. Zum Ver-/Entschlüsseln von Content würde ich dann doch SSL vorziehen.
----------------------------------------------------
EinBildung ist auch Bildung...
aze schrieb:
--------------------------------------------------------------------------------
> Eine (sehr) sinnvolle Anwendung:
>
> verschlüsseltes Login
>
> Das Passwort muss in diesem Fall nicht im Quellcode stehen, da es vom User
> eingetippt wird. Username und Passwort werden verschlüsselt zum Server
> übertragen (ohne SSL) und der Server "meldet" den User an und gibt 'ne
> Session zurück
Ja ne, wie überprüft der Server dann das Passwort?
Ohne einen gemeinsamen Schlüssel geht das nicht.
Wenn das verschlüsselte Passwort nicht entschlüsselt wird, ist es selbst das Passwort und man hat nichts gewonnen.
wooza schrieb:
--------------------------------------------------------------------------------
> Stell dir z.B. ein bookmarklet vor (ein js script als Bookmark), das die
> Inhalte aller nicht versteckten Formulare auf einer Seite mit dieser
> Methode verschlüsselt. Als Konterpart jetzt ein bookmarklet, das ein
> Formular zur Passwort Eingabe aufpoppt und nach Eingabe die Daten
> entschlüsselt. Theoretisch kann dann auf Seiten wie z.B. facebook nurnoch
> derjenige Nutzer mit dem richtigen Passwort die Daten lesen.
>
> Ob das sinnvoll ist, oder nicht sei mal dahingestellt. Eine kreative
> Anwendung wäre es trotzdem :)
gibts schon. weiss nicht ob das plugin für ff schon fertig ist, aber die idee ist nicht neu.
Sinnfrei schrieb:
--------------------------------------------------------------------------------
> Muss dann nicht das Passwort irgendwo im Quelltext der Seite mitgeliefert
> werden, oder vom Client an den Server gesendet werden? Und was soll das
> dann überhaupt bringen?
An sich hast du recht. Ohne gemeinsamen Schlüssel ist das Unsinn.
Es gibt aber sichere Wege zum geheimen Schlüsselaustausch siehe z.B. Diffie-Hellman. Muss ja SSL auch machen.
Und alle asymmetrischen Verfahren sind auch nur beim Schlüsselaustausch wirklich asymmetrisch, die Verschlüsselung an sich ist der Leistung wegen symmetrisch.
Den Austausch muss man hier wohl halt selbst implementieren, wenn man so eine Verwendung vorhat.
Andererseits gibt es auch andere Verwendungsmöglichkeiten.
Ohne zu speziell zu werden: Alles wobei der Server den Schlüssel garnicht kennen SOLL, z.B. Kommunikation. Für Terroristen :P
Schlüsselwächter schrieb:
--------------------------------------------------------------------------------
> aze schrieb:
> ---------------------------------------------------------------------------
> -----
> > Eine (sehr) sinnvolle Anwendung:
> >
> > verschlüsseltes Login
> >
> > Das Passwort muss in diesem Fall nicht im Quellcode stehen, da es vom
> User
> > eingetippt wird. Username und Passwort werden verschlüsselt zum Server
> > übertragen (ohne SSL) und der Server "meldet" den User an und gibt 'ne
> > Session zurück
>
> Ja ne, wie überprüft der Server dann das Passwort?
> Ohne einen gemeinsamen Schlüssel geht das nicht.
> Wenn das verschlüsselte Passwort nicht entschlüsselt wird, ist es selbst
> das Passwort und man hat nichts gewonnen.
i.d.r. wird auch nicht das passwort übertragen, sondern nur ein hash davon. auf dem server liegt genau dieser hash auch vor. also nur noch die hashes vergleichen -> passwort bleibt geheim. da hashes einwegfunktionen sind -> kann das passwort nicht rekonstruiert werden. naja... kollisionen gibts immer...
Es ist ja nicht so, dass man nicht automatisch einen Schlüssel generieren könnte um diesen dann in der Session auf dem Server zu speichern....
----------------------------------------------------
EinBildung ist auch Bildung...
Paeniteo schrieb:
--------------------------------------------------------------------------------
> Anwendungen vorstellen, z.B. eine sichere Authentifizierung per
> Challenge-Response, so dass trotz fehlendem SSL keine Klartext-Übertragung
> eines Passworts stattfinden muss.
Nein, das funktioniert nicht. Ein Angreifer könnte on-the-fly den Javascriptquelltext manipulieren, so daß das Passwort im Klartext übertragen wird. JS Crypto hat nur Sinn wenn das Javascript fest im Client verankert ist.
Diffie-Hellman ohne vorher ausgehandeltes Geheimnis oder Trusted Third Party (was man im Fall von Zertifikaten hat) ist anfällig für Man-in-the-middle-Angriffen, das wär also kein Ersatz für SSL.
> Auch wenn man Daten serverseitig nur verschlüsselt speichern möchte, kann
> es sinnvoll sein, schon lokal am Client zu verschlüsseln (man muss dem
> Serverbetreiber nicht vertrauen).
Wenn du dem Serverbetreiber nicht vertraust, brauchst du asymmetrische Verschlüsselung. Die ist durchaus sinnvoll (Mozilla Weave).
Wenn man dem Serverbetreiber nicht traut, hilft die beste Verschlüsselung auch nix ;-)
----------------------------------------------------
EinBildung ist auch Bildung...
guest schrieb:
--------------------------------------------------------------------------------
> Schlüsselwächter schrieb:
> ---------------------------------------------------------------------------
> -----
> > aze schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Eine (sehr) sinnvolle Anwendung:
> > >
> > > verschlüsseltes Login
> > >
> > > Das Passwort muss in diesem Fall nicht im Quellcode stehen, da es vom
> > User
> > > eingetippt wird. Username und Passwort werden verschlüsselt zum Server
> > > übertragen (ohne SSL) und der Server "meldet" den User an und gibt 'ne
> > > Session zurück
> >
> > Ja ne, wie überprüft der Server dann das Passwort?
> > Ohne einen gemeinsamen Schlüssel geht das nicht.
> > Wenn das verschlüsselte Passwort nicht entschlüsselt wird, ist es selbst
> > das Passwort und man hat nichts gewonnen.
>
> i.d.r. wird auch nicht das passwort übertragen, sondern nur ein hash davon.
> auf dem server liegt genau dieser hash auch vor. also nur noch die hashes
> vergleichen -> passwort bleibt geheim. da hashes einwegfunktionen sind ->
> kann das passwort nicht rekonstruiert werden. naja... kollisionen gibts
> immer...
Nein, dem ist nicht so. Du sendest dein Passwort an den Server und DIESER generiert daraus einen Hash und ueberprueft ob er den Hash in der Datenbank findet.
Wenn du nur den Hash uebertragen wuerdest, dann waere der Hash das Passwort und du hast nix veraendert. Dass das eine einweg Funktion ist bringt dir da nicht viel, weil du das Passwort garnicht wissen brauchst.
Gruss,
kimnotyze
Also ich finde die Idee auch nicht so doof, gerade wenn man eingene daten irgendwo im Internet aufbewahren will und die Verbindung nicht sichern kann. In einigen Netzen (Internetcafes, hochschulen, firmen,...) sind SSL Verbindungen aus Sicherheitsgründen(z.B.Umgehen der Firewall) gesperrt.
gruß Gurke
kimnotyze schrieb:
--------------------------------------------------------------------------------
> Nein, dem ist nicht so. Du sendest dein Passwort an den Server und DIESER
> generiert daraus einen Hash und ueberprueft ob er den Hash in der Datenbank
> findet.
> Wenn du nur den Hash uebertragen wuerdest, dann waere der Hash das Passwort
> und du hast nix veraendert. Dass das eine einweg Funktion ist bringt dir da
> nicht viel, weil du das Passwort garnicht wissen brauchst.
>
> Gruss,
>
> kimnotyze
Wie wärs mit etwas Salz, Herr Kellner?
http://en.wikipedia.org/wiki/Salting_%28cryptography%29
Achso, das Salz gäbs überm Tellerrand.
Kommentare: 172 | letzter Beitrag 22:36 Uhr
Kommentare: 94 | letzter Beitrag 26.05. 19:45
Kommentare: 79 | letzter Beitrag 22:43 Uhr
Kommentare: 71 | letzter Beitrag 22:20 Uhr
Kommentare: 62 | letzter Beitrag 21:44 Uhr
E-Mail an news@golem.de
Lockheed Martin hat eine neue Version des Exoskeletts Hulc vorgestellt, das es einem Menschen ermöglicht, schwere Lasten zu heben und zu tragen. Der Hersteller will das System im Spätsommer testen und, wenn alles gutgeht, danach an US-Soldaten in Afghanistan ausliefern.
Immer wieder zeigt Google seine Project Glass genannten Datenbrillen, ohne aber bislang konkrete Ankündigungen zu machen. Neben zahlreichen Fotos, die mit der Brille gemacht wurden, stellte Google nun auch ein erstes Video, das mit der Brille aufgenommen wurde, ins Netz.
Symantec hat sich zu den Aussagen der Bundesregierung geäußert, nach denen Geheimdienste in der Lage seien, SSH oder PGP zu knacken oder zu umgehen. Mathematisch gesehen sei kein wirksamer Angriff bekannt.
Renesas ist nach Elpida der zweite schwer angeschlagene japanische Chiphersteller. Renesas, das Hitachi, Mitsubishi Electric und NEC gehört, macht Verlust und will seine größte Fabrik verkaufen.
RIM soll in den kommenden Tagen erneut einen massiven Stellenabbau ankündigen. "Ich habe herausgefunden, welche Teile ich in meinem Puzzle nicht mehr benötige", sagte Firmenchef Thorsten Heins.
Ein britisches Blog will erfahren haben, dass Facebook den norwegischen Browserhersteller Opera Software kaufen will. Beide Unternehmen wollen sich dazu nicht äußern.