nicht angemeldet
Hallo!
Wenn man bei dir unbemerkt Software installieren kann, dann kann man wahlweise am Datenverkehr deiner Netzwerkverbindung lauschen, oder am Tastaturport, wenn du die Paßwörter (dort noch unverschlüsselt) eingibst.
Naja, 'man' ist vielleicht das falsche Wort, die machen das ja mehr oder weniger von alleine, aober ich will mich ja auch nicht rausreden...
Wie meine nachfolgenden Überlegungen ergeben haben, ist es vollkommener Quatsch, einen Zeitstempel oder irgendwelche sonstigen Zusätze zu benutzen: Das verlängert im Endeffekt nur die Session-ID, man hat also mehr Variantionen und entsprechend mehr Zeitaufwand beim Raten.
Nein, das sehe ich absolut anders! Du mußt nicht immer von irgendwelchen Profi-Crackern ausgehen(die würden die Versuche hier eh nur belächeln :-)), aber es gibt ja zig Schattierungen, und je mehr Features man da einbaut desto kleiner wird der Kreis der Leute, die tatsächlich noch Schaden anrichten können! Und nicht nur das: der Angreifer weiß ja nicht, was man da noch verwendet - die SessionID sieht er sofort und kommt da recht problemlos dran, z.B. über irgendwelche referer-Logs. aber da stehe ja garantiert keine Cookie-Daten drin, also um an die Cookiedaten zu kommen, müßte er entweder auf den Clientrechner, was wir hier ja ausklammern wollen, oder die Verbindung irgendwo belauschen, und das ist nicht so einfach denke ich. Wobei ich mich tatsächlich frage, wenn man SSL verwendet - derjenige der es schafft an SSl vorbei zu kommen, für den ist der Rest dann ein Kinderspiel, oder? Aber dann müßte auch sichergestellt sein, das nirgendwo die Referer... geloggt werden. Nicht das jemand dann auf ne andere Seite geht ohne sich abzumelden, dann hätten wir das ja wieder in nem unsicheren Bereich in nem Referer stehe, also ist das mit dem Cookie und Tiemstamp vielleicht doch nicht so dumm, oder?
Es ist vollkommen egal, ob du Session-ID und weiteres Merkmal separat hälst oder zusammenpackst:
SID = abcdefg
Time= 20020603
Mal ein ganz einfaches Beispiel: Wenn man durch raten in solch ein System eindringen will, muß man 7 Buchstaben und 8 Zahlen richtig raten.
SIDTime = abcdefg20020603
Und bei diesem System muß man 7 Buchstaben und 8 Zahlen richtig raten.
Wenn du den Zeitstempel unverschlüsselt auf dem Server abspeicherst und dann verschlüssel im Cookie beim Browser, änderst du im Prinzip nur den String, der zu erraten ist. Statt 20020603 erscheint dann z.B. 67895674 als verschlüsselter String - viel geändert hat das aber nicht, da man wieder nur 8 Zahlen raten muß, diesmal verschärft um die Aufgabe, daß man nicht mehr so einfach sieht, was da mitgeschickt wird - es ist nicht offensichtlich das Tagesdatum, sondern eine Zufallszahl.
Das ist alles richtig, nur bedenke, dass die SessionID nicht gerade kurz ist, und ein md5(microtime()) ist auch nicht ganz so leicht per bruteforce zu erraten, oder? Wenn Du diebeiden Sachen zusammennimmst, dann zeig mir mal jemanden, der eine Gültige kombination errät, die auch zufälligerweise ausgerechnet zudem zeitpunkt 40 Minuten existiert, ich denke da braucht man gar nicht so schwarz zu sehen! und außerdem dauern die Anfragen über http immer so Ihre Zeit, also das zu erraten halte ich für (fast) unmöglich.
Tja, und da kommt eben zum Tragen, daß unverschlüsselte Verbindungen grundsätzlich unsicher sind. AuthType Digest verschlüsselt das Paßwort durch ein Challenge-Response-Verfahren - so erfahren lauschende Angreifer nicht mehr den Zugangsschlüssel, um später nochmal wiederzukommen.
Wobei ich da mal anmerken will, ich habe mir gerade mal ein kleines Tootl zum testen gesucht, war nicht besonders, aber damit konnte ich mich mal selbst belauschen :-) Und wenn man sowas irgendwo dazwischen hätte... man, man. Cookies... alles bekommt man damit, ist ja klar! Aber was mich erstaunt hat, htaccess Benutzerdaten waren verschlüsselt! War Basic! Aber das war kein Klartext, was da stand!!!
Auch wenn Sessions scheinbar hier einen Vorteil haben: Irgendwann müssen die ja auch mal begonnen haben - mit dem unverschlüsselten Übertragen von Paßwort und Username mittels eines Formulars. Und wer das belauscht...
Ja, aber belauschen, dann mußt Du aber auf einem Rechner zwischendurch ein programm installieren können, und das stelle ich mir nicht so einfach vor! ich denke die Rechner +über die richtige Internetverbindungen laufen, sollten doch einigermaßen schwierig zu knacken sein, oder? Aber das hatten wir ja schon, wenn man belauschen kann ist eh alles vorbei...
In diesem Zusammenhang: Die PHP-Funktion get_browser() ist ziemlich billig aufgebaut. Sie schaut in einer Textdatenbank nach, was der Browser im allgemeinen so kann, und zerpflückt ein wenig den User-Agent in seine Bestandteile. Eine Information über den real verwendeten Browser und seine Möglichkeiten ist das nicht.
Ja, das ist mir klar! Aber ich vermute, das sich die Einstellungen über eine Session nicht ändern, ob das jetzt stimmt oder nicht, und das ist entscheidend, mir ist total egal ob das jetzt ein Ferrari xyz oder was auch immer ist, Hauptsache es bleibt ein Ferrari und kein Proxy oder so macht daraus einen Ferrari xyz 145533532!
Ich fasse nochmal zusammen: Der einzige Schutz der jetzt von uns diskutierten Methoden ist der, daß man davon ausgeht, daß ein Angreifer nicht exakt die gleichen Informationen senden kann wie ein ordentlicher Benutzer. Dies wird im Allgemeinen dadurch erreicht, daß ordentliche Benutzer keine Klartextinformationen vom Server erhalten,
Damit meinst Du SSL, oder?
und daß die Vielfalt der Ratemöglichkeiten hinreichend groß ist.
damit meinst Du einen Timestamp oder sowas, oder?
Sessionbasierte Mechanismen haben den leichten Vorteil, daß im Prinzip nach erfolgter Authentifizierung, bei der einmal Username und Paßwort übermittelt wurden, ein Einmal-Zugangsschlüssel (nämlich die Session-ID, meinetwegen angereichert um gewisse Zusatzinformationen) erstellt wird, der irgendwann ungültig wird und dann keine weiteren Benutzungen mehr zuläßt. Diese Methode hilft bei zufällig nach außen gelangten Sessiondaten etwas, den Mißbrauch einzudämmen, ist aber trotzdem nur ein extremst schwacher Schutz. Viel wichtiger ist SSL.
Das stimmt, aber das war mir vorher klar und wird auch verwendet, mich interessieren halt noch die anderen Möglichkeiten!
Letztendlich ist alles nur eine Frage des Rateaufwandes. Man kann auch Benutzernamen und Paßwörter raten und bei Erfolg Zugang erhalten - egal welcher Mechanismus benutzt wird:
Sessions, .htaccess, irgendwas mit SSL. Der Schwachpunkt hierbei ist, wie immer, der Mensch, der sich einfach keine ordentlichen Paßwörter merken kann, sondern den Vornamen der Frau plus das Alter der Kinder nimmt (wobei das Paßwort da ja immerhin noch jedes Jahr gewechselt wird <eg>).
Ja, aber man kann den Rateaufwand ja derart groß machen, das kein Großrechner der Welt das innnerhalb einer Session schafft, oder? Aber Du sprichst was anders an, das einloggen ist natürlich eine ganz andere Sicheheitslücke! Wie kann man sinnvoll verhindern, das sich jemand mit einem Script per Bruteforce probiert einzuloggen? Cookies haben keinen Sinn. Wi könnte man das sonst wirkunksvoll verhindern?
Grüße
Andreas