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:
Der JavaScript-MD5-Login geht in die nächste Runde
Bei der neuen PyLucid Version, mit django werde ich allerdings von MD5 auf SHA-1 umstellen. Das gibt es ja auch in JavaScript implementiert, also warum nicht.
Den Login in die _install Sektion nutzt das SHA1.js schon jetzt. Funktioniert prima.
Hab mir überlegt, man kann noch ein weitaus einfacheres Verfahren nutzten um zu verhindern, das ein Login Passwort im Klartext übertragen wird:
1. Auf dem Server speichert man das Passwort als SHA-salt-hash. (So wie es django macht).
2. Beim Login schickt man den salt Wert zum Client.
3. Der User tippt das Passwort im Klartext ein.
4. Das JavaScript packt zum Passwort den salt vom Server und bildet daraus den SHA-1 Hash.
---stop---
Nun könnte man also den von JS gebildeten SHA-salt-hash Wert zum Server übertragen und dort vergleichen. Das ist die einfachste Variante.
Hat allerdings ein gravierenden Nachteile: Der übertragene SHA-salt-hash Wert ist immer der selbe!
Wenn ein Angreifer diesen Wert einmal abgefangen hat (unverschlüsseltes WLAN o.ä.) dann kann er sich immer wieder damit einloggen.
Ein weiterer Nachteil: Auf dem Server liegt zwar nicht das Passwort im Klartext, aber der SHA-salt-hash Wert, mit dem man sich einloggen kann.
---weiter---
Also machen wir oben weiter:
5. Der Server schickt nicht nur den salt Wert aus der DB zum Client, sondern eine zusätzliche Zufallszahl. Diese wird auf dem Server in den Session Daten hinterlegt, für den späteren abgleich.
5. Der vom JS gebildete SHA-salt-hash Wert des Klartext Passwortes wird nochmals mit der zusätzlichen Zufallszahl vom Server, zu einem neuen SHA-salt-hash Wert gewandelt.
6. Übertragen wird nur der zweite SHA hash Wert, vom Client zum Server.
7. Der Server bildet ebenfalls den zweiten SHA hash aus dem gespeicherten SHA-salt-hash und der zweiten Zufallszahl aus den Session Daten und vergleicht diese mit den geschickten Daten vom Client.
Hier haben wir also den Vorteil, das bei jedem Login ein neu gebildeter SHA hash Wert übertragen wird. Dieser ist nur einmalig gültig.
Gesteigert wird die Sicherheit, wenn man die Sessiondaten (mit der Zufallszahl) an die IP Adresse bindet.
Wenn jemand nur über ein Proxy rein kommt, der für jeden Request eine unterschiedliche IP Adresse benutzt, dann muß man in dem Falle ein fallback unterstützten, der die IP nicht abgleicht.
Ein Nachteil zu meinem alten Verfahren gibt es allerdings: Auf dem Server sind alle Informationen gespeichert, die für einen Login notwendig sind
Das hört sich erstmal nicht so schlimm an. Man muß allerdings dabei bedenken, das man mit Datenbank Dumps vorsichtiger umgehen sollte. Man kann nicht einfach jemanden den Dump geben.
Bei meiner vorherigen Variante steckte in der Datenbank nur die halbe Information, die für einen Login notwendig ist. Das hab ich durch Verschlüsselung erreicht.
In der aktuellen PyLucid Version ist aber auch das auth System von django aktiv. Das speichert die Passwörter eh als SHA-salt-hash... Mal sehen, vielleicht schalte ich dann den auth Kram von django aus.
...uff... viel Text geschrieben... liest überhaupt noch jemand mit???
Bei der neuen PyLucid Version, mit django werde ich allerdings von MD5 auf SHA-1 umstellen. Das gibt es ja auch in JavaScript implementiert, also warum nicht.
Den Login in die _install Sektion nutzt das SHA1.js schon jetzt. Funktioniert prima.
Hab mir überlegt, man kann noch ein weitaus einfacheres Verfahren nutzten um zu verhindern, das ein Login Passwort im Klartext übertragen wird:
1. Auf dem Server speichert man das Passwort als SHA-salt-hash. (So wie es django macht).
2. Beim Login schickt man den salt Wert zum Client.
3. Der User tippt das Passwort im Klartext ein.
4. Das JavaScript packt zum Passwort den salt vom Server und bildet daraus den SHA-1 Hash.
---stop---
Nun könnte man also den von JS gebildeten SHA-salt-hash Wert zum Server übertragen und dort vergleichen. Das ist die einfachste Variante.
Hat allerdings ein gravierenden Nachteile: Der übertragene SHA-salt-hash Wert ist immer der selbe!
Wenn ein Angreifer diesen Wert einmal abgefangen hat (unverschlüsseltes WLAN o.ä.) dann kann er sich immer wieder damit einloggen.
Ein weiterer Nachteil: Auf dem Server liegt zwar nicht das Passwort im Klartext, aber der SHA-salt-hash Wert, mit dem man sich einloggen kann.
---weiter---
Also machen wir oben weiter:
5. Der Server schickt nicht nur den salt Wert aus der DB zum Client, sondern eine zusätzliche Zufallszahl. Diese wird auf dem Server in den Session Daten hinterlegt, für den späteren abgleich.
5. Der vom JS gebildete SHA-salt-hash Wert des Klartext Passwortes wird nochmals mit der zusätzlichen Zufallszahl vom Server, zu einem neuen SHA-salt-hash Wert gewandelt.
6. Übertragen wird nur der zweite SHA hash Wert, vom Client zum Server.
7. Der Server bildet ebenfalls den zweiten SHA hash aus dem gespeicherten SHA-salt-hash und der zweiten Zufallszahl aus den Session Daten und vergleicht diese mit den geschickten Daten vom Client.
Hier haben wir also den Vorteil, das bei jedem Login ein neu gebildeter SHA hash Wert übertragen wird. Dieser ist nur einmalig gültig.
Gesteigert wird die Sicherheit, wenn man die Sessiondaten (mit der Zufallszahl) an die IP Adresse bindet.
Wenn jemand nur über ein Proxy rein kommt, der für jeden Request eine unterschiedliche IP Adresse benutzt, dann muß man in dem Falle ein fallback unterstützten, der die IP nicht abgleicht.
Ein Nachteil zu meinem alten Verfahren gibt es allerdings: Auf dem Server sind alle Informationen gespeichert, die für einen Login notwendig sind
Das hört sich erstmal nicht so schlimm an. Man muß allerdings dabei bedenken, das man mit Datenbank Dumps vorsichtiger umgehen sollte. Man kann nicht einfach jemanden den Dump geben.
Bei meiner vorherigen Variante steckte in der Datenbank nur die halbe Information, die für einen Login notwendig ist. Das hab ich durch Verschlüsselung erreicht.
In der aktuellen PyLucid Version ist aber auch das auth System von django aktiv. Das speichert die Passwörter eh als SHA-salt-hash... Mal sehen, vielleicht schalte ich dann den auth Kram von django aus.
...uff... viel Text geschrieben... liest überhaupt noch jemand mit???
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Gratulation, du hast so eben das Challenge Response Verfahren erfunden
http://de.wikipedia.org/wiki/Challenge- ... ifizierung
Typo3 verwendet ja auch sowas, ich halte es jedoch für nicht sehr sinnvoll. Wer sichere Logins braucht sollte SSL verwenden!
http://de.wikipedia.org/wiki/Challenge- ... ifizierung
Typo3 verwendet ja auch sowas, ich halte es jedoch für nicht sehr sinnvoll. Wer sichere Logins braucht sollte SSL verwenden!
FYI:
- RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication
- Implementierung in `paste.auth.digest` (sind weitere verfügbar?)
- RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication
- Implementierung in `paste.auth.digest` (sind weitere verfügbar?)
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
...uralt thread herrauskram...
Mein ursprünglicher "PyLucid JS-MD5-Login", der ja schon seid einiger Zeit SHA1 statt MD5 nutzt, geht in die nächste Runde: http://www.python-forum.de/viewtopic.php?f=9&t=36227
Mein ursprünglicher "PyLucid JS-MD5-Login", der ja schon seid einiger Zeit SHA1 statt MD5 nutzt, geht in die nächste Runde: http://www.python-forum.de/viewtopic.php?f=9&t=36227