Wie gestalte ich ein sicheres Loginsystem? (Im Detail)

[molily]

Hallo,

Die Übertragung von Gruppenname und PIN erfolgt mit SSL. Ist die Überprüfung der Daten erfolgreich, passiert folgendes: Aus einer Kombination aus time() in Mikrosekunden und einer Stringkette entsteht eine 30-stellige unique Zufalls ID.

So etwas ist keine gute Idee, weil sehr einfach von Angreifern erratbar. Es ist keine zufällige, sondern eine völlig deterministische ID! time() ist Angreifern bekannt und eine konstante Stringkette lässt sich per Brute-Force finden.

Warum nutzt du keine PHP-Sessions? Die Session-IDs von PHP nutzen viel mehr Entropie als das hier. Zufällig und damit schwer erratbar sind lediglich Session-IDs aus kryptografischen Pseudo-Zufallsgeneratoren, die mit guter Entropie geseedet sind.

Auf dem Server wird eine Session angelegt. Dabei ist die ID der Variablenname und der Variablenwert entspricht dem Gruppennamen, für die man eingeloggt ist. Zusätzlich gibt es auf dem Server eine .txt Datei mit einem Array, in dem die Indices den Timestamp des Login-Endes und die Werte die IDs wiedergeben. Die neu erstellte ID wird nun samt dem gewünschten Gültigkeits-Endzeitpunkt in dieses Array dazugespeichert.

Warum implementierst du das selbst und nutzt nicht PHP-Sessions? Du setzt hier, soweit ich das verstehe, haargenau das um, was PHP-Sessions dir out-of-the-box liefern: Sessions als Dateien mit der Session-ID im Namen, darin serialisierte PHP-Objekte, ein Garbage Collector beendet die Sessions nach einem konfigurierten Timeout.

Bei jedem Aufruf einer geschützten Seite verwende ich zusätzlich session_regenerate_id().

Also nutzt du PHP-Sessions bereits? Dann scheinst du komplett daran vorbei zu programmieren, denn sie bieten bereits, was du offenbar auf deren Basis implementiert hast.

Im Übrigen ist es nicht sinnvoll, die Session-ID mit jedem Request zu erneuern. Das setzt nämlich voraus, das Requests immer streng nacheinander erfolgen. Werden sie parallel abgesendet, was in zwei Browsertabs durchaus vorkommen kann, kommt es zu einer Race Condition: Mit Request A und B jeweils die Session-ID S1 gesendet. Wird Request A zuerst abgearbeitet, wird S1 für ungültig erklärt, serverseitig gelöscht sowie S2 erzeugt und zum Browser gesendet. Wenn der Server anschließend Request B verarbeitet, dessen Request-Header S1 beinhalten, wird dieser Request als unautorisiert verworfen (Weiterleitung auf die Login-Seite o.ä.).

Die Passwörter der Gruppen sind md5()-gespeichert.

Das alleine verbessert die Sicherheit überhaupt nicht! Dann kannst du sie auch im Klartext speichern. MD5 ist eine längst kompromittierte kryptografische Hashfunktion, nicht mehr zu empfehlen ist. Wenn du sie nutzt, dann nur mit einem zufälligen Salt.

Dir scheint Grundlagenwissen zu fehlen – das soll kein Vorwurf oder Angriff sein, nur eine Bestätigung dessen, dass selbstgebaute Lösungen im Bereich Sicherheit in aller Regel unsicher sind. Ich könnte das auch nicht besser, ich weiß lediglich, wovon ich besser die Finger lasse.

Dieses System kommt ohne einer Datenbank aus und für die Verwaltung der paar Gruppen, mit denen ich hier arbeite, ist das IMHO _mehr_ als sicher.

Ein solches System ist halbwegs sicher, wenn es

• gängige Best Practices implementiert,
• geprüfte Bibliotheken und Module korrekt nutzt,
• die Komplexität und Angriffsfläche klein hält,
• einen unabhängigen Security-Audit überstanden hat.

Grüße
Mathias