Hallo Phil
Okay da sha1 40 Bit Hash und md5 einen 32 Bit Hash erzeugt ist es doch okay wenn ich das Passwort mit sha1(PW.Salt) kodiere.
Also, MD5 ist meiner Meinung nach sicher genug. Die berichtete Unsicherheit ist folgende: Gegeben sein eine MD5-Prüfsumme, z.B. 5d05d2f5b461d9c93a84067013959ec9 (erzeugt aus dem Text "Bodo Thiesen" oder anders ausgedrückt: Diese Prüfsumme ist die MD5-Prüfsumme über meinen Namen). MD5 gilt nun als geknackt, wenn Du weniger als 2^128 Versuche brauchst, einen anderen Text als "Bodo Thiesen" zu finden, der genau diese Prüfsumme ergibt. Das ist für das Login-System aber nicht relevant. Für das Login-System wäre relevant, ob Du die richtige Zahl aus 2^128 erraten kannst, um die Sitzung zu klauen. Klar, bei SHA1 ist die Wahrscheinlichkeit geringer (2^160) aber die Wahrscheinlichkeit ist bei 2^128 schon hinreichend gering, daß MD5 für diese Zwecke als ausreichend sicher betrachtet werden kann.
Ok, egal, Back to Topic.
Nach dem Senden von Benutzername + Passwort wird "Benutzername-MD5(Benutzername+Passwort+Magic)" in Form eines Session-Cookies an den Benutzer zurückgesendet.
Ich nehme an das "Magic" ein Salt sein soll. Und das ich einfach Eine Session starte mit der Sesseion Variable z.b. $_SESSION['geheim'] = Benutzername-MD5(Benutzername+Passwort+Magic)
Der Magic ist eine Zufalls-Zeichenkette, die entweder Global für alle Sitzungen gilt, oder Pro Benutzer für ewig festgeschrieben wird - oder eben bei jedem Login neu vergeben wird (dann konsequenterweise aber auch für jeden Benutzer getrennt bleibt).
Bei jedem Request wird geprüft, ob der Session-Cookie vorhanden ist. Wenn ja, wird der Benutzername isoliert, in der Datenbank das Passwort abgerufen und dann wieder "Benutzername-MD5(Benutzername+Passwort+Magic)" berechnet.
Jetzt versteh ich das ganze nicht mehr.
Also: Du willst wissen, ob der Benutzer, der Dich (Deinen Server) kontaktiert, tatsächlich der ist, der er zu sein vorgibt. Einmal beweist er Dir das beim Login (durch mehr oder weniger direkte Übertragung von Benutzername+Passwort), später macht er es, in dem er den Session-Cookie immer wieder übermittelt, der für die Dauer seiner Gültigkeit gleichwertig zu Benutzername und Passwort ist.
Denke bitte daran, daß HTTP ein statusloses Protokoll ist. Jeder Zugriff muß sich selbst erneut authentisieren.
Letztlich wirst Du einfach als ersten Aufruf eines jeden PHP-Skriptes, das vom Web aus erreichbar ist, ein 'include "login_check.php";' einbauen. Dieses Skript überprüft dann nur, ob der Benutzer eingeloggt ist, und gibt andernfalls eine Fehlermeldung aus und beendet sich. Ist der Benutzer eingeloggt, setzt es wohl noch ein paar Variablen, damit man z.B. direkt über $uid an die Benutzer-ID heran kommt, und nicht ständig nochmal in der Tabelle nachschauen muß.
Stimmt das mit dem vom Benutzer übergebenen Wert überein, ist er eingeloggt, sonst nicht. Ob man den Magic global für alle Benutzer konstant setzt, oder ob man diesen Wert pro Benutzer beim Login zufällig generiert, bleibt sich erstmal relativ gleich. Das Argument Plaintext-passwort-equivalent zählt auch nicht, da auch das Übertragen des Passwortes beim Login unverschlüsselt passiert.
??
Worauf genau beziehen sich Deine Fragezeichen?
1. Magic global: Wenn ja, ist es möglich, browserübergreifend eingeloggt zu bleiben. Wenn nein, wird man jedes mal, wenn man sich mit einem anderen Browser neu einloggt, beim anderen Browser, bei dem man bereits eingeloggt ist, ausgeloggt.
2. Plaintext-passwort-equivalent: Wenn Du Dich einloggst, wirst Du Benutztername+Passwort normalerweise im Klartext (oder engl. Plaintext) übertragen. Wenn der Server Dir nun einen Cookie zurückschickt, ist dieser genauso gut, wie die Kombination Benutztername+Passwort. Also ist der Cookie "Plaintext-passwort-equivalent". Weil es einem Angreifer reicht, den Cookie zu kennen, um in Deinem Namen auf den Dienst zuzugreifen, er muß nicht unbedingt Dein Passwort kennen.
Wenn du es jetzt noch ganz sauber machen möchtest, baust Du noch eine Codierungsstufe auf JavaScript-Basis ein:
Im Login-Formular kommt noch ein type=hidden, name=challeng, value=zufall rein, der submit-button bekommt noch ein onclick verpasst. Dort steht eine Funktion, die das Passwort zusammen mit dem Challenge md5summiert, und das Ergebnis dieser md5sum-Berechnung statt des Klartextpasswortes als Passwort übermittelt (zusammen mit dem Challenge, das Du natürlich vorher in der Datenbank gespeichert hattest). Auf diese Weise wird das Passwort nicht mehr im Klartext übertragen.
Auch das stößt ein wenig ans Ende meiner Vorstellungskraft.
Punkt 2 aus letztem Absatz: Nehmen wir an, mein Benutzername lautet bodo, und mein Passwort lautet 123. Wenn ich nun vom Server die Aufforderung erhalte MD5(Benutzername+Passwort+abc) zu generieren, wobei abc das vom Server generierte Magic ist, und ich (also das JavaScript meines Browsers) nun die Prüfsumme errechnet, dann wird das Passwort im Login-Vorgang überhaupt nicht an den Server übertragen. Ergo kann man es auch unterwegs nicht klauen. Wir hatten hier vor einiger Zeit mal eine Diskussion laufen, ich weiß nicht wer es war, aber einer sagte, daß häufig das Passwort eine wesentlich schützenswertere Information ist, als was durch das Passwort geschützt wird. Das ist nämlich genau dann der Fall, wenn Du Dein Passwort für 1000 Dienste verwendest. Dann schützt Du damit vielleicht diesen SELFHTLM-Forenaccount mit dem gleichen Passwort, wie Dein E-Mail-Account. Ich glaube, wir beide sind uns einig, daß in diesem Falle die Tatsache, daß Du hier im Forum authentisiert bist (daß ist die Durch Dein Passwort geschützte Information), nicht so wichtig ist, als die Geheimhaltung des Passwortes vor einem potentiellen Angreifer (weil man damit Zugriff auf Dein E-Mail Account erhält). Richtig? Deswegen mein Vorschlag mit dem JavaScript.
Ich denke, so funktioniert das, werde das demnächst mal selber zusammen programmieren.
Muss man dir das dann abkaufen, kriegt man es kostenlos, garnicht oder hilfst du mir jetzt hier weiter, was sehr sehr toll wäre =) .
Da jeder, der im Programmieren geübt ist, dieses ganze System in wenigen Tagen (an einem Tag?) selber auf die Beine stellen kann, glaube ich nicht, daß man damit ernsthaft Geld verdienen kann. Ich für meinen Teil beginnen das in den nächsten Tagen umzusetzen, wenn Du noch etwas warten kannst, dann schick mir mal eine E-Mail und ich benachrichtige Dich, sobald ich fertig bin, dann kannst Du Dir das mal anschauen und ggf selber verwenden.
Gruß, Bodo