nicht angemeldet
Hi,
Das geht ja runter wie Öl... ;-)
Öl, Moment, das kenne ich. Nichts verraten! ...Ah, da ist es ja:
"Öl: Eines der wenigen zweibuchstabigen Wörter, die mit 'Ö' beginnen und auf 'l' enden."
Ja, genau :-)
Waren mein bisher hauptsächlich im SELFforum gesammeltes Wiissen bzgl. Sicherheit.
Es ist schön zu sehen, dass hier nicht nur Leute mitlesen, sondern auch von dem Gelesenen profitieren.
Aber mir fehlt noch ne ganze Menge, vor allem Sicherheitslöcher auf der Homepage selbst.
Klar - das nennt sich Erfahrung. Trotzdem, Du bist Dir der Bedeutung des Begriffes "Sicherheit" schon bewusst. Ich traue Dir zu, einen "sauberen" Mechanismus zu entwickeln.
Die Passwörter werden auf dem Server ja verschlüsselt gespeichert.
Nicht auf allen Systemen. Wie erwähnt liegen bei Windows ("due to excessive paranoia") die Passwörter im Klartext vor. Da der Client dies nicht erraten kann, hat er grundsätzlich nur die ungecryptete Version.
Auch aus einem anderen Grund ist dies notwendig: crypt() funktioniert mit einem zweibuchstabigem Salt, welches auch die ersten zwei Zeichen des Ergebnisses ergibt. Der Server müsste also praktisch seine Passwörter dem Client übertragen, damit dieser die richtige Verschlüsselung wählen kann.
und auch im Klartext übertragen, wenn man kein SSL benutzt?
Ja, genau das. Der Server cryptet "bei Bedarf"; bis dahin gibt es keine Extra-Verschlüsselung für diesen Mechanismus.
Du sagst ein Problem ist wenn die SessionID in den Log-Files irgendwelcher Proxies... stehen, korrekt? Aber die Session wird doch rel schnell wieder gelöscht, wenn nicht mehr benötigt, das müßte also sehr zeitnah passieren, oder?
Richtig. Allerdings ist eben nicht ausgeschlossen, dass jemand kurzfristig (Referrer-Logs sind dabei eigentlich gefährlicher, auch weil sie jeder User haben kann, nicht nur Admins - und was Browser bisweilen alles als Referrer ansehen... mein lieber Mann...) das Logfile "benutzt" und dann in die noch gültige Session gelangt. Hab ich selbst mehr als ein Mal geschafft, aus purem Zufall - in einem Fall bin ich dann sogar an das Passwort des Users gekommen.
Und wenn ich SSL verwende, wird dieses Risiko dann ausgeschaltet?
Nein. Sicherheit ist niemals erreichbar; Risiken sind nur minimierbar. Die SSL-Verschlüsselung wird durch einen Handshake ausgehandelt - auch dieser kann abgefangen werden.
Was steht dann in den Refers?
"Eine" URL; idealerweise die, von der aus die Ressource angefordert wurde - manchmal aber einfach irgend eine.
Der Proxy... muß aber doch irgendwie wissemn, wohin er weiterlieten soll,
Der Referrer hat mit Proxies nichts zu tun; abgesehen davon, dass einige dort reinschreiben, was sie wollen.
HTTP_USER_AGENT - sehr verscheiden - gut geeignet, oder?
Ja; aber theoretisch kann dieser von Proxies etc. requestindividuell verändert werden - mir ist der Fall zwar nicht bekannt, aber damit würdest Du eine Session unmöglich machen.
HTTP_ACCEPT - genau so, vielleicht etwas lang, oder?
Naja, vor allem wenig nutzbar. Es dürfte sich meist um ein von der Browser-Hauptversion abhängiges Set handeln, also wenig individuell.
REMOTE_ADDR - auch gut, aber was ist mit Proxys?
Eine IP-Adresse ist nicht eineindeutig einem User zuzuordnen; aber wenn während einer Internet-Session der Proxy des Users wechselt, dann hat dieser entweder seine Konfiguration geändert, oder benutzt einen Anonymizer. In beiden Fällen muss er meines Erachtens mit eingeschränkter Funktionalität rechnen, ist also "selbst schuld".
REMOTE_PORT Da weiß ich nicht, ob der immer gleich bleibt, wie ist das, wonach werden die Ports aufgeteilt?
Weiß ich ehrlich gesagt nicht.
Hat es Sinn, das noch mit MD5() zu verschlüsseln?
Nein. Diese Daten sind nicht geheim; vor allem werden sie eh im Klartext (bzw. SSL-verschlüsselt) übertragen, ohne dass Du es beeinflussen kannst.
Cheatah