nicht angemeldet
Hi Christian,
Naja, sobald man sich ausloggt, ist der Session-Key ja nichts mehr wert. Das heißt: Wenn jemand nicht genau in dem Zeitraum, in dem Du eingeloggt bist, etwas macht, dann nützt ihm der Session-Key auch nichts.
Wobei wir wieder bei dem bereits von mir angesprochenen bzw. angedeuteten Punkt wären, dass die Lebenszeit der Session ausreichend kurz (z.B. max 30 Min) sein sollte und ein User bei Inaktivität frühzeitig (z.B. nach 10 Min) ausgeloggt wird - viele Leute nutzen nämlich den Logout nicht.
Ich persönlich stelle mich auf folgenden Standpunkt: Kann man die jetztige Situation irgendwie verbessern? Im Moment ist es nämlich bei Formular-Logins extrem trivial die Auth-Daten abzufangen, gerade in offenen WLANs oder ähnlichem. Und mit einigen Maßnahmen man könnte es einem Angreifer sehr (!) viel schwerer machen, Zugang zum System zu erhalten.
Ok, da stimme ich dir zu. Natürlich sollte man solch einfache Angriffsmöglichkeiten verhindern. Zu Beginn dieses Threads habe ich mir allerdings mehr Gedanken zu einem sicheren™ Verfahren gemacht, wie du selber bereits gesagt hast, kommt dafür nur SSL/TLS in Frage - trotzdem wäre es natürlich schön, wenn man auch bei unverschlüsseltem HTTP Transfer etwas Sicherheit bieten könnte, wobei ich nach wie vor bei der Bedingung bleibe, dass gerade ein Login auch ohne Javascript möglich sein *muss*. (Gerne mit entsprechendem Hinweis auf die damit verbundenen Risiken.)
Es ist auch denkbar, fremde Session-Cookies zu "injecten". Drei Beispiele (gibt vermutlich noch mehr): […]
Danke, dass du das noch mal so ausführlich notiert hast ;-) Ich werde mir es auf jeden Fall merken *g*
Allgemeines noch zu Challenge-Response (ich hatte auch im Chat eine interessante Diskussion deswegen): Challenge-Response hat den großen Nachteil, dass man sich mit den Informationen, die auf dem Server gespeichert sind, einloggen kann. Das heißt: Taucht die User-DB irgendwann einmal im Internet auf, so kann sich bei Challenge-Response jeder mit den dort vorhandene Informationen einloggen. Selbst wenn die Daten gehasht und gesaltet gespeichert werden: Der Client muss genau diesen Prozess bei sich mit dem gleichen Hash und Salt nachbauen, damit er das gleiche Ergebnis erzeugen kann, wie der Server. Daher ist es bei Challenge-Response im Prinzip relativ sinnlos, die Passwörter zu hashen / salten, weil der Zugang damit trotzdem möglich wird.
Genau, vielleicht ist das auch das Problem, was ich hier mit Challenge-Response habe. Man muss recht großen Aufwand betreiben und hat am Ende doch nicht alles so, wie man es am liebsten hätte.
Ich habe zwischenzeitlich auch mal noch etwas recherchiert und zwar mit folgendem Hintergedanken: Warum müssen wir uns komplizierte Verfahren ausdenken, wenn es doch bereits erprobte Algorithmen zur Verschlüsselung gibt? Warum verwenden wir nicht einfach eine asynchrone Verschlüsselung, wo der Server seinen Public-Key mit dem HTML-Dokument ausliefert?
Wir haben oben festgehalten, dass auch Challenge-Response gegen Man-In-The-Middle machtlos ist, weil der Javascript-Code zur Berechnung ausgetauscht werden kann. Insofern kann man es einer asynchronen Kryptographie nicht als Nachteil anhängen, dass ein Man-In-The-Middle den Public-Key im HTML-Code beim Übertragen manipulieren könnte.
Fehlen nur noch Libraries dafür in Javascript, ich habe mal gesucht und bin auf PGP / GnuPG / OpenPGP Message Encryption in JavaScript gestoßen. Getestet habe ich es auch, ich habe der Seite meinen Public-Key und eine Nachricht gegeben, den verschlüsselten Output der Seite konnte ich dann lokal mit meinem Private-Key wieder erfolgreich entschlüsseln. Funktioniert also alles bestens und die Laufzeit sollte bei einem 1024-Bit Key und einem kurzen zu verschlüsselnden Text wie ein Passwort auch schnell genug sein, um es on-the-fly zu erledigen.
Henryk hat mich im Chat allerdings auf ein Projekt namens SRP aufmerksam gemacht. Das dort vorgeschlagene Protokoll bewerkstelligt folgendes:
a) Das Passwort wandert nie im Klartext über die Leitung.
b) Der Server kennt nur ein gehashtes, gesaltetes Passwort, nicht das Klartextpasswort.
c) Der Client *muss* das Klartextpasswort kennen, um sich einloggen zu können.
d) Der Server kann das Klartextpasswort aus den ihm zur Verfügung stehenden Daten auch nach der Authentifizierung nicht rekonstruieren.
e) Der Client kann verifizieren, dass der Server einen korrekten Hash des Passworts kennt.
f) Sollte die User-DB des Servers veröffentlicht werden, kann ein Angreifer sich damit nicht einloggen (der Client muss). Er kann natürlich weiterhin Wörterbuchangriffe gegen die Hashes fahren. Allerdings kann er sich dem Client gegenüber als gültiger Server ausgeben (weil er ja jetzt den Hash kennt).
g) Man-in-the-middle funktioniert nicht.
h) Server- und Client handeln einen gemeinsamen Schlüssel aus, der nur ihnen bekannt ist.Ich werde damit in nächster Zeit mal etwas rumspielen, wollte es nur mal erwähnt haben, vielleicht interessiert's Dich auch.
Klingt sehr interessant, ich habe es mir ebenfalls mal angesehen… verstehe es aber noch nicht so ganz ;-) Ist weiterhin noch ein Login im Klartext möglich? (Für User ohne Javascript)
Was heißt Man-In-The-Middle funktioniert nicht? Es funktioniert genauso wie bei Challenge-Response, der Datentransfer kann abgehört werden, das Javascript kann gefälscht werden etc.
Im Prinzip sieht mir das so aus, als ob der Client hier entscheidet, ob die Authentifizierung erfolgreich war oder nicht, weil der Client hier den vom Server erhaltenen String mit einem selbst errechneten String vergleicht. Ist das wirklich so? In welchem Praxis-relevanten Beispiel wäre das denn schon akzeptabel?
Viele Grüße,
~ Dennis.