Sinn oder Unsinn des PyLucids JS-MD5-Login...

[jens]

Jo, gutes timing

Code: Alles auswählen

user_pref("capability.policy.default.Location.hostname.set", "noAccess");

Eingetragen und gut ist

[Y0Gi]

@N317V: Also vor ein paar Jahre würde ich dir voll zustimmen. Allerdings ist es IMHO mittlerweile so, das man JavaScript eigentlich immer eingeschaltet hat.

Das sehe ich anders. Ich persönlich habe mehr den Eindruck, dass JavaScript heutzutage durch den Einsatz aktueller Browser zwar weitreichender verfügbar ist, aber durch gestiegendes Sicherheitsbewusstsein seitens der Nutzer zunehmend aktiv unterbunden wird.

Beliebte Dienste wie del.icio.us, Flickr, Google Maps und dergleichen habe ich auch erlaubt, aber der Rest wird von NoScript unterdrückt - und das erweist sich erschreckend häufig als gute Idee.

Alle AJAX Seiten sind ohne JavaScript unbrauchbar.

Und genau deswegen verzichte ich als Entwickler auf AJAX oder biete alternative Wege an.

[Leonidas]

Alle AJAX Seiten sind ohne JavaScript unbrauchbar.

Und genau deswegen verzichte ich als Entwickler auf AJAX oder biete alternative Wege an.

Sehe ich auch so. Wenns doch wenigstens was bringen würde, dann ok. Aber einen sicheren Login kann man mit HTTPS bewerkstelligen, ohne JS, sogar noch besser, simpler und ohne dessen Probleme.

[jens]

Ich hab nun auch NoScript installiert, ist ja ein wirklich nettes Plugin

Ich sehe das Problem nicht. Man kann doch wohl seine eigenen CMS-Seite in die JS-Ausnahme-Liste aufnehmen und fertig.

Im Übrigen erhält man natürlich auf der PyLucid-Login-Seite einen fetten Hinweis, das JS benötigt wird.

@Leonidas: Du wiederholst dich.

[Leonidas]

Ich sehe das Problem nicht. Man kann doch wohl seine eigenen CMS-Seite in die JS-Ausnahme-Liste aufnehmen und fertig.

Es geht nicht darum, wie man das umgehen könnte sondern darum, dass du etwas implementierst, das mehr Probleme macht, als das es sie löst.

@Leonidas: Du wiederholst dich.

Und du siehst es immer noch nicht ein. Du hast ein Feature gebaut das nahezu niemand braucht (außer dir hat sowas niemand gebraucht), das zusätzliche Probleme verursacht und versuchst es nun zu rechtfertigen und stellst dich gegen die ganzen Gegenargumente taub.
Ist natürlich deine Sache, aber das man es nicht abschalten kann ist eine starke Einschränkung.

[N317V]

Ich sehe das Problem nicht. Man kann doch wohl seine eigenen CMS-Seite in die JS-Ausnahme-Liste aufnehmen und fertig.

Es geht nicht darum, wie man das umgehen könnte sondern darum, dass du etwas implementierst, das mehr Probleme macht, als das es sie löst.

Und das Schärfste ist, dass es ja noch nicht mal tatsächlich ein Problem löst und jens das auch weiß:

Um es nochmal klarzustellen. JS-MD5 Login bietet keine echte Sicherheit

Sorry, jens! Ich will eigentlich echt nicht auf Dir rumhacken.

[Y0Gi]

IMHO ist es nur eine Frage der Zeit, bis die Mehrheit der Administratoren (wenn sie es nicht schon tun) auf Firmencomputern der Mitarbeiter JavaScript verbieten - ohne Reaktivierungsmöglichkeit. Dann verplempern die Mitarbeiter auch keine Zeit mehr bei YouTube und Konsorten.

[sape]

Alle AJAX Seiten sind ohne JavaScript unbrauchbar.

Und genau deswegen verzichte ich als Entwickler auf AJAX oder biete alternative Wege an.

Die da wären? Ich kenne keine Alternative zu AJAX, aber muss dazu auch sagen das ich nicht soviel Ahnung mit Web habe. Welche gibt es die den gleichen Zweck wie AJAX erfüllen?

[...]

@Leonidas: Du wiederholst dich.

Und du siehst es immer noch nicht ein. Du hast ein Feature gebaut das nahezu niemand braucht (außer dir hat sowas niemand gebraucht), das zusätzliche Probleme verursacht und versuchst es nun zu rechtfertigen und stellst dich gegen die ganzen Gegenargumente taub.
Ist natürlich deine Sache, aber das man es nicht abschalten kann ist eine starke Einschränkung.

Ich denke Jens wird auch eine non variante anbieten. Aber wirklcih verstehen tue ich nicht was an seiner Methode falsch sein soll? Ist das Gegenargument wirklich nur JS?

