nicht angemeldet
Hallo Thomas!
Wenn ich Bastian richtig verstanden habe, will er doch für jeden Benutzer einen eingenen Messenger-Bereich haben. Dann würde er ja auch für jeden Bentutzer eine eigene Passwortdatei benötigen. Dadurch ist der Pflegeaufwand höher, als mit einer DB.
Das wurde ja bereits widerlegt ;-)
_Darüber_ doch noch nie, oder? ;-)
*ggggg* (breiter gings nicht)
Auch diese These kann ich widerlegen, es geht definitiv breiter:
*gggggg*
Nein, da irrst Du. Ein "Einzelschlüssel" stellt in einem verbindungslosen Protokoll keine Zugangsbeschränkung dar. Durch Brute Force und einige Kenntnisse darüber, wie diese SessionIDs ausgewürfelt werden (das will ich hier nicht erläutern) sinkt die Sicherheit einer solchen Lösung erheblich.
Ich weiß nicht wie die gebildet werden, aber ich vermute das Daten wie microtime() und Apache ZuffallsID verwendet werden. Selbst wenn es sich so deutlich einschränken ließe ist es immer noch so gut wie unmöglich, denke mal dran wieviele Versuche zu pro Sekunde starten kannst, je nach Server vielleicht 200, meist erheblich weniger. Und wenn ich einen 2. Schlüssel habe, das kannich ja auch mit brute-force erraten, ist halt wie eie verlängerung der SessionID, ein Vorteil wäre evtl das Du bei erraten einer SessionID mit hoher Wahrscheinlichkeit dieses als Raten erkennst und reagieren kannst.
Nein, der Vorteil eines verbindungsorentierten Protokolls oder eines logisch verbindungsorientierten (zwei Schlüssel oder mehr) liegt darin, dass man erkennen kann, wenn ein Fehlversuch durchgeführt wurde und daruf reagieren kann. Man kann die Session stoppen und dem eigentlichen Besitzer noch eine Nachricht hinterlassen, dass seine Session angegriffen wurde. Das kann man mit einem "Einzelschlüssel" nicht.
Ich meinte es allgemein, warum kann man das mit HTTP nicht abbilden? Z.B. so wie DU es beschreiben hast?
Na, nun hast Du mich ja doch wieder in eine Diskussion verstrickt. :-)
Ich finde es nunmal wirklich interessant ;-)
Grüße
Andreas