Password mit Datenbank

[Karsten06]

Guten Tag!

Ich habe gerade eine Website übernommen, die bislang komplett statisch war und jetzt um ein paar serverseitige Features bereichert werden soll. Zum Beispiel sollen User, die vorher von mir einen Login-Account eingerichtet bekommen haben, in einem geschützten Bereich Termine und aktuelle Meldungen in eine MySQL-DB eintragen können. Eigentlich rechtfertigt das allein noch nicht das Umstellen auf ein CMS, deswegen wollte ichs selbst machen.

Mir hat jemand dringend davon abgeraten so einen geschützten Bereich mit .htaccess abzusichern wenn es wirklich einigermaßen sicher sein soll (Frage: warum eigentlich? Ist .htaccess so riskant?)

Jedenfalls hatte ich mir folgendes ausgedacht:

- serverseitiger Login über Login-Page mit Username- und Passwortabfrage

- Username und Passwort sind MD5-verschlüsselt und mit Session-ID in MySQL-Datenbank eingetragen

- Timestamp-Eintrag in Datenbank damit man nach 10 Minuten Inaktivität automatisch ausgeloggt wird

- Username wird zusätzlich in Cookie gespeichert und bei jedem Seitenaufruf wird neu geprüft ob der User im Cookie auch in der DB als eingeloggt steht (Daten werden aber ausreichend gefiltert um poisoned cookies vorzubeugen). Timestamp-Timer wird dann wieder auf null gesetzt wenn unter 10min.


ferner:

- Login-History-Tabelle in DB um zurückzuverfolgen wer wann eingeloggt war



Wie siehts aus damit? Ist das so ok? Hat hier noch wer zusätzliche Ideen wie man sowas auf nem LAMP-Server absichern kann?

Viele Grüße, Karsten

[ghostgambler]

Re: Password mit Datenbank

Original geschrieben von Karsten06
(Frage: warum eigentlich? Ist .htaccess so riskant?)

Ich wüsst jetzt spontan nicht, was dagegen spricht das für einfache Abschirmungsmechanismen zu verwenden ... wenn du natürlich nach Usern z.B. trennen willst, oder sowieso session brauchst, oder oder oder, würde ich die php-Lösung bevorzugen, weil sie einfach schöner ist ^^

[Karsten06]

Grundsätzlich will ich einfach die "Latte" relativ hoch legen für die ganzen Skript-Kiddies und Amateur- bis fortgeschrittenen Hacker, d.h. es denen so schwer wie möglich machen.

Hat sonst noch wer Anmerkungen zu dem was ich da zur Absicherung durch PHP/MySQL geplant habe?

[extr3m0]

-ip-überprüfung!!! (sollte man aber auch deaktivieren können... sonst bekommen die aol-user ein problem!!! [häufig wechselnde ips])

-ansonsten: wenn du z.b. eine session-id per url überträgst, dann noch zusätzlich einen check-schlüssel (einer pro session, auch in der login-tabelle speichern) per cookie speicherst... (oder andersrum, wenn du die sid in einem cookie speicherst)

mehr fällt mir grad auch nciht ein!

[ghostgambler]

Original geschrieben von extr3m0
-ip-überprüfung!!! (sollte man aber auch deaktivieren können... sonst bekommen die aol-user ein problem!!! [häufig wechselnde ips])

wenn sollte das Skript das selber entscheiden...

-ansonsten: wenn du z.b. eine session-id per url überträgst, dann noch zusätzlich einen check-schlüssel (einer pro session, auch in der login-tabelle speichern) per cookie speicherst... (oder andersrum, wenn du die sid in einem cookie speicherst)

lol?
Das ist ja mehr Arbeit als Effekt ... SID in URL ist für die Fälle wo Cookies nicht erlaubt sind/der User keine will. In so einem Fall einen Cookie setzen zu wollen ist mehr als unangebracht und wenn die SID im Cookie klebt, ist das damit die URLs einfacher werden, bzw. man sich die Dinger vernünftig bookmarken können soll, da ist ein zusätzlicher GET-Par auch geringfügig unangebracht, geschweige denn sind Cookies in den meisten Fällen eindeutiger zuzuordnen als SIDs in URLs. Zusätzliche unnötige GET-Parameter behindern auch Suchmaschinen und nicht zuletzt einfach die Verständlichkeit der URLs.

Für gewöhnlich reicht die SID aus, einzig wirklich sichere Dinge, z.B. Online-Banking, hantiert noch an jedem Link mit einem extra Hash um auch wirklich sicher zu sein, dass der User den Link angeklickt hat und nicht jemand die Session geklaut hat und dann einfach versucht auf eine Seite zu kommen. Dies lässt sich aber nur mit erheblich mehr Prozessorleistung alles abwickeln und ist des weiteren auch nicht so übersichtlich vom Programmcode her, denn es müssen eine Menge Überprüfungen getätigt werden (die sowohl Prozessor, wie auch Datenbankserver, ein wenig beschäftigen...)