digest auth mit django?

[apollo13]

Der eigentliche soucecode ist hier: http://trac.pylucid.net/browser/branche ... s/crypt.py

Ich nehme an, du hast es diversen Krypto Mailinglists zur Kontrolle vorgelegt? Wenn nicht; ein Grund mehr http digest zu verwenden. Denn wenn deine Lösung nicht von mehreren kompetenten Leuten kontrolliert wurde ist sie zumindest für mich genauso wertvoll wie ein Plaintext login…

[apollo13]

Ach, in der Vergangenheit hat es auch Man-in-the-Middle Angriffe auf https Verbindungen gegeben... Und da sind wir wieder bei den Zertifikat Problem. Ohne ein echtes, hat der Mann in der Mitte es einfacher, oder nicht?

Nein, sobald du das Zertifikat einmal akzeptiert/verifiziert hast ist es genauso sicher wie eines der bekannten Stellen, kritisch ist es wenn der Attacker dich beim ersten Zugriff erwischt; deshalb immer Fingerprint etc über eine verlässliche Quelle kontrollieren…

[mkesper]

deshalb immer Fingerprint etc über eine verlässliche Quelle kontrollieren…

Und weil das niemand macht (bzw. woher den Fingerprint nehmen, mit dem man vergleichen kann?), gibt es sowas wie http://www.cs.cmu.edu/~perspectives/firefox.html.

[lunar]

@jens: Du solltest den vollständigen Inhalt Deiner Datenbank nicht an Personen weitergeben, denen Du nicht vertraust Davon abgesehen: So schwer ist es ja nun nicht, sensible Daten daraus zu entfernen … der große Nachteil an Deinem Algorithmus ist dagegen, dass er nur mit Javascript funktioniert.

Ich glaube zudem nicht, dass der Angreifer bei selbst ausgestellten Zertifikaten leichtere Arbeit hat, denn wie gesagt: Wer prüft schon Zertifikate? Die meisten Benutzer (mich eingeschlossen) klicken die Warnungen doch einfach weg, wenn es nicht gerade um sehr private Daten wie das Online-Banking geht (und selbst da machen das viele).

Bei HTTPS aber hat der Benutzer zumindest eine Chance, den Angriff zu bemerken, wenn er den will. Schließlich kann man das Original-Zertifikat nicht nur über Aussteller, sondern auch über den Fingerabdruck identifizieren, und eine Änderung des Zertifikats führt zu einer sehr auffälligen Warnung im Browser.

Bei Digest-Auth oder Deinem Javascript-Login dagegen muss man schon HTTP-Header oder Seitenquelltext genau prüfen, um den Austausch durch den Man in the middle überhaupt zu bemerken.

[jens]

Ach, was mir da noch einfällt: https lohnt sich eigentlich auch nur dann, wenn man nach dem Einloggen auch bei https bleibt. Ansonsten hat man ein Problem mit Session Hijacking... oder irre ich mich da?

Das meine Variante nur mit JavaScript funktioniert, stört mich eigentlich weniger. Klappt eigentlich mit allen Browsern und für NoScript gibt es bei mir natürlich für meine eigenen Seiten eine Ausnahme

[Leonidas]

Wir müssen uns nicht darüber streiten, das https das beste wäre. Das ist mir auch klar. Aber wie viele Seiten setzten es ein, wenn es nicht gerade ein Shop ist? Diese Forum? Ubuntuusers?

Also Debianforum nutzt es und ich nutze das dann auch gerne. Ansonsten habe ich eh vor Damaskus vorzuschlagen beim Umstieg auf ne neuere Forensoftware mal zu gucken ob wir nicht irgendwie SSL auch hinbekommen könnten.

[lunar]

Ach, was mir da noch einfällt: https lohnt sich eigentlich auch nur dann, wenn man nach dem Einloggen auch bei https bleibt. Ansonsten hat man ein Problem mit Session Hijacking... oder irre ich mich da?

Session Hijacking ist wieder ein anderes Thema … aber ja, um die Sitzung zu schützen, muss der gesamte Verkehr verschlüsselt werden.

[jens]

btw. die neu Implementierung vom JS-SHA-Login ist nun auf http://www.pylucid.org

Wer Lust hat, kann es ja mal ausprobieren (Login link ist ganz unten auf der Seite)

Die Änderungen: http://trac.pylucid.net/changeset/2572