Das deutsche Python-Forum

Ja, ob der Nutzer allerdings das benutzte Zertifikat einsehen kann steht auf einem anderen Blatt. Und ob er mit den zwei Schluesseln etwas anfangen kann auf dem naechsten. Auf den naechsten 2 Blaettern, ob der Nutzer sich den Problemen bewusst ist und ob es ihn interessiert.

An der Stelle sei evtl noch das Firefox Plugin Certificate Patrol empfohlen.

@Bodyslam Die Idee, Zertifikate in Javascript zu prüfen, ist – sehr höflich formuliert – Blödsinn.

@cofi Ich weiß nicht, was der Zweck dieses Addons sein soll… So wie ich das sehe, ist das eine etwas interaktivere Version von Certificate Pinning, um den Preis, dass der Nutzer Zertifikate betrachten und verstehen muss. Was in der Realität nicht funktioniert…

Zertifikate geben offensichtlich keine Aussage über ihre eigene Vertrauenswürdigkeit, wie also sollte der Nutzer die Vertrauenswürdigkeit eines Zertifikates nur anhand desselben beurteilen? Und selbst wenn, X.509 Zertifikate sind viel zu kompliziert als das irgendein Nutzer sie verstehen könnte…

Bodyslam hat geschrieben:Ok, also ist der Schaden dann obligatorisch beim Nutzer des Dienstes. Wie sieht es dann da mit einer Lösung aus? Könnte man nicht ganz banal (wenn man beim Zertifikat bleibt) dem User einfach Anzeigen welches Zertifikat die Seite nutzt? Da ich mich gerade mit JS einarbeite kann ich da leider nicht viel beisteuern, aber ist es nicht möglich per JS das Zertifikat, welches die Domain nutzt, mit dem zu vergleichen welches im Browser des Nutzers ankommt?

Nein. Wenn jemand am Zertifikat vorbei kommt und eine MITM Attacke erfolgreich ausführen kann hast du verloren.

Die ganze Diskussion an dieser Stelle ist sowieso irrelevant. HTTPS ist nicht perfekt, trotzdem musst du darauf vertrauen das HTTPS so funktioniert wie es soll, die Alternative ist das Web nicht zu benutzen.

Nur damit ich richtig verstanden werde, mir geht es letzenendes um die Implementierung eines "sicheren" Logins und um die Besprechung der Möglichkeiten. Das Problem dabei was ich habe, ist einfach die Sache, dass jeder eine andere Meinung hat, daher habe ich schwierigkeiten für mich zu entscheiden wie man es macht.

Du sendest ein Passwort an den Server, der Server prüft das Passwort und antwortet entsprechend. Mach es über HTTPS und es ist sicher.

DasIch hat geschrieben: ...
Nein. Wenn jemand am Zertifikat vorbei kommt und eine MITM Attacke erfolgreich ausführen kann hast du verloren.
...

Damit widersprichtst du dich aber mit dieser und deiner letzten Aussage, wenn es sicher ist über https Daten zu versenden, dann würde auch ein MITM Angriff nichts bringen, wenn man aber an HTTPS "vorbei" kommt, ist es nicht sicher, oder?

@Bodyslam: HTTPS ist sicher, wenn es mit _dir_ zustande kommt. Essentieller Teil des MITM-Angriffes ist es dem Nutzer mit einem Zertifikat vorzuspielen du zu sein.

@lunar: Zugegeben, der Nutzerkreis, der das Addon sinnvoll nutzen kann ist nicht besonders gross.

Der entscheidende Punkt ist aber ein Wechsel von Zertifikaten: Wenn das alte Zertifikat noch lange nicht ausgelaufen ist, das neue von einer anderen CA kommt, usw sind das IMO aber Indizien das etwas falsch laufen koennte.

Ohne das Addon bekommt man von einem Wechsel ja nicht einmal etwas mit.

Absolute Sicherheit gibt es nicht, deswegen ist "sicher" ein relativer Begriff. "sicher" kann etwas halt nur momentan sein, solange wir es nicht besser wissen und unsere angenommenen Vorraussetzungen bestand haben.

HTTPS ist sicher weil man davon ausgeht das User das Zertifikatsystem verstehen und nichts dummes anstellen. Die Realität sieht natürlich etwas anders aus und deswegen ist HTTPS nicht so ganz optimal.

XKCD erklärt das Problem recht eindrücklich.

Ok danke an alle. Ich werde mal mit dem Codesnippet vom Anfang arbeiten. Status: problem solved

Skandale der letzten Zeit haben gezeigt, dass es nicht sonderlich schwer ist, ein gültiges Zertifikat für beliebige Webseiten zu erzeugen. Staatliche stellen können das zu 100% sicher. Die Korrektheit eines Zertifikats zu prüfen, ist aber nicht schwer. Du läßt Dir vom Serverbetreiber per Post den Public-Key schicken und vergleichst ihn mit dem, der für die Verschlüsselung benutzt wird. Dann kannst Du sicher sein, dass Deine Daten nicht abgehört werden können. Ob der Server kompromittiert ist, ist damit aber nicht sicher.

