Verständnissfrage zu einem sicheren PHP-Login

[bobafett]

Halle alle zusammen,

ich bin seit einigen Tagen dabei meine Web-Applikationen auf Fehler, Probleme und Sicherheitslücken zu prüfen und entsprechend zu fixen/anzupassen.

Vorgestern war der Login-Prozess an der Reihe. Diesen würde ich gerne insofern weiter ausbauen, als dass ich den eingeloggten Benutzer an seine IP binden möchte. Aktuell gibt es für jeden Benutzer ein Sitzungslimit von 30 Minuten. Sollte also der Benutzer an eine IP gebunden, und zufällig kurz nach dem einloggen von seinem Provider eine neue IP zugewiesen bekommen, würde er für die restliche Zeit sich nicht mehr einloggen können.

Aus diesem Grunde würde ich das ganze eher auf einen Adressbereich beschränken, was im falle vom obigen Beispiel dann kein Problem mehr sein sollte. Das dann auch weitere Logins aus dem selben Adressbereich für den Benutzer möglich sind muss man wohl in Kauf nehmen.

Nun allerdings zu meiner eigentlichen Frage: Wie kann ich das ganze mit dem IP Adressbereich am besten umsetzen? Soweit ich mich informiert habe, besitzen einige Provider mehrere verschiedene Adressbereiche. Arcor z. B. hat die 88.x, 134.x, 138.x. reserviert. Habt ihr etwas ähnliches, oder genau DAS schon einmal umgesetzt, und wenn Ja .. wie?! Bevor ich mir hier das Teil hier parse und in meine Datenbank einpflege (ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt) um zu prüfen welche Adressbereiche erlaubt sind, würde ich mich über ein paar Antworten zu dieser Problematik sehr freuen




cheers

[h3ll]

Was ist, wenn der Benutzer zwei unterschiedliche Provider verwendet?

[bobafett]

Darüber habe ich mir natürlich auch Gedanken gemacht.
In diesem Fall hat der Benutzer dann Pech

Da es dem Benutzer aber selbst obliegt seine Sitzung an einen Adressbereich zu binden (das ganze versteht sich optional!), ist er sich dieser Sache wohl bewusst wenn er sich dann mal nebenbei vom Netbook oder iPhone etc. nicht einloggen kann.



cheers

[combie]

Ein echter (DA)User denkt sich:

Schei** Seite. Tuts schon wieder nicht.
Und Tschüss....

Vergiss die IP !

[bobafett]

Ich denke das warum spielt hier keine Rolle, da ich es auf jeden Fall implementieren werde. Demnach wären Hilfreiche Lösungsvorschläge doch angebrachter als das bisherige.

Vielen Dank.


cheers

[pekka]

Hm, die übliche Lösung für das Problem sind doch Session-Cookies, oder? Funktionieren Providerübergreifend.

Ansonsten wirst du nicht drumrumkommen, die IPs deiner Besucher auf ihren RIPE-Record abzuklopfen und wenn es noch derselbe ist, die Session zuzulassen. Ich kann mir aber Fälle vorstellen, in denen das zu falschen Ergebnissen führt, etwa bei Reseller-Providern, die IPs von einem Großhändler "mieten".
Und wahnsinnig gefährlich ist es ohnehin: Wenn Du damit Sessions fortsetzen willst, ohne eine Passwortabfrage zwischenzuschieben, schaffst Du eine riesige, komplizierte Sicherheitslücke, Optional hin oder her.

[bobafett]

Und wahnsinnig gefährlich ist es ohnehin: Wenn Du damit Sessions fortsetzen willst, ohne eine Passwortabfrage zwischenzuschieben, schaffst Du eine riesige, komplizierte Sicherheitslücke, Optional hin oder her.

Da hast du vollkommen Recht, zum Glück mache ich das ja auch nicht

[Kropff]

Ich denke das warum spielt hier keine Rolle, da ich es auf jeden Fall implementieren werde. Demnach wären Hilfreiche Lösungsvorschläge doch angebrachter als das bisherige.

So einfach solltest du dir das nicht machen. Es gibt tatsächlich Provider, die bei einem User ständig die IP ändern. AOL macht das zum Beispiel etwa alle 30 Sekunden und noch irgendeiner, der aus Schweden kommt. Mir zerhauts bei solchen Usern regelmäßig die Zugriffsstatisitik, da die auch IP-basiert ist. Insofern halte ich das für keine gute Idee. Aber mit Begründung .

Peter

[bobafett]

