Grav-plugin-admin: Anmeldeseite anfällig für Brute-Force-Angriffe

Ich würde einfach eine einzelne Fehlermeldung verwenden, die etwa so lautet: Incorrect username or password. Diese Änderungen (einschließlich der Änderung der vergessenen Passwortzeichenfolge) würden es unmöglich machen, Benutzernamen in beiden Formen zu erraten.

Ich würde den Zugriff nicht auf IPs beschränken, aber das Hinzufügen von Captcha als Option ist keine schlechte Idee.

Ich mag die Captcha-Option nicht wirklich, aber wenn sie hinzugefügt werden muss, könnten wir sie wenigstens erst nach ein paar fehlgeschlagenen Versuchen (wie 3 oder so) aktivieren?

Verzögerungen zwischen Anmeldeversuchen – die vorzugsweise mit jedem Versuch bis zu einem bestimmten Limit exponentiell ansteigen – blockieren effektiv Brute-Force-Angriffe. Die Verzögerungen und Grenzen könnten als Parameter eingestellt werden.

Die Funktion „Passwort vergessen“ wurde in der Beta-Version des Login-Plugins geändert. Es dauert jetzt nur E-Mail-Adressen.

Außerdem bearbeitet, um dieselbe Nachricht zu drucken, unabhängig davon, ob die E-Mail existiert oder nicht, in https://github.com/getgrav/grav-plugin-login/commit/3e7c20fd66639123cfb2894d9298d4ccfb861af9

Das Protokollieren fehlgeschlagener Versuche wäre auch schön für fail2ban usw. :)

Wie wäre es mit einer Möglichkeit, die Anzahl fehlerhafter Anmeldeversuche in einem bestimmten Zeitraum zu begrenzen?

Das Login-Plugin hat jetzt einen Sicherheitsabschnitt in seiner Konfiguration, um dies zu steuern: https://github.com/getgrav/grav-plugin-login/commit/590f188189c8453afb5992e7ec385795336ee711

Wäre immer noch schön, sogar die OPTION für ein Captcha zu haben. Auch der Hochwasserschutz scheint überhaupt nicht zu funktionieren.
Grav hindert Sie nie daran, weitere Passwörter einzugeben, selbst wenn die Sicherheitsfunktionen aktiviert sind. Es verlängert auch nicht die Zeit zwischen Anmeldeversuchen.

Mache ich etwas falsch oder ist das Plugin einfach kaputt?

Tatsächlich gilt der Brute-Force-Schutz des Login-Plugins nicht für Admin (mein schlechtes Schreiben des Gegenteils hier oben). In Admin haben Sie die Möglichkeit, Schutz auf Webserver-Ebene hinzuzufügen (z. B. htaccess/htpasswd in Apache) und auch nach IP-Bereich einzuschränken, bis diese Funktion auch in Admin landet.

Ich verstehe. Ja, ich denke, das ist bis dahin das Vernünftigste.
Derzeit scheint dies eine eklatante Sicherheitslücke zu sein, wenn Benutzer nicht zumindest eine Warnung erhalten, dass sie die Admin-Seite sichern sollten.

Außerdem, wie schon angedeutet: eine Warnung bei fehlgeschlagenen Anmeldeversuchen im Dashboard wäre sehr schön.

Ich hoffe auf ein baldiges Update dazu :)

BEARBEITEN: Die .htaccess-Lösung tötet so ziemlich alle CSS auf der Admin-Seite. Was es mehr oder weniger unbrauchbar macht.

Derzeit ist das Beste, was Sie für eine bessere Admin-Sicherheit tun können, die Admin-Seite auszublenden, indem Sie sie wie folgt umbenennen:
https://learn.getgrav.org/admin-panel/faq#custom -admin-url
Ich hoffe sehr, dass bald ein Anmeldeschutz für den Administrator kommt, da dies mich daran hindert, ihn auf einer Unternehmensseite zu verwenden.

Tatsächlich gilt der Brute-Force-Schutz des Login-Plugins nicht für Admin (mein schlechtes Schreiben des Gegenteils hier oben). In Admin haben Sie die Möglichkeit, Schutz auf Webserver-Ebene hinzuzufügen (z. B. htaccess/htpasswd in Apache) und auch nach IP-Bereich einzuschränken, bis diese Funktion auch in Admin landet.

Der Brute-Force-Schutz scheint auf meiner Admin-Anmeldeseite zu funktionieren. Steht auch in den Unterlagen . Ist dieser Kommentar veraltet oder verstehe ich das falsch?

Weiß jemand auch, wie man Grav dazu bringt, mit fail2ban zu arbeiten?

Meine alternative Lösung funktioniert nur, wenn Sie FTP-Zugriff auf alle Ihre Server/Hosting haben.

Sie können die .htaccess-Datei so bearbeiten, dass nur Ihre spezifische IP-Adresse den /admin/-Ordner lesen kann. Alle anderen IP-Adressen (und nachfolgende Bots) können keine Ordnerinhalte laden.

Früher habe ich diese Methode verwendet, um alles außer meiner eigenen IP-Adresse zu verbieten, um zu überprüfen, ob eine erstellte Website funktioniert, bevor ich sie starte. Das war, bevor Sie einen lokalen Webserver betreiben konnten. Vielleicht funktioniert das immer noch für die wenigen Benutzer, die Angst haben und die totale Kontrolle nur über ihre IP wollen.