Alain: zu den t-online,AOL-clients anstatt IP's

hallo, ich weiss es ist ein thema,das für manchen bereits bekannt sein dürfte. Dennoch wollte ich zur Archiv-antwort http://forum.de.selfhtml.org/archiv/2003/3/42458/ bzw. http://forum.de.selfhtml.org/archiv/2003/3/41056/ folgendes fragen: Man weiss ja dass bei t-online oder AOL z.B. die ip-nummer bei einer laufenden sitzung ändern kann,was nicht gerade zuverlässig einen bestimmten user erkennen lässt. Nun meine Frage wie wärs denn mit dem server-client + eventuell den browser client zusammen? z.B. so:

....

use Socket; $IPnr = $ENV{REMOTE_ADDR}; $host_name = lenght(gethostbyaddr (inet_aton($IPnr), AF_INET)) || '02'; $agent = length($ENV{'HTTP_USER_AGENT'}) || '01'; $user_check = $host_name + $agent;

....

Kann man davon ausgehen,das zumindest der hostname (wie z.B. t-online oder AOL)  bei der selben sitzung vom selben user immer den gleich langen string hat,selbst,wenn seine IP wechselt?

Grüsse vom Alain-- ...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre

  1. Hi,

    Man weiss ja dass bei t-online oder AOL z.B. die ip-nummer bei einer laufenden sitzung ändern kann,was
    nicht gerade zuverlässig einen bestimmten user erkennen lässt.

    genauer gesagt: Es existiert neben einem Login (und selbst das ist nur bedingt sicher) in HTTP kein Weg, einen User eindeutig zu identifizieren.

    Nun meine Frage wie wärs denn mit dem server-client + eventuell den browser client zusammen?

    Was ist ein "Server-Client"? Wenn Du den Hostnamen meinst: Da ist die IP-Adresse genauer und ressourcenschonender. Die Kombination aus IP-Adresse und User-Agent-String ist üblich; sie bringt Vor- und Nachteile mit sich. Beispielsweise verändern einige Proxies den UA und fügen gelegentlich sogar Timestamps an - eine Wiedererkennung ist dann unmöglich.

    Kann man davon ausgehen,das zumindest der hostname (wie z.B. t-online oder AOL)
    bei der selben sitzung vom selben user immer den gleich langen string hat,selbst,wenn seine IP wechselt?

    Ein Hostname wird zu einer IP-Adresse aufgelöst. Eine IP kann mehrere Hostnamen haben, ein Hostname jedoch nur eine IP. Entscheide nun selbst.

    Cheatah

    --
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Moin!

      Ein Hostname wird zu einer IP-Adresse aufgelöst. Eine IP kann mehrere Hostnamen haben, ein Hostname jedoch nur eine IP. Entscheide nun selbst.

      Es ist noch schlimmer! Ein Hostname kann auch zu _mehreren_ IPs aufgelöst werden. Das wird beispielsweise für Load-Balancing eingesetzt, um eine Serverfarm unter dem gemeinsamen Namen "www.example.com" anzusprechen.

      Umgekehrt gehts natürlich genauso: Mehrere Hostnamen können zu einer einzigen IP aufgelöst werden.

      In der Regel ist das Hostnamen-IP-Konstrukt aber fest. Wenn der Client die IP wechselt, wechselt in der Regel auch der Hostname. Es ist also egal, ob man nun IP+User-Agent oder Hostname+User-Agent zur Identifikation heranzieht - beides ist total untauglich, weil die Wiedererkennung natürlich nicht klappen kann. Denn woher will man wissen, dass der User, der eben noch "192.168.0.1+Mozilla/5.0" war, beim nächsten Zugriff unter "192.168.0.123+Mozilla/5.0" wiederzufinden ist? Es könnten (vor allem bei den Massenveranstaltungen T-Online und AOL) doch genausogut zwei User sein, die zufällig den gleichen Browser haben. Das Problem ist eben, das man sowas nicht raten kann. Mehrere Zugriffe von derselben IP mit dem gleichen User-Agent _könnten_ _vielleicht_ ein und derselbe User gewesen sein (muß aber nicht so sein) - zumindest hat man wegen der IP-Gleichheit einen Anhaltspunkt, dass irgendwas an den Zugriffen identisch ist. Aber wenn man unterschiedliche IPs erkennen will, müßte man wissen, welche Proxy-Struktur der Provider hat, und welche Lastverteilung - all das weiß man nicht, also kann man das Verfahren gleich vergessen.

      Der einzige sichere Mechanismus ist, wenn der Client ein vom Server vergebenes, unverwechselbares Merkmal bei jedem Request mitsendet. Und da gibts zwei Methoden: HTTP-Authentifizierung und Sessions.

      - Sven Rautenberg

      --
      Signatur oder nicht Signatur - das ist hier die Frage!
      1. Hi Sven,

        Der einzige sichere Mechanismus ist, wenn der Client ein vom Server vergebenes, unverwechselbares Merkmal bei jedem Request mitsendet. Und da gibts zwei Methoden: HTTP-Authentifizierung und Sessions.

        Sessions, ja - aber HTTP-Authentifizierung ist (üblicherweise) nicht gegenseitig ausschließend (je nach Implementierung der Serverseite ...).

        Viele Grüße
              Michael

        --
        T'Pol: I apologize if I acted inappropriately.
        V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
        (sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
        Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
      2. Moin!

        Der einzige sichere Mechanismus ist, wenn der Client ein vom Server vergebenes, unverwechselbares Merkmal bei jedem Request mitsendet. Und da gibts zwei Methoden: HTTP-Authentifizierung und Sessions.

        Naja ich würde das auch in kombination mit dem remonte_user machen,was aber beim aol client auch in nächster sekunde ändern könnte als B.s.p. Gibts denn in perl HTTP-Authentifizierung und Sessions methoden und wenn ja wie z.B., die man realisieren könnte,weil bisher hab ich unter session bei der suche in selfhtml nur php,asp, oder javascript gesehen.

        Grüsse vom Alain

        --
        ...nichts ist so schlecht, als daß es nicht für irgend etwas gut wäre
      3. Hi,

        Es ist noch schlimmer! Ein Hostname kann auch zu _mehreren_ IPs aufgelöst werden. Das wird beispielsweise für Load-Balancing eingesetzt, um eine Serverfarm unter dem gemeinsamen Namen "www.example.com" anzusprechen.

        hm, das ist nicht mein Fachgebiet; aber bisher war ich der Überzeugung, dass eine DNS-Anfrage immer die selbe IP-Adresse liefern würde (andernfalls müsste jeder DNS-Server dieselbe Dynamik beherrschen), an der dann natürlich ein Loadbalancer liegen kann, welcher physikalisch auf mehrere Rechner verteilt. Vom Prinzip her nicht wesentlich anders als bei einem Proxy.

        Liege ich da falsch?

        Cheatah

        --
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Moin!

          hm, das ist nicht mein Fachgebiet; aber bisher war ich der Überzeugung, dass eine DNS-Anfrage immer die selbe IP-Adresse liefern würde (andernfalls müsste jeder DNS-Server dieselbe Dynamik beherrschen), an der dann natürlich ein Loadbalancer liegen kann, welcher physikalisch auf mehrere Rechner verteilt. Vom Prinzip her nicht wesentlich anders als bei einem Proxy.

          Liege ich da falsch?

          Scheinbar ja.

          Ich habe mal www.t-online.de auflösen lassen (mit dem dnsqr-Tool, dass beim Paket djbdns dabeiliegt):

          dnsqr any www.t-online.de

          255 www.t-online.de:
          167 bytes, 1+7+0+0 records, response, noerror
          query: 255 www.t-online.de
          answer: www.t-online.de 86400 A 62.153.159.88
          answer: www.t-online.de 86400 A 62.153.159.89
          answer: www.t-online.de 86400 A 212.185.47.88
          answer: www.t-online.de 86400 A 194.25.134.146
          answer: www.t-online.de 86400 A 194.25.134.153
          answer: www.t-online.de 86400 MX 10 mailin00.sul.t-online.de
          answer: www.t-online.de 86400 MX 10 mailin01.sul.t-online.de

          Wie du hoffentlich sofort siehst, sind hier insgesamt fünf Server in drei Netzen gelistet, die auf www.t-online.de hören (sollen). Der DNS-Server von djbdns liefert, wenn bei ihm mehr als 8 IPs für einen Namen registriert sind, zufällig 8 Adressen in einer Antwort aus. Offensichtlich wird solch ein System ziemlich häufig eingesetzt. Die kompliziertere Frage ist, wie man die mehreren Server synchron abgleicht - insbesondere bei schnell wechselndem, dynamischen Content. Und noch eine Sache dürfte schwierig sein: Sessions. Zumindest der Standard-Mechanismus in PHP legt die Session-Informationen auf der lokalen Festplatte ab. Man sollte deshalb irgendeinen zentralen Session-Daten-Server haben (bzw. ein System, welches Session-Daten von allen www-Servern sofort auf mehreren Session-Daten-Servern dupliziert), auf den jeder www-Server zugreifen und die Session-Daten einlesen kann.

          - Sven Rautenberg

          --
          Signatur oder nicht Signatur - das ist hier die Frage!