BTW: Zu AJAX - Hm, wie besucht ihr den Foren die vBulletin nutzen?

[N317V]

Wie gesagt: ich hab immer noch nicht kapiert, welchen Zweck AJAX denn erfüllt? Wie schon erwähnt: wenn ne Seite bei mir nicht funktioniert, dann besuch ich sie einfach gar nicht. Ich scroll trotzdem ne Minute durch meine Bookmarks und sitz viel zu viel am Rechner.

[Y0Gi]

Alle AJAX Seiten sind ohne JavaScript unbrauchbar.

Und genau deswegen verzichte ich als Entwickler auf AJAX oder biete alternative Wege an.

Die da wären? Ich kenne keine Alternative zu AJAX, aber muss dazu auch sagen das ich nicht soviel Ahnung mit Web habe. Welche gibt es die den gleichen Zweck wie AJAX erfüllen?

AJAX bietet meiner Meinung nach einen Weg, das UI komfortabler zu gestalten. Das heißt aber nicht, dass es vorher nicht auch anders - und benutzbar - ging. Da ich kein Google Mail oder dergleichen baue, rechtfertigt nichts AJAX. Grafischer Schnickschnack war schon immer ein Tradeoff (vgl. z.B. Flash).

Ansonsten habe ich bisher auf AJAX verzichtet, damit ist die Bedingung `not ajax or alternative` bereits wahr und der zweite Teil muss nicht ausgewertet werden

BTW: Zu AJAX - Hm, wie besucht ihr den Foren die vBulletin nutzen?

Wenn ein Forenbetreiber wirklich so dumm ist, JavaScript erforderlich zu machen, dann kann er sein Forum schön alleine benutzen. Das sind nicht selten auch die Leute, die meinen, die Welt braucht ein neues redundantes Forum und dann hundert Bretter zu Hardware, Software, Betriebssystemen, Programmiersprachen, Spielen und diversen Spezialkategorien anlegen. In denen nie jemand postet.

[Leonidas]

Die da wären? Ich kenne keine Alternative zu AJAX, aber muss dazu auch sagen das ich nicht soviel Ahnung mit Web habe. Welche gibt es die den gleichen Zweck wie AJAX erfüllen?

JSON-RPC, aber gut, das ist eigentlich nur eine Art AJAJSON. Gegenfrage: wofür braucht man AJAX unbedingt? In der Regel wird AJX nur dazu eingesetzt irgendwelche kleinen Spielereien zu implementieren. Stattdessen kann man die Seite auch einfach neu laden.
AJAX ist manchmal praktisch, aber in der Regel nicht besonders notwendig.

BTW: Zu AJAX - Hm, wie besucht ihr den Foren die vBulletin nutzen?

Gar nicht? Nein, im Ernst: im Moment besuche ich keine Forum, die vBulletin einsetzen. Habe aber mal JS ausgemacht und ein solches Forum angesurft. Funktioniert doch!?

[sape]

Stattdessen kann man die Seite auch einfach neu laden.

Das stimmt allerdings.

Habe aber mal JS ausgemacht und ein solches Forum angesurft. Funktioniert doch!?

Ja in der Tat. Habe gerad noch mal in ne ref. nachgesehen. AJAX wird tatsächlich nur für direktpost und edit genutzt. - €: Lesen ist also drin.

[jens]

Zu AJAX. Also reines AJAX ist nicht mehr als:

Es bezeichnet ein Konzept der asynchronen Datenübertragung zwischen einem Server und dem Browser, welches es ermöglicht, innerhalb einer HTML-Seite eine HTTP-Anfrage durchzuführen, ohne die Seite komplett neu laden zu müssen.

Siehe: http://de.wikipedia.org/wiki/Ajax_%28Programmierung%29

Es beschleunigt einfach nur das Web.

JavaScript an sich, kann allerdings lokal beim Client einige nette Dinge machen. z.B. hier im Forum, wenn man jemanden Antwortet. Die Buttons im Editor werden mit JS realisiert. Wer hier JS aus hat, muß halt die BBCode-Tags per Hand schreiben.

[jens]

So, nun gibt es in der SVN Version auch einen unsecure-Non-JS-Login als Fallback: http://pylucid.net/trac/changeset/859

Man sieht beim normalen Login einen Link zu diesem, wenn JS aus ist.

[Y0Gi]

Es gibt 'unsecured' und 'insecure', aber 'unsecure' gibt es nicht

[jens]

Danke. Ich hab's verbessert.

[jens]

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

[veers]

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!

[Y0Gi]

FYI:
- RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication
- Implementierung in `paste.auth.digest` (sind weitere verfügbar?)

[jens]

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