nicht angemeldet
kleine anmerkdung zu md5:
es ist keine richtige verschlüsselung, sondern ein one way (nicht reversibles) hash verafhren, man erhält als ausgabe immer einen 32 zeichen langen string.
nee meinst du die daten die ich dem cokkie gegeben habe?
also setcookie($name,"DATEN") ?
ich meine, dass du nicht nur prüfst, ob der nutzer ein cookie "DATEN" hat, sondern auch prüfst, ob ein entsprechender nutzer (mit richtigen pass natürlich) in der db vorhanden ist.
Also soll ich das PW und User verschlüsselt ins cookie schreiben?
Ich würds unverschlüsselt eine User ID statt einem Usernamen speichern. Das Passwort natürlich verschlüsselt.
Beispiel:
Ein Nutzer registriert sich. Das Passwort speicherst du verschlüsselt in der DB, verschlüsseln geht z.b. per MD5: http://de.php.net/manual/en/function.md5.php
ganz einfach $pass=md5($_POST[pass]);
und dann gleich nochmal:
$pass=md5($pass);
Grund:
Nehmen wir als Beispiel das Passwort "test".
Verschlüsselt ergibt dies "098f6bcd4621d373cade4e832627b4f6"
(kannste z.b. unter http://scriptserver.mainframe8.com/md5.php machen oder halt selbst n php script schreiben)
Das lässt sich relativ leicht per BruteForce knacken.
Hierbei werden z.B. alle Kombinationen mit 1-4 Buchstaben mit MD5 verschlüsselt und anschließend mit dem verschlüsselten Passwort, also "098f6bcd4621d373cade4e832627b4f6", verglichen (wie gesagt, md5 ist one way, d.h. lässt sich nicht einfach umkehren). aufgrund der (für einen modernen PC) geringen menge an kombinationen ist sowas innerhalb 1,2 minuten erledigt.
wäre nun jedoch das Passwort "test" 2mal verschlüsselt, d.h.
- md5("test") --> 098f6bcd4621d373cade4e832627b4f6
- md5("098f6bcd4621d373cade4e832627b4f6") --> fb469d7ef430b0baf0cab6c436e70375
Wollte man dieses zweimal verschlüsselte Passwort knacken, müsste man alle Kombinationen von 1-32 zeichen ausprobieren - und das sind wesentlich mehr als bei 1-4 zeichen. und dann hätte man auch erst "098f6bcd4621d373cade4e832627b4f6", also das einmal verschlüsselte passwort "test", das man dann wiederrum knacken müsste (das geht nun schnell, aber ist ja nur n beispiel und n passwort mit 32 zeichen zu knacken dürfte jahre dauern, gibt genug tools dafür, kannst es ja mal selbst testen).
wie du evtl. bemerkt hast, beziehe ich mich hier auf angriffe direkt auf den inhalt einer datenbank. beim login musst du natürlich das eingegebene ebenfalls zweimal verschlüssen und mit dem inhalt der datenbank vergleichen, hier müsste ein angreifer dann nur 1-4 zeichen ausprobieren - allerdings übers netz, was bekanntlich wesentlich länger dauert, und du könntest eine ip ja nach z.b. 3 falschen eingaben blocken, sprich praktisch ist sowas nicht rentabel.
nochmal zur übersicht:
registrierung: eingegebenes passwort z.b. 2x verschlüsseln, in der db speichern
login: eingegebenes passwort 2x verschlüsseln und mit dem inhalt der db vergleichen (ist ja bereits 2mal verschlüsselt!)
für cookies/autologin könntest du das ganze z.b. 3 mal verschlüsseln und/oder einen salt hinzufügen. ein salt ist nicht weiter als zusätzliche daten zum passwort, z.b. könntest du als salt "longlong" festlegen.
nehmen wir unser 2x verschlüsseltes passwort "test" von oben:
"fb469d7ef430b0baf0cab6c436e70375"
wir fügen dem ganzen nun den salt hinzu:
"fb469d7ef430b0baf0cab6c436e70375longlong"
das verschlüsseln wir nun mit md5:
"992b808d42f508b41b59f3529326b494"
das könntest du nun in einem cookie speichern.
sollte nun jmd. an die komplette datenbank gelangen, kann er die passwörter nun nicht nutzen, ohne sie zuvor zu knacken. würde das cookie ganz normales das 2x verschlüsselte passwort enthalten, könnte der angreifer das cookie einfach selbst erstellen!
so ist ihm dies nicht möglich, obwohl er die datenbank besitzt.
und was für einen salt du hinzugefügt hast bzw. das du noch ein weiteres mal verschlüsselt hast, das ist an der db ja auch nciht ersichtlich, denn der code dazu befindet sich in den php dateien, und an diese zu kommen ist nocheinmal ein ganzes stück schwieriger.
beim autologin musst du dann natürlich bedenken, dass das verschlüsselte passwort nicht gleich dem in der db ist - einfach das verschlüsselte passwort aus der db auslesen, und das selbe machen wie fürs cookie: "longlong" dranhängen, mit md5 verschlüssen und mit dem inhalt des cookies vergleichen.
hört sich übrigens alles etwas kompliziertes an als es ist, das verschlüsseln des passworts ist absolut kein aufwand, bringt aber sicherheitsmäßig einiges.
MudGuard
Der Martin