[_root]

Mitgliederbereich mit Login

Also mein "Problem" leigt darin das ich mir gerade eine authentifizierungs Klasse schrieben will. Dies ist aber schon Schritt 2, momentan bin ich noch im Brainstorming.
Was ich damit Sagen will ist das ich nicht Recht weis wie ich einen hohen Sicherheitsstandart erhalte und gleichzeitig den User nicht all zu stark "behindere".

Diverse Mechanismen zur Sicherung von Sessions sind nun schon implementiert. Skeptisch bin ich immer noch gegen das 'fingerprint' system:

PHP-Code:

<?php
$string  = $_SERVER['HTTP_USER_AGENT'];
$string .= 'Sicherheitswort';

$fingerprint = md5($string);
?>

Danach das ganze entsprechend bei jedem Aufruf abfragen. Nur kann es ja sein das z.b. jemand uber einen Proxy die Seite und den internen Mitgliederbereich besucht. Ein Proxy kann $_SERVER['HTTP_USER_AGENT'] verändern was zur folge hätte das der User aus dem Mitgliederbereich herausgeschmissen und hat keine Ahnung wiso.

Nun zur Frage, hat jemand von euch dieses "Fingerprint" System im produktiven Einsatz und hat es sich bewährt?

Desweiteren würde mich interessieren wie ihr das mit dem Sicherheitswort handhabt. Hier gäbe es ja verschiedene möglichkeiten.

• Regelmässiger Wechsel um (MEZ+1) 3Uhr Nachts. Problem, User aus anderen Ländern z.b. Asien sind uns 6-8h vorraus Sprich (MEZ+7 - MEZ+9). Wenn bei uns 3Uhr ist und die meisten Offline sind kommt in Asien schon bald eine haupt online Zeit. Sprich wenn bei uns dann die Sicherheitswörter wechseln sind alle unweigerlich draussen und sie müssen sich neu einloggen.
• Fix Array, meine erstmal bevorzugte methode ist das fix array das per get oder cookie z.b. etwas wie index.php?pin=54sd45s steht was auf einem Array basiert das dann eigentlich der Index (assoziativ) zum Wort ist.

PHP-Code:

<?php
$pin = array("54sd45s" => "test",
"456ds45" => "u.s.w."
)
?>

Oder habt ihr noch gute ideen um Session's abzusichern?

Danke erstmal, gruss
_root

Ich beschäftige mich sehr viel mit Web Security, aber ich habe noch nie was vom Fingerprint System gehört ... . Aber egal, jetzt zu deinem Problem.

Du erstellst ein "Sicherheitswort" in der DB. Nach dem Login ladest du es in eine Session und vergleichst ob das in der Session noch immer das gleiche wie in der DB ist, wenn nicht => ausloggen?

Sofern du das so machen wolltest, kannst du es auch gleich wieder vergessen. Weil es die Sicherheit nicht erhöht.

Viel wichtiger wäre einen Sessionhandler zu erstellen und die Sessions in einer DB zu speichern. Weil wenn jemand anderer auf dem gleichen Server wie du ist, kann er deine Session ids auslesen mit einem 10 Zeiler Script.

Das kritische an einer Auth...-Klasse ist das Login. Deshalb sollte dein Hauptaugenmerk am Login liegen und nicht wie du bei einzelnen Seiten die Sicherheit um 0.00000001% erhöhst und die Laufzeit dafür um ne ms.

EDIT: Für was willst du das "Sicherheitswort" überhaupt ändern?!

MfG Fat Tony

[Jojo]

Ist dein Fingerprintsystem nicht löchrig?
wenn z.B. zwei User über den selben Useragent und über den selben proxy reingehen, kann der zweite nicht das system "knacken"?

Rein von der Überlegung her:
Wenn jemand einen Proxy nutzt, kannst du ja über getenv('HTTP_X_FORWARDED_FOR') den X-Host ermitteln.
Der müsste ja immer gleich bleiben, auch wenn der Proxy zwischendurch die IP wechselt.
Wenn dieser leer ist, nimmst du die IP vom user als key.
wenn nicht, müsste man sich mal überlegen, ob man die interne ID noch mit irgendwas verbindet, damit nich zwei user den gleichen key haben.

