Und jetzt die Hammer-Frage: Warum zum Teufel willst du das machen? Einen MD5 Login kannst du auch um vieles einfacher haben...
EDIT (jens): Abgetrennt von suche pure Python crypt Algo...
Sinn oder Unsinn des PyLucids JS-MD5-Login...
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ach ja?blackbird hat geschrieben:Und jetzt die Hammer-Frage: Warum zum Teufel willst du das machen? Einen MD5 Login kannst du auch um vieles einfacher haben...
Hast du dir es schon mal genau angesehen, wie es überhaupt funktioniert?
http://pylucid.org/index.py/JSMD5Login/
Ich sollte dem JS-MD5Login mal einen anderen Namen verpassen, weil irgendwie verwechseln die Leute es immer. Es hat nichts mit dem einfachen "MD5 Digest authentication" zu tun!
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Sondern es ist viel komplizierter und trotzdem nicht sicherer?
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ich denke schon das es sicherer ist, als einfach ein Klartext Passwort durch die Gegend zu schicken... Es ist auch sicherer als ein MD5 hash, der auf dem Client erzeugt wurde durchs Internet zu schicken...birkenfeld hat geschrieben:Sondern es ist viel komplizierter und trotzdem nicht sicherer?
Im ersten Fall kann man direkt das Passwort erschnüffeln. Im zweiten Fall zwar nur den MD5 hash, aber damit kann man sich dann auch einloggen.
Beim JS-MD5-Login werden aber zwei MD5 hash Werte erzeugt. Dabei wird im zweiten ein salt vom Server einbezogen. Somit ändert er sich bei jeder Anfrage. Wenn man also diese beiden MD5 abfängt, kann man sich nur genau in diesem Moment einloggen, weil der salt dann stimmt.
Ein weiterer Angriffspunkt ist die Übernahme der Session: http://de.wikipedia.org/wiki/Session-Hijacking
Wie gesagt, https ist in jedem Fall sicherer. Aber eigentlich auch nur dann, wenn das Zertifikat ein offizielles ist. Das kosten so um die 100€ pro Jahr, wenn ein Shared-Webhoster es überhaupt anbietet.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wieso sollten "offizielle" Zertifikate sicherer sein? Der einzige Unterschied bei einem Zertifikat bei Verisign oder Thawte ist, dass es im Browser nicht angenickt werden muss. Technisch ist es nicht sicherer.jens hat geschrieben:Wie gesagt, https ist in jedem Fall sicherer. Aber eigentlich auch nur dann, wenn das Zertifikat ein offizielles ist. Das kosten so um die 100€ pro Jahr, wenn ein Shared-Webhoster es überhaupt anbietet.
Außerdem: Wer entscheidet was eine offizielle Zerftifizierungsstelle ist? Ich ernenn mich selbst zur offiziellen Stelle und biete dir ein von mir signiertes Zertifikat für 50€ an. Deal?
Sowas wie offizielle Zertifizierungsstellen gibt es einfach nicht. Genauso wie bei PGP, es gibt keinen Key der offiziell ist. Es gibt nur ein Web of Trust, bei dem einige Keys mehr vertrauen haben als andere. Zum Beispiel c't signierte Keys.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Wer sagt dir bei einem nicht offiziell Signierten Zertifikate, das es nicht ein gefälschtes ist?Leonidas hat geschrieben:Wieso sollten "offizielle" Zertifikate sicherer sein?
Ach gerade http://de.wikipedia.org/wiki/Challenge- ... ifizierung gelesen...
Im Grunde stellt mein JS-MD5-Login so eine "Challenge-Response Authentifizierung" dar.
Gut das die Diskussion mal wieder aufgetaucht ist, ich hab gleich mal die Seite http://pylucid.org/index.py/JSMD5Login/ ein wenig aufgefüllt
EDIT: Im übrigen gab es schon mal eine Diskussion um JS-MD5-Login: http://groups.google.de/group/de.comp.l ... 3d860c4bf9
Schon gell. Ich bin auch sehr stolz auf michXtraNine hat geschrieben:Sieht beeindruckend aus dein Code.
Geht mir ähnlichXtraNine hat geschrieben:Aber verstehen tue ich da nichts von
Von mir sind ja auch nur beiden öffentlichen Methoden (encrypt & decrypt) und der Testcode. Den Rest habe ich auch nicht verstanden; ehrlich gesagt hat er mich auch nicht besonders interessiert, Hauptsache, er tut seine Arbeit und verschlüsselt einzelne Blöcke zuverlässig
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Was ist ein offiziell signiertes Zertifikat?jens hat geschrieben:Wer sagt dir bei einem nicht offiziell Signierten Zertifikate, das es nicht ein gefälschtes ist?Leonidas hat geschrieben:Wieso sollten "offizielle" Zertifikate sicherer sein?
Hab' ich schon erwähnt, dass ich schon gefälschte Seiten mit Thawte-Zertifikat gesehen habe?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Eben, so ist es. Und wie Gerold schon in der Newsgroup die du verlinkt hast gesagt hat: Es ist besser etwas für die Sicherheit zu tun als garnichts!jens hat geschrieben:Eine Absolute Sicherheit gibt es wohl nicht und wird es wohl auch nie geben
Von daher jens, finde ich deine Idee auch Super!! Ehrlich Alle CMS, Forensoftwares, etc übermitteln alle logins in Klartext (z.B. das Login bei vbulletin )...
lg
- birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Nur haben wir das Problem, dass der "JS-MD5-Login" wie der Name schon sagt nur mit JS funktioniert, und das nicht überall vorhanden/aktiviert.
Gibt es ein Fallback?
Gibt es ein Fallback?
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Da hast du vollkommen recht. Einen Fallback war eigentlich in Planung, aber wurde bisher nicht implementiert, weil der Login so gut funktioniert. Es gab bisher nur einen der angeblich mit dem Opera Browser es nicht geschafft hat. Aber ich meine das hatte ich vor langer Zeit auch schon einmal mit erfolg getestet...
Ein Fallback wäre dann der normale Plain-Text Login...
Ein Fallback wäre dann der normale Plain-Text Login...
Aber Du könntest auch einen Zufallswert vom Server zum Client schicken der mit in den MD5 Hash einfliesst. So wird jedesmal ein anderer Hash übertragen und man kann mit einem "abgehörten" MD5 Hash nichts anfangen.jens hat geschrieben:Ich denke schon das es sicherer ist, als einfach ein Klartext Passwort durch die Gegend zu schicken... Es ist auch sicherer als ein MD5 hash, der auf dem Client erzeugt wurde durchs Internet zu schicken...birkenfeld hat geschrieben:Sondern es ist viel komplizierter und trotzdem nicht sicherer?
Im ersten Fall kann man direkt das Passwort erschnüffeln. Im zweiten Fall zwar nur den MD5 hash, aber damit kann man sich dann auch einloggen.
Jain. Ich habe 2. aus der Aufzählung weiter unten vorgeschlagen, und das wird nicht gemacht.
Ordnen wir mal nach Komplexität was von Client an Server geschickt wird:
1. Nur Passwort oder Hash
2. Hash von Server-Zufallszahl + Passwort-Hash
3. Dein Verfahren
Wenn birkenfeld und ich sagen, Dein Verfahren sei zu kompliziert, meinen wir nicht Du sollst auf 1. zurückgreifen.
Ordnen wir mal nach Komplexität was von Client an Server geschickt wird:
1. Nur Passwort oder Hash
2. Hash von Server-Zufallszahl + Passwort-Hash
3. Dein Verfahren
Wenn birkenfeld und ich sagen, Dein Verfahren sei zu kompliziert, meinen wir nicht Du sollst auf 1. zurückgreifen.
Wie soll den 2 funktionieren? 0o Du übermittelst den hash von den salt bzw. den salt und dann wird was zurückgeschickt? Das pwd+salt? md5(salt+pwd)?BlackJack hat geschrieben:[...]
Wenn birkenfeld und ich sagen, Dein Verfahren sei zu kompliziert, meinen wir nicht Du sollst auf 1. zurückgreifen.
lg
Du bekommst vom Server die `challenge`, vom Benutzer das `passwd` und schickst zurück: md5(challenge + md5(passwd)).
Das steht doch da unter 2. eigentlich genau so.
Wobei in `challenge` natürlich noch ein Teil von einem "salt" enthalten sein kann, sollte.
Das steht doch da unter 2. eigentlich genau so.
Wobei in `challenge` natürlich noch ein Teil von einem "salt" enthalten sein kann, sollte.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
So, ich hab mal mit DIA ein Diagramm gebaut:
Gut das diese Thread aufgetaucht ist... Beim bauen des Diagramms sind mir noch einige Sachen aufgefallen, die ich bei meiner momentanen Implementierung besser machen kann!
Ein Problem muß aber weiterhin umständlich gelöst werden. Wie kann ich den zurück geschickte MD5 überprüfen???
Also wenn der Client jetzt folgendes zurück schickt: md5(Server-Zufallszahl + Password)
Dann brauche ich auf dem Server das Passwort im Klartext, damit der Server die selbe MD5 bilden kann. Passwörter möchte ich aber nicht im Klartext auf den Server speichern
Deswegen ist mein Verfahren etwas anders! Und deswegen benötige ich auch ein crypt-Modul.
Mein Verfahren beruht darauf, das nicht das ganze Passwort mit der Zufallszahl zu einer MD5 zusammen gerechnet wird, sondern nur die Hälfte.
Die andere Hälfte wird dazu gebraucht die zurück geschickte MD5 zu überprüfen.
Gespeichert wird auf dem Server also folgendes:
1. md5(Klartext Passwort) wird aufgeteilt in zwei hälften:
2. eine hälfte wird verschlüsselt mit der anderen hälfte
3. die verschlüsselte Variante wird gespeichert, die andere MD5 gelöscht
Wenn nun ein Client einloggen möchte wird folgendes gemacht:
1. md5(Klartext Passwort) wird aufgeteilt in zwei Hälften:
2. eine Hälfte wird mit der Zufallszahl verknüpft: md5(Server-Zufallszahl + MD5-Hälfte)
3. zweite MD5-Hälfte wird so zum Server geschickt.
Der Server kann nun die MD5 so überprüfen:
1. Mit der einen zugeschickten Hälfte wird die verschlüsselte Hälfte aus der Datenbank entschlüsselt
2. Die entschlüsselten Hälfte wird mit der Zufallszahl verknüpft: md5(Server-Zufallszahl + MD5-Hälfte)
3. Vergleichen der gebildeten MD5 Summe
- Wie PyLucid einen neuen User anlegt: http://pylucid.org/index.py/CreateUserWorkflow/
Wie PyLucid einen Login überprüft: http://pylucid.org/index.py/CheckLoginWorkflow
Gut das diese Thread aufgetaucht ist... Beim bauen des Diagramms sind mir noch einige Sachen aufgefallen, die ich bei meiner momentanen Implementierung besser machen kann!
Ein Problem muß aber weiterhin umständlich gelöst werden. Wie kann ich den zurück geschickte MD5 überprüfen???
Also wenn der Client jetzt folgendes zurück schickt: md5(Server-Zufallszahl + Password)
Dann brauche ich auf dem Server das Passwort im Klartext, damit der Server die selbe MD5 bilden kann. Passwörter möchte ich aber nicht im Klartext auf den Server speichern
Deswegen ist mein Verfahren etwas anders! Und deswegen benötige ich auch ein crypt-Modul.
Mein Verfahren beruht darauf, das nicht das ganze Passwort mit der Zufallszahl zu einer MD5 zusammen gerechnet wird, sondern nur die Hälfte.
Die andere Hälfte wird dazu gebraucht die zurück geschickte MD5 zu überprüfen.
Gespeichert wird auf dem Server also folgendes:
1. md5(Klartext Passwort) wird aufgeteilt in zwei hälften:
2. eine hälfte wird verschlüsselt mit der anderen hälfte
3. die verschlüsselte Variante wird gespeichert, die andere MD5 gelöscht
Wenn nun ein Client einloggen möchte wird folgendes gemacht:
1. md5(Klartext Passwort) wird aufgeteilt in zwei Hälften:
2. eine Hälfte wird mit der Zufallszahl verknüpft: md5(Server-Zufallszahl + MD5-Hälfte)
3. zweite MD5-Hälfte wird so zum Server geschickt.
Der Server kann nun die MD5 so überprüfen:
1. Mit der einen zugeschickten Hälfte wird die verschlüsselte Hälfte aus der Datenbank entschlüsselt
2. Die entschlüsselten Hälfte wird mit der Zufallszahl verknüpft: md5(Server-Zufallszahl + MD5-Hälfte)
3. Vergleichen der gebildeten MD5 Summe
Okay, jetzt zum dritten mal:jens hat geschrieben:Ein Problem muß aber weiterhin umständlich gelöst werden. Wie kann ich den zurück geschickte MD5 überprüfen???
Also wenn der Client jetzt folgendes zurück schickt: md5(Server-Zufallszahl + Password)
Dann brauche ich auf dem Server das Passwort im Klartext, damit der Server die selbe MD5 bilden kann. Passwörter möchte ich aber nicht im Klartext auf den Server speichern
Der Client schickt md5(challenge + md5(passwd))
Und der Server kennt die von ihm generierte `challenge` und hat ``md5(passwd)`` (mit einem "salt" erstellt) in der Datenbank stehen.
Also vielleicht das mit dem "salt" noch ein wenig expliziter:
Login:
Vorbedingung: Server hat in DB `salt` und `hash(salt + password)`
1. Server schickt `challenge` und `salt` an Client
2. Client antwortet mit `hash(challenge + hash(salt + password))`
3. Server vergleicht mit `hash(challenge + hash(salt + password))`
Der farbige Teil steht schon fertig berechnet in der DB, ist also nicht das Klartextpasswort. Das Verfahren ist ziemlich verbreitet würde ich mal behaupten.
Ja außer das ``md5(salt + password)`` nicht schon in der DB ist und stattdessen (vbulletin) den ``salt`` einmal in der DB hat und ``md5(pwd)``. Die Verifizierung sieht so aus: ``$md5pwd = md5(md5($password).$userinfo->salt);``BlackJack hat geschrieben:[...]Das Verfahren ist ziemlich verbreitet würde ich mal behaupten.
lg