Es gibt tatsächlich Provider, die bei einem User ständig die IP ändern

Solange sich die jeweils neue IP im gleichen Adressbereich befindet sollte es da keine Probleme geben. Daher ja auch meine Frage wie man dies am besten umsetzen kann. Wenn sich keine vernünftige Lösung finden kann, wird es natürlich auch nicht implementiert .. ich versuche es allerdings umzusetzen :-)

Wie gesagt .. es obliegt ja dem Benutzer selbst dieses feature zu nutzen, demnach sehe ich da auch keinerlei Probleme. Es wird ja niemand genötigt das auch zu nutzen!

cheers

[Kropff]

Solange sich die jeweils neue IP im gleichen Adressbereich befindet sollte es da keine Probleme geben.

Ups, das habe ich übersehen. Allerdings ändert sich imho die Liste permanent. Du müsstet also die Datei (wenn sie denn überhaupt immer aktuell ist) eigentlich täglich parsen. Außerdem verstehe ich nicht, wieso das ein Mehr an Sicherheit bedeutet?

Peter

[AmicaNoctis]

Ich konnte in der Liste kein "77.179" finden (meine aktuelle IP). Ich bin bei 1und1 und mein Pool gehört zu mediaways.net. Evtl. ist die Liste nicht vollständig oder nicht aktuell.

Gruß,

Anja

[PHP-Desaster]

Ich konnte in der Liste kein "77.179" finden (meine aktuelle IP). Ich bin bei 1und1 und mein Pool gehört zu mediaways.net. Evtl. ist die Liste nicht vollständig oder nicht aktuell.

Doch, ist in der Liste:

de.mediaways
    Telefonica Deutschland GmbH 
...
    20061117	77.176/12	ALLOCATED PA
...

Ich erkläre aber besser kurz, wieso hier die 77.179 bei ist. Eine IP besteht aus 4 Bytes, zwischen jedem wird in der Dottedform ein Punkt gesetzt. 77.179 sind also 2 Bytes. Die Ziffer hinter dem Slash in dem Adressbereich 77.176/12 beschreibt, wieviele Bits fest sind, d.h. den eigentlichen Bereich adressieren. Hier sind dies 12 Bits, d.h. das erste Byte und die 4 obersten Bits des Folgebits.
Wie sieht unsere Adresse in Bits aus?

77.176 <=> [B]1001101.1011[/B]0000

Dabei sind nur die ersten 12 Bits für die Bereichsadressierung nötig. Wie sieht deine IP aus?

77.179 <=> [B]1001101.1011[/B]0011

So, und wie du siehst, liegt deine IP sehrwohl innerhalb des allozierten Adressbereichs

[onemorenerd]

Was genau versprichst du dir denn davon? Vor was willst du dich oder deine User schützen?

[AmicaNoctis]

Sorry, alles klar, hatte vergessen, dass es ja auch "unrunde" Subnet Masken gibt *schäm*

[wahsaga]

Das ganze optional anbieten, schön und gut - macht heise.de in seinem Forum bspw. auch so. Allerdings auf genau die aktuelle IP beschränkt.
Wer das Feature nutzt, sollte wissen, was er tut.

Es auf ganze IP-Bereiche auszudehnen, da halte ich aber nichts von. Die Wahrscheinlichkeit, dass ich und der, der sich in meinen Account "reinhacken" möchte (in dem er bspw. meinen Session-Cookie entführt oder was auch immer), uns beide innerhalb von einem solchen befinden, ist in der deutschen Providerlandschaft eh schon ziemlich hoch. (Wie hoch, käme jetzt darauf an, wie weit man "IP-Bereich" fasst.)
Und wenn ihm wirklich was an meinen Daten/meinem Account liegt - dann "verschafft" er sich halt eine IP aus dem gleichen Bereich. Wie dein System diesbezüglich arbeitet, dass weiss er ja entweder schon aus deiner Beschreibung, mit der du dem Nutzer dieses optionale Feature anbietest, oder er findet's über einen Testaccount selber raus.

Wenn du wirklich IP-Bereiche zulässt, gaukelt das System also m.E. eine Zusatzsicherheit vor, die im Zweifelsfalle gar nicht gegeben ist. Und das ist etwas, was man tunlichst unterlassen sollte.
Also entweder auf eine IP beschränken (dann ist es nur was für Nutzer, deren Zugang entsprechende Voraussetzungen mitbringt, wie bspw. IP gleichbleibend über einen "längeren" Zeitraum) - oder ganz bleiben lassen ... meine Meinung.