Tweet
Ich experimentier gerade mit einer weiteren Lösung gegen Bruteforce angriffe.
Also bislang schützt sich mein Script gegen bruteforce atacken mit einer simplen 3 sekunden verzögerung wenn ein passwort falsch eingegeben wurde, mit der sperrung der IP für eine einstellbahre Zeit bei 4 maligen falscher eingabe des passworts, der abfrage eines Zahlencodes (als image angezeigt) der schon nach der ersten falscheingabe eingegeben werden muss (nur wenn gd verfügbahr ist) und da ich absolut und hochgradig paranoid bin hab ich mir noch was neues einfallen lassen.
Ich bin ja kein hacker aber ich geh einmal davon aus, das die meisten Bruteforce atacken darauf beruhen, mittels script die einloggseite mit abfragen zu benutzername und passwort zu bombardieren, bis ein treffer gelandet wird.
Dazu muss der angreifer die richtigen Request variablen kennen womit er die beiden Daten übermittelt. Das herauszufinden ist kein problem. Man brauch dafür ja nur die Formulare sich anzuschauen.
Mein Ansatz dazu ist, die variablennamen dynamisch zu verändern, so das diese sich zufällig ändern und jeder bruteforce angriff ins leere geht.
Dafür speicher ich Serverseitig einen wert sys_username und sys_userpw in einer Datenbank und ändere ihn zufällig.
Wird das benutzerformular angefordert, werden zuerst diese beiden werte ausgelesen und als namen für die Eingabefelder angegeben.
So nu kommt aber der hacken an der sache. Wenn sich die Variablen serverweitig ändern und ein benutzer sein Formular jedoch bereits erhalten hat, geht sein einloggversuch auch ins leere und er muss sich erneut anmelden. Ich hab das ärgerniss minimiert, ich dem ich maximal alle paar minuten die variablen ändern lass, aber dennoch ist diese Lösung extrem unbefriedigend.
Aber vom Grundsatz halte ich dies für einen guten Ansatz Bruteforce attacken extrem zu erschweren. Frage ist ob die oben genannten abwehrmaßnahmen nicht ausreichend sind und ich lieber meine paranoia herunterfahren sollte anstatt weiter darüber nachzugrübeln.
Oder hat jemand eventuell doch ne idee wie man das lösen könnte ???
Ich geb so ungern ideen auf. Insofern wäre es auch hilfreich, wenn jemand mir den schwachsinn dieser Idee beweist
So sieht es zur zeit aus... glaub man sieht den ansatzt auch ohne nun im detail alle funktionen und Klassen hier mit zu posten
Also bislang schützt sich mein Script gegen bruteforce atacken mit einer simplen 3 sekunden verzögerung wenn ein passwort falsch eingegeben wurde, mit der sperrung der IP für eine einstellbahre Zeit bei 4 maligen falscher eingabe des passworts, der abfrage eines Zahlencodes (als image angezeigt) der schon nach der ersten falscheingabe eingegeben werden muss (nur wenn gd verfügbahr ist) und da ich absolut und hochgradig paranoid bin hab ich mir noch was neues einfallen lassen.
Ich bin ja kein hacker aber ich geh einmal davon aus, das die meisten Bruteforce atacken darauf beruhen, mittels script die einloggseite mit abfragen zu benutzername und passwort zu bombardieren, bis ein treffer gelandet wird.
Dazu muss der angreifer die richtigen Request variablen kennen womit er die beiden Daten übermittelt. Das herauszufinden ist kein problem. Man brauch dafür ja nur die Formulare sich anzuschauen.
Mein Ansatz dazu ist, die variablennamen dynamisch zu verändern, so das diese sich zufällig ändern und jeder bruteforce angriff ins leere geht.
Dafür speicher ich Serverseitig einen wert sys_username und sys_userpw in einer Datenbank und ändere ihn zufällig.
Wird das benutzerformular angefordert, werden zuerst diese beiden werte ausgelesen und als namen für die Eingabefelder angegeben.
So nu kommt aber der hacken an der sache. Wenn sich die Variablen serverweitig ändern und ein benutzer sein Formular jedoch bereits erhalten hat, geht sein einloggversuch auch ins leere und er muss sich erneut anmelden. Ich hab das ärgerniss minimiert, ich dem ich maximal alle paar minuten die variablen ändern lass, aber dennoch ist diese Lösung extrem unbefriedigend.
Aber vom Grundsatz halte ich dies für einen guten Ansatz Bruteforce attacken extrem zu erschweren. Frage ist ob die oben genannten abwehrmaßnahmen nicht ausreichend sind und ich lieber meine paranoia herunterfahren sollte anstatt weiter darüber nachzugrübeln.
Oder hat jemand eventuell doch ne idee wie man das lösen könnte ???
Ich geb so ungern ideen auf. Insofern wäre es auch hilfreich, wenn jemand mir den schwachsinn dieser Idee beweist
So sieht es zur zeit aus... glaub man sieht den ansatzt auch ohne nun im detail alle funktionen und Klassen hier mit zu posten
PHP-Code:
....
....
....
// dieser Ausschnitt steht innerhalb der Benutzerverwaltung
srand((double)microtime()*1000000);
$lastchange=$userdb->getconfig("sys_userlastchange");
$random=rand(0,20);
if (($random==10) and ($lastchange<gmmktime()-2400))
{
// createrandwort ist eine funktion die einfach ein zufallswort erstellt
// Writeconfig schreib einen wert in eine Konfigurationsdatenbank und
// ist letztendlich nur eine mysql abfrage die prüft ob wert vorhanden ist
// und entweder neu anlegt oder updatet
$userdb->writeconfig("sys_username",createrandwort(),'int'); //neuer name fuer benutzername
$userdb->writeconfig("sys_userpw",createrandwort(),'int'); // neues passwotfeld
$userdb->writeconfig("sys_userlastchange",gmmktime(),'int'); // letzte änderung
// funktion die konfigurationswerte für getconfig in Array einliest
$userdb->configdata();
}
$user_dlg = 'username'; //standardbezeichner
$pw_dlg = 'userpw'; //standardbezeichner
if ($userdb->getconfig("sys_username")<>'') $user_dlg=$userdb->getconfig("sys_username");
if ($userdb->getconfig("sys_userpw")<>'') $pw_dlg=$userdb->getconfig("sys_userpw");
.....
.....
....
// letztendlich nach den üblichen abläufen wird das formular z.b. folgendmaßen ausgegeben
$ret.= '<form method="post" name="login" class="formbox" method="post" action="">
<input type="hidden" name="action" value="login">
Username <input class="formdlg" size="10" type="text" name="'.$user_dlg.'">
Password <input class="formdlg" size="10" type="password" name="'.$pw_dlg.'">
<input type="submit" class="formbtn" value="Login">
</form>';
return $ret; //
...
...
Moderator
[/color]
Kommentar