Hallo Mathias
Welches Angriffsszenario genau soll durch das Gehashe überhaupt bekämpft werden?
Wenn du dem Script einen Salt für den Hash zur Verfügung stellst, sei es die IP-Adresse, sei es die Serverzeit oder sei es ein Zufallstoken: Wenn ich das angreifen will, hole ich mir halt einfach vor jedem Versuch einen Token ab.
Bei einem Zufallstoken wäre das so, in dem Moment wo ich das Kennwort mit der IP verbinde und daraus einen Hash bilde hilft es erstmal niemandem, diese Kommunikation abzuhören. Er benötigt schon die gleiche öffentliche IP-Adresse - das wird bei der Verwendung von Proxi´s natürlich aufgeweicht. Noch Idealer wäre natürlich den Hash aus Kennwort + IP + Uhrzeit zu bilden. Damit müsste der "Mann in der Mitte" schon in dem passenden Zeitfenster die öffentliche IP-Adresse erhalten um mit dem abgefangenen Hash was zu tun.
Ich verhindere damit höchstens, dass eine fremde Website das Script direkt einbinden kann. Oder sehe ich das falsch? Dieses Szenario versuchst du ja auch mit der Referrer-Prüfung zu bekämpfen.
Also grundsätzlich mache ich die Referrer-Prüfung um Fehlleitungen zu verhindern. Also z.B. Robots die sich nicht an die nofollow/noindex halten.
Das sind aber alles letztlich ineffektive Methoden, die den Angriff nur ein wenig schwieriger gestalten. Effektiver wirkt die Sperrung des Nutzernamens und der IP. Allerdings kann ich auch dann von mehreren IPs einfach alle möglichen Nutzernamen durchspielen.
Darum bekommt der "Angreifer" auch keine Meldung, warum die Anmeldung nicht funzt.
Gut, das sind aber Schwierigkeiten, mit denen jede Anmeldung im Web zu kämpfen hat, nicht allein dein spezifisches Konzept.
Da gehe ich von aus - aber gerade aus diesem Grund finde ich ist es die Diskussion wert. Meiner Meinung nach sind alle Schutzmechanismen, solange sie den Benutzer nicht stören, gut. Das sie überlistet werden können liegt natürlich in der Natur der Sache - hier ist dann nur die Frage mit welchem Aufwand der Angreifer zu Werke geht.
Gruß
Matthias