BlackBoard (http://www.black-board.net/index.php)
- Design, Programmierung & Entwicklung (http://www.black-board.net/board.php?boardid=55)
-- Programmieren (http://www.black-board.net/board.php?boardid=4)
--- PHP Sicheres Loginsystem (MD5 und Session Frage) (http://www.black-board.net/thread.php?threadid=22285)


Geschrieben von HeaD am 23.06.2006 um 15:15:

  Sicheres Loginsystem (MD5 und Session Frage)

Ich habe mir mal verschiedene Loginsysteme von Foren etc. angeschaut und bin zu dem Ergebnis gekommen, das folgendes System offenbar ausreichend und gut zu sein scheint:

MD5 Verschlüsslung des Passwords
Session ID bei Links übergeben
Jeder "Mitglieder"-Seite auf die Sessiondaten abfragen

Ein paar Dinge habe ich aber schon seit langem nicht so ganz verstanden.

MD5: Was bringt mir das? Mittels eines kleinen PHP Befehls entschlüssel ich das ganze wieder. Wovor genau schützt mich also MD5 Verschlüsslung? Also nennt mir bitte mal jemand ein Beispiel was ein "Hacker" ohne MD5 tun kann was er mit nicht kann!?

Session ID: Wieso übergebe ich die Session-ID bei jedem Link, wenn ich die Session eh auf die entsprechenden Variablen überprüfe. Als Zusatzsicherung? Auch hier würde ich gerne mal wissen, was ohne die ID gefährlicher ist als mit (ich habe es bisher eigendlich immer nur genutzt um z.B. die Loginlänge und den automatischen Logout zu bestimmen, oder wenn benutzer Daten hochladen konnten, um so einen einmaligen Dateinamen zu bestimmen)



Geschrieben von LX am 23.06.2006 um 15:25:

Achtung RE: Sicheres Loginsystem (MD5 und Session Frage)

Zu MD5:

MD5 ist eine Einweg-Verschlüsselung, kann also nicht wieder entschlüsselt werden. Genau das ist der Vorteil daran. Das Passwort steht letztendlich nicht in der Datenbank. Dort landet nur ein MD5-Hash, den du mit dem MD5-Hash des eingegebenen Passworts vergleichst.


Zu Session-IDs:

Die brauchst du nicht übergeben, wenn du sie beim Nutzer in einem Cookie ablegst. Beide Varianten haben ihre Vor- und Nachteile. Wenn du die SID im Cookie speicherst, muss der Nutzer Cookies auch akzeptieren. Ansonsten darf er sich mit jedem Seitenaufruf erneut einloggen Augenzwinkern

Gibst du die SID aber in den Links mit, brauchst du weitere Sicherungen, da ansonsten die Session des Benutzers geklaut werden kann, indem dieser beispielsweise einem Freund einen Link schickt und seine Session-ID nicht vorher aus der URL entfernt hat.



Geschrieben von HeaD am 23.06.2006 um 15:29:

  RE: Sicheres Loginsystem (MD5 und Session Frage)

Zitat:
Original von LX
Gibst du die SID aber in den Links mit, brauchst du weitere Sicherungen, da ansonsten die Session des Benutzers geklaut werden kann, indem dieser beispielsweise einem Freund einen Link schickt und seine Session-ID nicht vorher aus der URL entfernt hat.


Mhh aber das Woltlab Board nutzt ja auch Cookies und übergibt trotzdem die Session in der URL... Man könnte das ganze ja absichern indem man die Sessionid zusammen mit der IP in die Datenbank schreibt, aber sobald man dann seine IP wechselt, ist man wieder ausgelogged, also ist das auch keine Lösung. Also wieso wird dann überhaupt die Session ID übergeben und wie ist das abgesichert z.B. auf dem Woltlab Board... falls das bekannt ist Augenzwinkern

Achja und noch eine Frage (im Netz kusieren da die wildensten Storys, deswegen frag ich hier nochmal) .. können Cookies nun geklaut werden oder nicht? (außer direkt bei dem Typen am Rechner sitzen und die Daten auf Diskette kopieren oder sowas Augenzwinkern ) .. und wenn ja, speichere ich nur die Session ID nützt es ihm eigendlich nicht viel !?



Geschrieben von Misel am 23.06.2006 um 18:48:

 

Ein Hash ist keine Verschlüsselung, sondern eher ein Fingerabdruck. Du speicherst in der Regel nur diesen Fingerabdruck, damit das PW nicht im Klartext in der DB gespeichert wird und somit der Admin - oder ein potenzieller Angreifer nicht sofort weiß, wie die Passwörter lauten. Außerdem kann der Hash an den Client geschickt werden und dann im Cookie gespeichert werden, so dass der Client nicht immer das PW im Klartext rüberjagen muss, wenn er was vom Server will. Idealerweise sollten natürlich die Passwort- und Hashübertragungen mit HTTPS übertragen werden.

Zum Cookieklau:

Ein Cookie ist immer nur auf einem Rechner. Der Browser verwaltet die und idealerweise sendet er die Cookies immer nur zu der Domain, die ihn gespeichert hat.

Am besten gebe ich mal ein Beispiel

  1. Du besuchst mit deinem Browser misel.de
  2. misel.de fordert Deinen Browser auf, die Wertzuordnung "xyz=23" in einem Cookie zu speichern
  3. Dein Browser ist darauf eingestellt, Cookies zu akzeptieren und speichert ihn
  4. Wenn du das nächste Mal auf misel.de gehst, sendet Dein Browser im HTTP Header bei der Seitenanfrage die Notiz mit: "In meinem Cookie steht 'xyz=23'"
  5. misel.de kann das nun auswerten ... oder auch nicht

Woher die Unsicherheitsbedenken gegenüber Cookies kommen, weiß ich leider nicht. Aber ich kann mir durchaus vorstellen, dass mal möglich war, dass der Browser den falschen Cookie mitgeschickt hat. Eventuell gibt die Wikipedia bessere Auskunft darüber: http://de.wikipedia.org/wiki/HTTP-Cookie

Erst seit ein paar Jahren gibt es aber die Möglichkeit auch mit Cookies Surfverhalten zu extrahieren.

Daher muss das Beispiel noch erweitert werden:

Wenn ich jetzt auf misel.de ein Element von stefanmisch.de eingebunden habe, kann stefanmisch.de Deinen Browser auch bitten, dafür einen Cookie einzurichten. Diesen Cookie schickt Dein Browser dann bei jeder Anfrage an stefanmisch.de mit, auch, wenn Du direkt zu stefanmisch.de gehst, oder zu js-games.de, sofern dort ein Element von stefanmisch.de eingebunden ist. So ein "Element" kann auch ein Webbug, also ein 1x1 Pixel Bildchen sein.

Firmen, wie zum Beispiel Doubleclick oder Google, über deren Systeme im Web quasi überall Werbung gemacht wird, kriegen somit quasi immer mit, wo Du wann welche Seite besucht hast - natürlich nur dann, wenn dort über Doubleclick oder Google Werbung gemacht wird. In den Cookies steht meist nur eine ID, die dann mit Referrern oder ähnlichem in einer Datenbank gespeichert wird.

Grundsätzlich ist es so möglich Surfprofile zu ermitteln. Es fehlt in vielen Teilen noch die Verbindung zu reellen Personendaten. Diese könnte zum Beispiel über Onlineshops, für die geworben wird ermittelt werden, wenn ein Kauf getätigt wurde.

Es ist allerdings eine RIESIGE Datenmenge und ein riesengroßer Aufwand. Außerdem ist es für die meisten Firmen vollkommen uninteressant, was Oma Kunz am 23.06.2006 um 14:23 so im Web getrieben hat.

Was die interessiert ist der Mainstream, und zu wissen, wie sich die große Masse bewegt. Daher halte ich eine Panikmache für übertrieben.



Geschrieben von HeaD am 24.06.2006 um 00:13:

 

Danke für die Ausführliche Erklärung.. Ich werde mich damit mal genauer Beschäftigen.

Es geht mir nur darum, daß ich gerne mal etwas in PHP programmieren würde, das ich auch weitergeben möchte. Da wäre es natürlich bescheuert, wenn einer das Script ließt und sofort sieht wie man die Sicherheit umgeht Augenzwinkern



Geschrieben von newbi am 24.06.2006 um 00:53:

 

man kann das Script ja auch unlesbar machen, also für das Menscliche Auge und Verstand nicht nachvollziehbar, jedoch hat der Computer damit kein problem.



Geschrieben von Misel am 24.06.2006 um 01:05:

 

Security by Obscurity funktioniert aber einfach nicht!



Geschrieben von HeaD am 24.06.2006 um 01:13:

 

Zitat:
Original von newbi
man kann das Script ja auch unlesbar machen, also für das Menscliche Auge und Verstand nicht nachvollziehbar, jedoch hat der Computer damit kein problem.


Ja war früher auch mal meine Idee. Aber ich wollte es dann schon OpenSource machen, so das andere es später mal erweitern können.


Forensoftware: Burning Board 2.3.6, entwickelt von WoltLab GmbH