Hi Thomas!
Du wirst also um eine Authentifizierung nicht herumkommen.
ist HTTP-Authentification keine Authentifizierung?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.
Echolon und NSA und Co. kannst Du damit allerdings nicht aussperren.
wieso nicht?Na, wenn die den ganzen Datenverkehr mitlesen, lesen sie auch Dein Schlüsselpaar (Liginname/Passwort) mit - oder?
OK, beim mitlesen ist das natürlich ganz was anderes, aber auch dafür müssen die den Verkehr erstmal über einen eigenen Server leiten, und vor allem speeziell den VErkehr der sie intzeressiert, stelle mir das nicht so eifnach vor, aber möglich ist es wohl. Wobei es dafür ja noch SSL gibt, was die Sichrheit deutlich erhöt. Aber 100%ige Sicherheit wird es wohl niemals geben wenn man einen Web-Service anbietet.
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? ;-)
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?
HTTP ist eben ein
verbindungsloses Protokoll und kann daher keine eindeutige Userkennung/-sperre leisten. Der Client kann also sooft er will (zur Not über verschiedene IPs) versuchen, eine Sessionnummer zu treffen.
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?
Die einzige Möglichkeit festzustellen, ob eine Sessionnummer erraten werden sollte, ist eben ein zusätzlicher PIN-Cookie (oder ein anderes zweites Credential).
Der Punkt ist das man dieses Spielchen unendlich weiter treiben könnte, auch die Pin könnte man erraten, dann am besten noch ein Cookie um das wieder sicherzustellen.... was ich sagen will ist das man die Sicherheit hierdurch nicht wirklich entscheidend verbessert. Die Schwachstellen liegen meist sicher woanders, z.B. username/password.
Viele Grüße
Andreas