Diesen Key nimmst du dann um Daten zu verschlüsseln, die du in die Session speicherst. Und beim Rauslesen nimmst du den aktuellen Schlüssel den du beim Laden der Seite erhälst zum entschlüsseln.

Is aber ein reines Gedankenexperiment.
Noch nich versucht, o.ä.

Jojo

[_root]

Das Login ist nicht das Problem das einzige was mir noch sorgen macht ist das Forum, da gibt es die möglichkeit blider von externen Seiten zu verlinken. Dies muss leider möglich sein. Also ist es zeimlich einfach an die Session ranzukeommen mit einem php Bild via Referer wenn jemand keine Cookies will oder keine haben kann. Deshalb die Sache mit dem Sicherheits wort dies bringt aber eigentlich kaum was und ist auch nicht mal Sicher das es gut funktioniert.

Was macht ihr denn gegen Referer, Session-Hijacking?

[_root]

Zitat von Jojo

I
Rein von der Überlegung her:
Wenn jemand einen Proxy nutzt, kannst du ja über getenv('HTTP_X_FORWARDED_FOR') den X-Host ermitteln.
Der müsste ja immer gleich bleiben, auch wenn der Proxy zwischendurch die IP wechselt.

Funktionert nicht wirklich, es gibt viele möglichkeiten das du mit HTTP_X_FORWARDED_FOR nichts erhälst. Sprich es kommt auf die konfiguration des Proxy's darauf an. Dies funktioniert höchstens bei einem Transparenten.

[Jojo]

stimmt......
Es ist halt schwer, einen user eindeutig zu identifizieren, wenn er hinter einem proxy hängt, ohne ihn auszuschließen.....

im zweifelsfall: ssl

//edit: was mir grade einfällt:
du könntest natürlich irgendwie (GET oder COOKIE) eine uniqid() mitsenden. die bei jedem aufruf des skripts geändert wird und auch in der session abgespeichert wird.
Also kann sie nur einmal verwendet werden.
wenn ein dritter nun eine URL mit session-id und veralterter uniqid daherkommt, wird erkannt, dass diese uniqid nicht gültig ist. also wird er abgewiesen.
Ist aber nur ein zusätzlicher Schutz, da es natürlich sein kann, dass der user an sich noch keine neue id bekommen hat.

Schwierig schwierig ^^

[_root]

Zitat von Jojo

//edit: was mir grade einfällt:
du könntest natürlich irgendwie (GET oder COOKIE) eine uniqid() mitsenden. die bei jedem aufruf des skripts geändert wird und auch in der session abgespeichert wird.
Also kann sie nur einmal verwendet werden.
wenn ein dritter nun eine URL mit session-id und veralterter uniqid daherkommt, wird erkannt, dass diese uniqid nicht gültig ist. also wird er abgewiesen.
Ist aber nur ein zusätzlicher Schutz, da es natürlich sein kann, dass der user an sich noch keine neue id bekommen hat.

Schwierig schwierig ^^

na ja das kann man ja gleich mit der session machen?! Bei jedem mal aktualisieren oder linkclick ändert sich die session id, sollte die session nun in falsch hände geraten funktioniert es nur solange der richtige User nicht schon weitergeklickt oder aktualisiert hat.
Sollte aber nun der Böse User den aktuellen Link erhalten und weiterklicken ist der gute User draussen.

[schifti]

Cookies, mit jedesmal einem neuen Namen od. Wert?!?
(Wie mit der SessionID, nur einmal ....)

[Corvin]

Zitat von _root

Was macht ihr denn gegen Referer, Session-Hijacking?

Dem User dringend empfehlen, Cookies anzunehmen (ansonsten -> selbst schuld) oder, wenn es mir auch (stark) schadet, wenn jemand anderes die Session übernimmt session.use_only_cookies aktivieren (un den User darauf hinweisen, dass er Cookies aktzeptieren muss).

Sofern du ein sicheres Forum hast, brauchst du vor Session Hijacking keine Angst haben. Verbiete Usern auf nicht bild dateien zu verlinken etc.

MfG Fat Tony

[Corvin]

Zitat von Fat Tony

Verbiete Usern auf nicht bild dateien zu verlinken etc.

Nuja.. das ist auch nicht wirklich ein Schutz. Es ist ja möglich das .jpg- (oder was auch immer) Dateien vom Server geparst werden..