Login-Script

[Thomas Schmieder]

ReHallo Andreas,

Ist der Pflegeaufwand über .hataccess nicht etwas groß?
IMHO ist die Pflege der Passwort-Datei nicht aufwendiger als eine Datenbank, dafür braucht man IMHO mehr Code, oder? Die Passwortdatei ist derart einfach, das man an die Daten zum bearbeiten mit einem einzeiler drankommt. Dein Argument kann ich nur verstehen wenn man die Datei "manuell" über ein bestimmtes(fertiges) DB-Frontend verwalten möchte.

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.

Nö, die Wahrscheinlichkeit ist durchaus berechenbar und im absolut endlichen Bereich. Ich muss auch zugeben, dass ich das hier mit dir nicht mehr diskutieren mag. Darüber gibt es schon genug Threads.
_Darüber_ doch noch nie, oder? ;-)

*ggggg* (breiter gings nicht)

Ich wollte nur sagen das Du somit die Sicherheit auf alle Fälle erhöhst, aber nur marginal. Wenn jemand in der Lage ist eine SessionID zu erraten wird die Pin dann erheblich schneller gehen. Die SessionID ist ja gerade so ausgelegt das man sich um das erraten - zumindest statistisch - keine Sorgen machen braucht. Wenn man als Pin einen zufälligen 1024-byte String verwendet, kann man die Wahrscheinlichkeit das es erraten wird vielleicht zusätzlich um 0,000000025 senken(gaaaaaanz grob geschätzt ;-)). Aber was bringt das wirklich?

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 habe mich letztens gefragt, ob diese Aussage(habe ich auch oft gemacht) überhaupt Sinn macht. Ist es nicht bei _jedem_ Protokoll dasselbe Problem? Der Unterschied ist nur, das man  so eine "Session" woanders auf Protokoll-Ebene implementiert hat, so SSH oder FTP. Bei HTTP eben nicht, aber wer sagt das so eine Lösung wie Du es vorgeschlagen hast, nicht besser ist als SSH & Co.? Die anderen verschlüsseln meist noch die komplette Verbindung, und verwenden darüberhinaus noch Schlüssel die sich ständig ändern und hin und her gereicht werden. Das ließe sich sicherlich auch mit HTTP abbilden, oder nicht? Oder wo ist der Entscheidene Unterschied z.B. zu SSH, außer das dies schon fertig implementiert ist?

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.

Na, nun hast Du mich ja doch wieder in eine Diskussion verstrickt. :-)

Grüße aus http://www.braunschweig.de

Tom