digest auth mit django?

Django, Flask, Bottle, WSGI, CGI…
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

jens hat geschrieben:@lunar: Da hast du natürlich recht. Das ganze ist aber auch eine Budget Frage. Denn ein echtes Zertifikat kostet i.d.R. Geld.
Ein selbstsigniertes oder von CACert-signiertes Zertifikat kostet kein Geld und wenn man damit Leben kann dass man keine CA hat, der man vertrauen kann (wobei hier wiederrum die frage aufkommt welcher CA man tatsächlich auch vertrauen will) dann ist das von der Sicherheit der Daten genauso gut wie ein kostenpflichtiges Zertifikat.
jens hat geschrieben:Ich dachte Digest-Auth wäre da evtl. eine Alternative. Aber ich bleib dann wohl lieber bei meinem JS-SHA-Login. Den habe ich auch gerade erst neu implementiert, denn nun nutzte ich jQuery und alles geht per Ajax. (ist noch nicht comittet) Wenn ich Zeit finde, dann werde ich daraus mal eine separate "Reuseable Dango App" machen.
Also ich würde selbstsigniertes HTTPS etwa unendlich oft einem selbstzusammengebastelten SHA-JS-Whatever-Login vorziehen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

@jens: Was ist denn Dein „JS-SHA-Login“? Das bedeutet doch nicht etwa, dass Du das Passwort per Javascript hasht und erst dann versendest?! Dann wäre Digest-Auth nämlich eine um Welten bessere Alternative (und HTTPS sowieso) …

Und es muss doch im Übrigen auch kein Zertifikat einer anerkannten CA sein. Verschlüsseln kann man auch mit einem selbst ausgestellten Zertifikat. Da die meisten Benutzer (mich eingeschlossen) Zertifikate eigentlich nie prüfen, ist der Sicherheitsverlust eines selbst ausgestellten Zertifikats gegenüber einem "echten" CA-Zertifikat eigentlich recht marginal …
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Mein "JS-SHA-Login" macht mehr als bloß einen Hash vom Password zu senden. Siehe: http://www.pylucid.org/permalink/42/sic ... ohne-https

Es ist schon ähnlich dem Digest Auth verfahren, aber:
1. es wird SHA1 statt MD5 verwendet
2. Auf dem Server wird nur ein Teil gespeichert mit dem man alleine nichts anfangen kann. (genau genommen wird ein Teil mittels XOR verschlüsselt)

Und Punkt 2 ist eigentlich das, was mich an Digest Auth am meisten stört.

Wie der JS-SHA-Login genau abläuft, steht hier: http://www.pylucid.org/permalink/34/js- ... seudo-code
Der eigentliche soucecode ist hier: http://trac.pylucid.net/browser/branche ... s/crypt.py

Bin für Kritik, wie man es noch besser manchen könnte, offen.


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? Fast niemand, wenn es nichts "kritisches" ist. Und meine Homepage sehe ich auch nicht als so "kritisch" an.

Aber wenn ich mich mal aus einem fremden Netz (z.B. an der Uni) einloggen möchte, ist es mit doch etwas unbehaglich, mein Passwort im Klartext zu verschicken. Zwar nutzte ich für jede Seite ein eigenes Passwort, aber dennoch...


EDIT: Ah, eine alternative wäre dann noch:
http://en.wikipedia.org/wiki/CRAM-MD5
http://en.wikipedia.org/wiki/HMAC

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
lunar

@jens: XOR ist keine Verschlüsselung :)

Wenn Du schon a priori davon ausgehst, dass die serverseitige Datenbank offen liegt, und man daraus HA1-Hashes auslesen kann, kann man über Sicherheit kaum sinnvoll diskutieren. Denn wenn der Angreifer tatsächlich so weit kommt, HA1-Hashes aus der Datenbank lesen zu können, dann ist das Auslesen des Hashes noch das geringste Problem. Schließlich kann der Angreifer dann unter Umgehung der Seite und deren Authentifizierungsmechanismen auch direkt die Datenbank manipulieren oder zumindest auslesen, und so noch weitaus größeren Schaden anrichten.

Insofern verstehe ich nicht, warum Du Dich daran, dass bei Digest-Auth eine verwertbare Vorstufe des Algorithmus serverseitig gespeichert werden muss, denn nüchtern betrachtet ist das eigentlich vollkommen egal, Dein Verfahren ist nicht sicherer oder unsicherer als Digest-Auth.

Beide Verfahren haben dieselben Probleme, und sind nur ein zusätzliches Hindernis, aber kein echter Schutz. Gegen einen Man-in-the-Middle-Angriff bieten beide Verfahren nicht den geringsten Schutz, sondern erhöhen der Aufwand nur ein kleines Stück.

Insofern ist HTTPS auch nicht das „beste“, sondern das einzig richtige und sichere.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Es muss nicht immer gleich ein Hacker auf der Maschine sein. z.B. kann man so keinen SQL Dump aus den Fingern geben, deswegen mag ich ehr ungern HA1 auf dem Server speichern... Und wenn das der einzige Mehrwert von JS-SHA-Login ist, dann ist das auch schon mal etwas, oder nicht?

Aber du hast natürlich recht, wenn ein Hacker auf der Maschine ist, ist eh alles verloren. Da hilft aber auch kein https ;)

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?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

jens hat geschrieben: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…
Zuletzt geändert von apollo13 am Donnerstag 11. März 2010, 14:02, insgesamt 1-mal geändert.
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

jens hat geschrieben: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…
Benutzeravatar
mkesper
User
Beiträge: 919
Registriert: Montag 20. November 2006, 15:48
Wohnort: formerly known as mkallas
Kontaktdaten:

apollo13 hat geschrieben: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.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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 ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

jens hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

jens hat geschrieben: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.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten