nicht angemeldet
Wie sicher sind PHP-Sessions?
Hallo zusammen,
möchte gerne den Zutritt zu einer Web-Seite mit einer
PHP-Passwort-Abfrage schützen. Ist das PW korrekt wird
das verschlüsselte PW in einer session registriert, so
dass bei einem Seitenrefresh nicht wieder die Abfrage
kommt.
Aber: wie sicher ist das eigentlich? Habe im Forum leider
nichts wirklich Aussagekräftiges gefunden.
Danke für Eure Meinung
Gruss
Ferdinand
-
Hallo Ferdinand,
die Session-Ids für sich betrachtet sind sehr sicher, da sie lang genug sind, daß die Möglichkeit, eine gültige zu erraten, praktisch nicht gegeben ist (außer jemand hat *extrem* viel Rechenpower und Bandbreite zur Verfügung).
Sicherheitsprobleme ergeben sich eher an der "Peripherie", z.B.:- wenn Du kein SSL verwendest, werden beim Einloggen Username und Passwort im Klartext übertragen, genauso wie später die Session, das ist wohl das größte Sicherheitsrisiko, weil man die mit einem packet sniffer abfangen kann
- wenn Du die Session-Id an die Url anhängst, kann sie je nach Browser in den Referrer-Logs eines anderen Servers auftauchen, deshalb sollte man den Timeout für die Session kurz halten.
Ein solches "übernehmen" einer session (wo jemand nicht die sessionid errrät, sondern sie z.B. über die Logdateien oder packet sniffing herausgefunden hat) ganz unmöglich zu machen, erfordert dann doch ein bißchen mehr Aufwand.
Nicht umsonst sagt das PHP-Manual:
"Sessions are not reliable as a secure authentication mechanism. "
Das ist ein wenig hart ausgedrückt, in 99,9% der Fälle reichen Sessions völlig aus, aber eben nicht, weil sie wasserdicht sind, sondern weil der Aufwand, den Schutz zu umgehen, in keinem Verhältnis zum erwarteten Gewinn (z.B. Posten in einem Forum unter einem anderen Namen) stehen, und verhältnismäßig wenige die technischen Fähigkeiten haben, das zu machen.
Falls Du Informationen schützen willst, die wirklich "etwas wert" sind (Kreditkartennummern, Firmeninterna, Anderkonten usw.), dann soltest Du zusätzliche Sicherungsmaßnahmen verwenden (und auf jeden Fall SSL, hilft ja auch nichts, wenn zwar die Authentifizierung wasserdicht ist, aber die abgefragten Informationen weiter unverschlüsselt übertragen werden)Viele Grüße
Stephan-
Hallo Stephan,
ist es nicht so, dass die "Sicherheit" der Session-IDs umgekehrt proportional zur Anzahl der "gleichzeitigen" Benutzer auf dem System ist?
Wenn nur ein Benutzer arbeitet, dann wird es wohl tatsächlich schwer sein, die eine gültige Session-ID aus dem Vorrat zur erraten. Was ist aber, wenn es schon 3000 Benutzer sind, die Sessions unterhalten?
Ok, ok, das werden nicht alles Hacker sein. Reicht ja aber, wenn _einer_ darunter ist, der mit einem Programm Session-Roulette spielt.
Ich würde in den Seiten zusätzliche Sicherheiten verstecken, die zusammen mit der Session-ID für Identifikation sorgen und vor allem öfter mal wechseln.
Man könnte ja auch serverseitig den Traffic mit einer IP für eine Weile ablehnen, wenn von dort z.B. mehr als 5 Fehlversuche innerhalb einer Zeitspanne von 10 Minuten gekommen sind. Wie würdest Du denn sowas implementieren? IP und Timestamp in eine Error-Tabelle und einfach ein Query, wieviel Datensätze in den letzten 10 Min. dort aufgelaufen sind?
Die ganzen ID-Verfahren (Passworte gehören auch dazu) haben doch nur Sinn, wenn man die Zeitdimension berücksichtigt!
Sollte sich zu diesem Thema noch was ergeben, bin ich sehr interessiert, es zu erfahren. Ich arbeite gerade selber an einem Loginverfahren, dass "nöglichst sicher" und bequem für den Nutzer werden soll. Die Irrläufer stapeln sich hier schon. Nicht jede Idee war gut.
Grüße aus http://www.braunschweig.de
Tom
-
Hallo Tom,
Wenn nur ein Benutzer arbeitet, dann wird es wohl tatsächlich schwer sein, die eine gültige Session-ID aus dem Vorrat zur erraten. Was ist aber, wenn es schon 3000 Benutzer sind, die Sessions unterhalten?
Die Session-ID ist 32 Byte lang, daß sind ungefähr 4,3 Milliarden Möglichkeiten. Wenn davon 3000 gültig sind, ist das immer noch (grob gerechnet) eine Chance von 1:1 Million, daß eine beliebig eingetippte Session gültig ist. (ein Lottosechser hat eine Wahrscheinlichkeit von 1:14 Millionen)
Man könnte ja auch serverseitig den Traffic mit einer IP für eine Weile ablehnen, wenn von dort z.B. mehr als 5 Fehlversuche innerhalb einer Zeitspanne von 10 Minuten gekommen sind.
Als zusätzliche Sicherheit vielleicht einen Versuch wert, allerdings gibt es IP-Spoofing. Wenn Du die IPs verwendest, und jemand macht einen Angriff, der scheinbar aus einem bestimmten Firmennetz kommt, dann sperrst Du damit das falsche Netz. Hilft also im Zweifelsfall auch nur gegen Skript-Kiddies.
Viele Grüße
Stephan-
Hi Stephan,
Die Session-ID ist 32 Byte lang, daß sind ungefähr 4,3 Milliarden Möglichkeiten. Wenn davon 3000 gültig sind, ist das immer noch (grob gerechnet) eine Chance von 1:1 Million, daß eine beliebig eingetippte Session gültig ist. (ein Lottosechser hat eine Wahrscheinlichkeit von 1:14 Millionen)
Meist Du wirklich 32Byte und nicht 32Bit? 32Byte würden ja tatsächlich eine recht hohe Sicherheit geben. Aber wahrsacheinlich nith 2hoch256 sonder "nur" 2hoch224. Darf ja wahrscheinlich weider nicht jedes Zeichen drinstehen, oder?
Sessions sind unser Tagesthema, darum frage cih nochmal nach.
Tom
-
Hallo Tom,
Meist Du wirklich 32Byte und nicht 32Bit? 32Byte würden ja tatsächlich eine recht hohe Sicherheit geben. Aber wahrsacheinlich nith 2hoch256 sonder "nur" 2hoch224. Darf ja wahrscheinlich weider nicht jedes Zeichen drinstehen, oder?
Oops, ja, Du hast recht, es sind natürlich 32Byte. Dann würde ich aber schon auf 2hoch256 tippen, man muß die Bytes ja nicht nach Ascii umsetzen.
Viele Grüße
Stephan -
Hallo!
Die Session-ID ist 32 Byte lang, daß sind ungefähr 4,3 Milliarden Möglichkeiten. Wenn davon 3000 gültig sind, ist das immer noch (grob gerechnet) eine Chance von 1:1 Million, daß eine beliebig eingetippte Session gültig ist. (ein Lottosechser hat eine Wahrscheinlichkeit von 1:14 Millionen)
Meist Du wirklich 32Byte und nicht 32Bit? 32Byte würden ja tatsächlich eine recht hohe Sicherheit geben. Aber wahrsacheinlich nith 2hoch256 sonder "nur" 2hoch224. Darf ja wahrscheinlich weider nicht jedes Zeichen drinstehen, oder?
Beides falsch, Session ist ein MD5-String und das ist eine Hexadezimalzahl, genauer 128 bit. Also schon recht sicher, siehe auch </archiv/2002/9/23580/#m130655>
Ich halte es auf alle Fälle für eine gute Idee IPs nach x Fehlversuchen verübergehend zu sperren, denn auch wenn es "nur" gegen Script Kiddies hilft, was meinst Du wieviele Angriffe von bekloppten Script-Kiddies und wieviele von "echten Hackern" ausgehen, und bedenke was letztere überhaupt für ein Interesse haben könnten!
Und ob IP-Spoofing quer über das Internet so einfach ist weiß ich auch nicht, vermutlich muß irgendein Leck im Netzwerk mit der Angreifenden IP vorhanden sein, womit die Sperrung berechtigt ist.
Aber die Wahrscheinlichkeit, auch bei 3000 gleichzeitigenb Sessions, das ein Angreifer per brute-Force eine der Sessoins errät halte ich für vernachlässigbar. Problematischer ist wenn die Daten jedesmal per GET im Klartext übertragen werden und dann auch noch in allen möglichen, auch fremden Logs auftauchen.Grüße
Andreas
-
-
-
-
Hallo!
Habe im Forum leider nichts wirklich Aussagekräftiges gefunden.
Wo hast Du denn gesucht? Was hälst Du hiervon:
Grüße
Andreas-
Hallo!
Habe im Forum leider nichts wirklich Aussagekräftiges gefunden.
Wo hast Du denn gesucht? Was hälst Du hiervon:
----davon halte ich, dass ich eine Fehlermeldung bekomme, wonach
----die Seite nicht existiert :-)
----trotzdem danke fürs posting, war ja gut gemeint!Grüße
Andreas
-