@cofi Eben, Indizien. Keine Beweise. Um die Indizien richtig deuten zu können, benötigt man Kontext zum Zertifikatswechsel. Ein Wechsel des Zertifikats kann legitim sein, und kaum eine Firma posaunt Zertifikatswechsel in die Welt hinaus. Mitunter hat man also gar keine Chance, an den nötigen Kontext zu gelangen, als Experte nicht, als normaler Nutzer erst recht nicht.

Eine Lösung, die den Benutzer mit einbindet, ist ziemlich zwangsläufig eine ziemlich schlechte Lösung. Ich glaube nicht, dass ein einzelner Nutzer MITM gegen HTTPS wirklich unterbinden kann, selbst wenn er solche Addons verwendet. Zertifizierungspfade sind im Allgemeinen viel zu kompliziert, als dass man legitime von illegitimen unterscheiden könnte.

@Sirius3 Man kann Middleboxes für MITM-Angriffe gegen HTTPS kaufen. Im Prinzip ist daran auch nichts verwerfliches, denn es kann durchaus legitime Gründe geben, HTTPS-Verkehr zu überwachen, z.B. in einer Firma, die mit Industriespionage zu kämpfen hat.

@DasIch Nun ja, bezüglich X.509 wissen wir es besser. Wir wissen, dass X.509 diverse, inhärente Probleme hat (e.g. die unglaublich hohe Komplexität, die strikt vertikalen Trustbeziehungen, keine DNS Begrenzung, etc), und wir wissen zumindest in der Theorie, dass es bessere Systeme gibt, v.a. SPKI.

Mit dem Nutzer hat das wenig zu tun. Selbst unter der Annahme, dass jeder Nutzer versteht, was er tut, ist X.509 eine ziemlich schlechte PKI.

DasIch hat geschrieben:XKCD erklärt das Problem recht eindrücklich.

Und dann der hier noch: http://xkcd.com/936/
Ich freue mich immer über Meldungen, dass ein gewähltes Passwort nicht sicher wäre, da es kein Sonderzeichen enthalte.

Mal etwas ab vom Thema... alles was Internet, neue Medien und die ganze Sparte Technik anbelangt, werde wir als moderne Menschen zukünftig gezwungen sein mehr mit zu beschäftigen, wenn wir unsere Privatsphäre sichern wollen. Leider herrscht heutzutage (unabhängig vom Alter) ziemliches Desinteresse, was fast an narzistische Ignoranz gleicht, der Glaube alles sei gut und man müsse sich um nichts kümmern und "alles sei doch gar nicht so tragisch".

Um das Thema "Sicherheit" richtig zu bearbeiten, ist es nötig dass Serviceersteller und -nutzer sich mit dem Thema auseinandersetzen.

(Um nicht falsch verstanden zu werden: http://de.wikipedia.org/wiki/Narzissmus)

Oh ich hab hier ja was verpasst da ist man einmal nicht da

@ Blackjack Danke für die Hilfe...hast mir echt weiter geholfen...manchmal hat man auch tomaten auf den Augen.

@Ts

Ja ich bin ein kompletter neuling, hab keinen Plan und mach halt das was ich hin bekomme...leider nicht immer der schnellste einfachste und vor allem "schönste" Weg aber ich bemühe mich und ich erstelle auch irgendwie meine DB gerne selbst . Eigentlich bräuchte ich mal jemanden der sich meinen Code anschaut und komplett überarbeitet, mit einem Roten Marker anstreicht und sagt SO NICHT -> BESSER SO ...

Meine Gedanken zum Thema Sicherer Login: http://www.pylucid.org/permalink/42/sic ... ohne-https
Dabei gilt: Wenn man auf deinem Server https hat, kann und sollte man es mit dem JS-SHA1 Login kombinieren!

jens hat geschrieben:Meine Gedanken zum Thema Sicherer Login: http://www.pylucid.org/permalink/42/sic ... ohne-https
Dabei gilt: Wenn man auf deinem Server https hat, kann und sollte man es mit dem JS-SHA1 Login kombinieren!

In welchem Paper kann ich den genauen Algorithmus und eine Analyse nachlesen und wieviele und welche Kryptographen haben es schon analysiert?

Mal abgesehen davon dass es ziemlich egal ist wie sicher der Login selbst ist, zumindest für die allermeisten Angriffe.

jens hat geschrieben:Dabei gilt: Wenn man auf deinem Server https hat, kann und sollte man es mit dem JS-SHA1 Login kombinieren!

Und das bringt dann was? Wenn man HTTPS hat, was bringt einem JS-SHA1 dann noch? Außer Leute mit NoScript auszugrenzen?