nicht angemeldet
Benötigte Daten zur Benutzerwiedererkennung
Hallo zusammen,
für ein Loginsystem in PHP speichere ich folgende Daten in Cookies:
1. ID des Benutzers
2. Passwort des Benutzers als MD5-Hash
3. Sitzungs-ID des Benutzers als MD5-Hash (über diese ID werden zuvor zusammengestellte Daten in einer Datenbank abgerufen).
Nun sagt man mir, das sei keine besonders sichere Methode, vor allem, dass ich den Passwort-Hash speichere sei eine große Sicherheitslücke. Doch die Frage, die sich stellt ist, wie soll man es besser machen?
Oder muss ich die Kritik nicht ganz so ernst nehmen, denn ich habe festgestellt, dass moderne Boardsoftware (eine davon hatte dieses Jahr noch keine schwerwiegende Sicherheitslücke) die selbe Methode verwendet.
Gibt es allgemein Verbesserungsvorschläge oder Anregungen zu dieser Methode?
Bin dankbar für alle Hinweise.
mfg, Tomas
-
Hallo,
Gibt es allgemein Verbesserungsvorschläge oder Anregungen zu dieser Methode?
Eigentlich sollte es doch ausreichen, eine eindeutige, schwer zu erratene Zeichenkombination serverseitig und klientseitig (Cookie/URL) zu speichern und darüber den Benutzer zu identifizieren. Wozu sollen die anderen Daten gut sein?
ike
-
Hallo,
Gibt es allgemein Verbesserungsvorschläge oder Anregungen zu dieser Methode?
Eigentlich sollte es doch ausreichen, eine eindeutige, schwer zu erratene Zeichenkombination serverseitig und klientseitig (Cookie/URL) zu speichern und darüber den Benutzer zu identifizieren. Wozu sollen die anderen Daten gut sein?
Genau! In den Cookie gehört _nur_ die Session-ID, alles Andere gehört auf den Server.
--roro
-
Hallo,
Genau! In den Cookie gehört _nur_ die Session-ID, alles Andere gehört auf den Server.
Hä? Dann könnte sich doch jeder, der eine Session-ID kennt sich ein Cookie bauen und den Account übernehmen. Liege ich da etwa falsch?
mfg, Tomas
-
Hä? Dann könnte sich doch jeder, der eine Session-ID kennt sich ein Cookie bauen und den Account übernehmen. Liege ich da etwa falsch?
Deswegen sollte diese Zeichenfolge schwer zu erraten sein, z.B. in dieser Form: 967a1a1dde2d20925c60fd655ceab16a.
ike
-
Deswegen sollte diese Zeichenfolge schwer zu erraten sein, z.B. in dieser Form: 967a1a1dde2d20925c60fd655ceab16a.
Ich verstehe schon, wie das funktionieren soll und ich kann mir auch keine Möglichkeit vorstellen, wie jemand an den Hash kommen könnte ohne dass er auch an die anderen beiden Werte kommt, wenn ich sie setzen würde.
Aber warum macht das keiner?
-
Aber warum macht das keiner?
Benutzer-ID und Passworthash werden deshalb extra als Cookie gespeichert, weil damit der Dauerlogin den die meisten Foren bieten möglich ist.
Eine Session wird meist nach kurzer Zeit vom Server gelöscht, wenn sie z.B. 30min inaktiv war. Daher würde ein Dauerlogin nur mit der SessionID nicht funktionieren, diese wäre am nächsten Tag mit Sicherheit ungültig.Um dennoch einen Dauerlogin realisieren zu können hat man also die Benutzerdaten gespeichert und kann damit eine neue Session mit gültigem Login erzeugen.
Die alternative wäre die Lebensdauer der Session zu erhöhen - was bei PHP aber umständlich ist, denn dazu muss man zwangsweise auch einen seperaten Ordner für die Sessiondaten der Software verwenden. Und wenn man mit Lebensdauern von einigen Tagen arbeitet, kann das schnell viel Müll auf dem Server erzeugen.
greetz RFZ
-
Eine Session wird meist nach kurzer Zeit vom Server gelöscht, wenn sie z.B. 30min inaktiv war. Daher würde ein Dauerlogin nur mit der SessionID nicht funktionieren, diese wäre am nächsten Tag mit Sicherheit ungültig.
Wobei ich ja nicht von PHP-Sessions rede, sondern von der Session-ID als Primärschlüssel einer Datenbank, die die Daten enthält. Also ein eigenes System. Die Datanbank kann man ja regelmäßig aufräumen.
Um dennoch einen Dauerlogin realisieren zu können hat man also die Benutzerdaten gespeichert und kann damit eine neue Session mit gültigem Login erzeugen.
Wie gesagt hätte ich die Dauerlogin-Funktion anders gestaltet. Aber dein Beitrag hat mich schon zum Nachdenken gebracht.
mfg, Tomas
-
Wobei ich ja nicht von PHP-Sessions rede, sondern von der Session-ID als Primärschlüssel einer Datenbank, die die Daten enthält. Also ein eigenes System. Die Datanbank kann man ja regelmäßig aufräumen.
Aufräumen kann man immer. Auch Sitzungen, die per Datenserver verwaltet werden, müssen/sollten austimen.
-
Wobei ich ja nicht von PHP-Sessions rede, sondern von der Session-ID als Primärschlüssel einer Datenbank, die die Daten enthält. Also ein eigenes System. Die Datanbank kann man ja regelmäßig aufräumen.
Aufräumen kann man immer. Auch Sitzungen, die per Datenserver verwaltet werden, müssen/sollten austimen.
Das "kann" mache ich mal locker zum "muss". Weil:
- Session-IDs könnten sich wiederholen, also per "Welt" nicht eindeutig sein,
- Benutzer melden ihre Sitzung nicht ab.
Viele Grüße!
Rolf
--
Budu ja
-
Das "kann" mache ich mal locker zum "muss". Weil:
Ich wollte eigentlich nur Ausdrücken, dass 'mein System' zum built-in System in der Hinsicht keine Nachteile hat. Aber danke für's Erwähnen. ;)
-
- Session-IDs könnten sich wiederholen, also per "Welt" nicht eindeutig sein,
;)
Terry Pratchett hat sich in Bezug auf Unendlichkeiten mit der Thematik Welt beschäftigt und festgestellt, dass in einer unendlich grossen Welt Teile unserer Welt (bspw. das Sonnensystem oder unsere Galaxie) sich alle ca. 10^110m wiederholen, und das natürlich in bestimmten Abständen unendlich mal. Der Begriff Multivsersum wurde so geprägt und Hawkings spekuliert da auch fleissig mit. -
Hallo Rolf,
- Session-IDs könnten sich wiederholen, also per "Welt" nicht eindeutig sein,
Das hängt davon ab, wie die Session-IDs generiert werden.
- Benutzer melden ihre Sitzung nicht ab.
Aber schon aus diesem Grund ist es _äußerst empfehlenswert_ die gespeicherten Sessions regelmäßig aufzuräumen. Denn je länger eine Session gültig ist, desto höher ist auch die Wahrscheinlichkeit, dass ein Unbefugter die Session-ID herausfindet.
Grüße,
Johannes
-
- Benutzer melden ihre Sitzung nicht ab.
Aber schon aus diesem Grund ist es _äußerst empfehlenswert_ die gespeicherten Sessions regelmäßig aufzuräumen. Denn je länger eine Session gültig ist, desto höher ist auch die Wahrscheinlichkeit, dass ein Unbefugter die Session-ID herausfindet.
Wobei die Gültigkeit einer Session bei richtiger Implementierung nicht von der Existenz einer Datei oder eines Datensatzes abhängig sein sollte. ;)
-
-
-
-
-
-
moin,
Hä? Dann könnte sich doch jeder, der eine Session-ID kennt sich ein Cookie bauen und den Account übernehmen. Liege ich da etwa falsch?
Nein, Du liegst richtig. Jedoch: Die Kenntnis einer Session-ID sollte schwierig sein. Prinzip: Ein Benutzer meldet sich per Browser mit seinen Credentials (Zugangsdaten: Name, Passwort...) an. Wenn das klappt generiert die Anwendung serverseitig eine Session-ID, die sowohl server- als auch clientseitig abgelegt wird.
Es ist zwar nicht möglich, eine weltweit eindeutige Session-ID zu erzeugen, die auch noch zufällig ist, aber es ist immerhin möglich, eine solche ID zu erzeugen, die unter Millionen Anderen keine Duplikate hat und damit schwer zu erraten ist.
Ansonsten siehe ike
--roro
-
Hi,
Genau! In den Cookie gehört _nur_ die Session-ID, alles Andere gehört auf den Server.
Hä? Dann könnte sich doch jeder, der eine Session-ID kennt sich ein Cookie bauen und den Account übernehmen. Liege ich da etwa falsch?
Ja!
Gruß
Reiner
-
-
-
-
für ein Loginsystem in PHP speichere ich folgende Daten in Cookies:
- ID des Benutzers
Warum?
- Passwort des Benutzers als MD5-Hash
Warum?
- Sitzungs-ID des Benutzers als MD5-Hash (über diese ID werden zuvor zusammengestellte Daten in einer Datenbank abgerufen).
Jo, gut.
Nun sagt man mir, das sei keine besonders sichere Methode, vor allem, dass ich den Passwort-Hash speichere sei eine große Sicherheitslücke. Doch die Frage, die sich stellt ist, wie soll man es besser machen?
Du hast doch eine Sitzung (repräsentiert durch eine eindeutige Kennung, die roundtrippt), die wird doch irgendwann authentifiziert und der Nutzer autorisiert. Nun, also speichere diese Information lokal oder gebe diese immer schön weiter. Machst Du ja auch, gut.
Oder muss ich die Kritik nicht ganz so ernst nehmen, denn ich habe festgestellt, dass moderne Boardsoftware (eine davon hatte dieses Jahr noch keine schwerwiegende Sicherheitslücke) die selbe Methode verwendet.
Hüstel. Passwort als MD5-Hash speichern und die Benutzer-ID? Warum denn?
Gibt es allgemein Verbesserungsvorschläge oder Anregungen zu dieser Methode?
Ja, die oben beschriebene Vereinfachung.
-
Warum?²
Die ID, um das Passwort einem Benutzer zuordnen zu können, den Hash um ihn vergleichen zu können. Damit mache ich eigentlich das selbe wie mit der Sitzungs-ID.
Hüstel. Passwort als MD5-Hash speichern und die Benutzer-ID? Warum denn?
Vermutlich um, wie RFZ meint, eine neue Sitzung zu erstellen.
Ich selbst würde zunächst die alte Situng laden und dann sofort für ungültig erklären und eine neue erstellen.
mfg, Tomas
-
Hüstel. Passwort als MD5-Hash speichern und die Benutzer-ID? Warum denn?
Vermutlich um, wie RFZ meint, eine neue Sitzung zu erstellen.Ja, finde ich persönlich nicht so cool und unsicher. Aber ich habe nun verstanden warum sowas gemacht wird.
Ich selbst würde zunächst die alte Situng laden und dann sofort für ungültig erklären und eine neue erstellen.
Auch wenn die alte Sitzung noch nicht ausgetimt ist? Würde ich nicht machen. - Aber Du siehst schon, alles in allem machst Du alles in allem alles richtig.
-