maller86

Hallo Community,

ich erstelle diesen thread da ich zu diesem Thema, hier und da draussen,
nicht wirklich das gefunden habe, was ich eigentlich gebrauchen kann.

Mein Ausbilder möchte von mir eine Ausarbeitung eines Hacksicheren Login haben.
Habe da auch was geliefert, aber ihm ist das zu wenig.

Meine vorstellung einen Hacksicheren Login zu realisieren:
Eigene Sessionverwaltung in der Datenbank.
Cookie mit md5-hash aus folgendem Inhalt beim Benutzer:
md5( $sUserSessionID, $iUserID, $sUserIP );
Mit jedem Klick wird die SessionID regeneriert
und in der Datenbank sowie auch im Cookie gespeichert.
Sobald die SessionID oder die IP nicht übereinstimmt, wird ausgeloggt!

Nun meine Frage:
Gibts da noch mehr was ich beachten muss, weil wir noch eMail-Verkehr haben?
Wie könnte ein Hacker das knacken und wie sichere ich das noch weiter ab?


Ich danke euch im Vorraus

Gruß
maller86

Mister Ad

tomtaz

Nun ja, du könntest, das er sich überhaupt nicht einloggen kann, nach einer gewissen anzahl an Logins das Fomular für Ihn sperren... Oder so

__________________
Mfg Tomtaz
"Es soll jetzt diese Erfindung geben.... Kugel oder so heißt die. Ist so eine Art Suchmaschine..."

22hase

also ich denke mal sicher ist garnix....man kann es den nur schwer machen.

wenn ein hacker was knacke nwill dann schafft er es auch auf eine art und weise...

David

Welchen Umfang hat die Aufgabe denn genau? Geht es nur um den Login-Vorgang selbst oder um die Implementierung eines geschützten Bereichs?

• session_regenerate_id() würde ich nur direkt nach erfolgtem Login einmal anwenden.
• Sofern es die Anforderungen zulassen, würde ich session.use_trans_sid ab- und session.use_only_cookies anschalten.
• den IP check würde ich zwar als Standardeinstellung einschalten, aber beim Login abschaltbar für die Session machen. Es gibt immer noch Benutzer, bei denen sich die IP regelmäßig während einer Sitzung ändert.
• sofern es die PHP Version hergibt bei session_set_cookie_params httponly auf true setzen.
• Den Ausbilder fragen, welche Form von brute-force-Sperre er bevorzugt. Die meisten davon haben mal kleinere mal größere Auswirkungen auf reguläre Benutzer.
• für Formulare, die im weiteren Verlauf angriffssicher sein müssen, kannst Du die in http://freedom-to-tinker.com/sites/d...files/csrf.pdf beschriebene Technik verwenden. Dabei hast Du bereits einen httponly Cookie auf dem Rechner gespeichert, den Sessioncookie. Du kannst den Wert also in _SESSION speichern anstatt einen weiteren Cookie zu setzen.

maller86

es muss doch noch was geben auf was ich nicht geachtet habe oder wovon ich nicht weiß, wenn es ihm zu wenig ist.

maller86

die seite soll sicher sein, also nicht über login oder menübereich oder durch sonstwas infiltriert werden können.

David

Hast Du darauf geachtet, dass alle zu schützenden Resourcen Deine Session-Verwaltung beachten?
Hast Du Dich mit csrf beschäftigt? Das oben verlinkte PDF gibt einen Überblick.

Was tust Du mitbzw was machst Du dann mit den Daten?

maller86

Ich würde die Daten auf dem Server auch nach
md5( $sUserSessionID . $iUserID . $sUserIP );
verschlüsseln und mit dem Cookie des eingeloggten Benutzers vergleichen.

Wenn sich keine übereinstimmung ergibt, so wird ausgeloggt.

//edit:
danke für den Link, werde mir das genauer anschauen mit der PDF-Datei.

David

Was ist mit den beiden Fragen davor?

Das ist dann also Dein Session-Cookie? Oder ist das noch was zusätzliches? Ich sehe gerade den direkten Nutzen nicht auf Anhieb.

maller86

Ich würde den verschlüsselten String als Cookie beim Benutzer abspeichern lassen. Wenn der Benutzer auf der Seite unterwegs ist so wird immer geprüft ob die Daten identisch sind. Durch die Sessionverwaltung in der Datenbank habe ich die einzelnen Daten zur Hand. Verschlüssele diese Daten aus der Datenbank in der gleichen Folge wie die Daten im Cookie und vergleiche diese.
Sobald die verschlüsselten Werte nicht gleich sind, wird ausgeloggt bzw. die Daten aus der Datenbank entfernt. Das Cookie wird zusätzlich gespeichert.

Hoffe es ist so verständlicher formuliert.