Das deutsche Python-Forum

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...

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...

Ach ja?

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!

Sondern es ist viel komplizierter und trotzdem nicht sicherer?

birkenfeld hat geschrieben:Sondern es ist viel komplizierter und trotzdem nicht sicherer?

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...

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.

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.

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.

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.

Leonidas hat geschrieben:Wieso sollten "offizielle" Zertifikate sicherer sein?

Wer sagt dir bei einem nicht offiziell Signierten Zertifikate, das es nicht ein gefälschtes ist?

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

XtraNine hat geschrieben:Sieht beeindruckend aus dein Code.

Schon gell. Ich bin auch sehr stolz auf mich

XtraNine hat geschrieben:Aber verstehen tue ich da nichts von

Geht mir ähnlich
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

jens hat geschrieben:

Leonidas hat geschrieben:Wieso sollten "offizielle" Zertifikate sicherer sein?

Wer sagt dir bei einem nicht offiziell Signierten Zertifikate, das es nicht ein gefälschtes ist?

Was ist ein offiziell signiertes Zertifikat?

Hab' ich schon erwähnt, dass ich schon gefälschte Seiten mit Thawte-Zertifikat gesehen habe?

Eine Absolute Sicherheit gibt es wohl nicht und wird es wohl auch nie geben

jens hat geschrieben:Eine Absolute Sicherheit gibt es wohl nicht und wird es wohl auch nie geben

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!

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

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?

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...

jens hat geschrieben:

birkenfeld hat geschrieben:Sondern es ist viel komplizierter und trotzdem nicht sicherer?

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...

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.

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.

Aber genau das macht doch mein Verfahren jetzt schon!

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.

BlackJack hat geschrieben:[...]
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)?

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.

So, ich hab mal mit DIA ein Diagramm gebaut:

• Wie PyLucid einen neuen User anlegt: http://pylucid.org/index.py/CreateUserWorkflow/
  
  Wie PyLucid einen Login überprüft: http://pylucid.org/index.py/CheckLoginWorkflow

Ist mein erstes Diagramm mit DIA...


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

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

Okay, jetzt zum dritten mal:

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.

BlackJack hat geschrieben:[...]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);``

lg