Zwei-Faktor-Authentifizierung, Passwortrichtlinien und Admin-Sicherheit für PrestaShop

Ihr PrestaShop-Backoffice ist die eine Tür in Ihrem Shop, die alles öffnet: Kundendaten, Bestellhistorie, Zahlungskonfiguration, den Modulmanager, der beliebigen PHP-Code ausführen kann, und einen Datenbankexport, der nur zwei Klicks entfernt ist. Für die meisten Angreifer ist es deutlich effizienter, sich mit gestohlenen Zugangsdaten durch diese Tür einzuloggen, als eine Code-Schwachstelle zu finden, und in sehr vielen Shops wird diese Tür nur von einem einzigen Passwort zugehalten, das der Inhaber auch für sein E-Mail-Konto und für ein vor drei Jahren kompromittiertes Forum verwendet. In diesem Beitrag geht es darum, genau diesen Login zu härten: den zweiten Faktor, die Passwortregeln, die dahinterliegenden Mitarbeiterkonten und die Sitzung, die aktiv bleibt, nachdem Sie den Bildschirm verlassen haben. Es ist die Zugriffskontrollschicht der Sicherheit. Die anderen Schichten, Dateiberechtigungen, Header, Patches, Bot-Filterung, finden Sie in der vollständigen Checkliste zur Sicherheitshärtung, und die ruhigere, nicht technische Übersicht steht im einfach verständlichen Leitfaden für Shopbetreiber.

Überprüft im Juni 2026 anhand des Backoffice-Verhaltens von PrestaShop 1.6, 1.7, 8 und 9 sowie der aktuellen NIST-Empfehlungen zu Passwörtern.

Wo Admin-Logins tatsächlich abfließen

Bevor Sie zu Werkzeugen greifen, lohnt es sich, die konkreten Fehler zu benennen, denn die Lösung ist jeweils eine andere, und sie ist PrestaShop-spezifisch:

• Wiederverwendete Zugangsdaten. Der häufigste Einbruch hat nichts mit PrestaShop-Code zu tun. Ein Admin-Passwort, das bei einem anderen Dienst geleakt wurde, wird von einem automatisierten Tool gegen Ihre AdminLogin-Seite ausprobiert. Das Passwort wurde nie „geknackt“, es wurde nachgeschlagen.
• Geteilte Konten. Ein admin@-Login, den drei Personen verwenden, bedeutet: Das Aktivitätsprotokoll ordnet jede Änderung derselben Zeile zu, und Sie können einer einzelnen Person den Zugriff nicht entziehen, ohne alle anderen ebenfalls auszusperren.
• Zu weitreichende Mitarbeiterrechte. Ein Versandmitarbeiter mit SuperAdmin-Rechten ist ein Loch in SuperAdmin-Größe, wenn sein Laptop per Phishing kompromittiert wird, er hätte von Anfang an keinen Zugriff auf den Modulmanager gebraucht.
• Kein zweiter Faktor. Ein Passwort allein ist ein einzelner Ausfallpunkt. Phishing, ein Keylogger oder ein wiederverwendeter Zugang reicht aus.
• Sitzungen, die nie enden. Ein Backoffice, das auf einem gemeinsam genutzten oder gestohlenen Gerät offen bleibt, ist eine authentifizierte Sitzung, die jeder übernehmen kann.

Alles Folgende ordnet jedem dieser Probleme eine konkrete Gegenmaßnahme zu. Keine davon erfordert Änderungen an Core-Dateien.

Zwei-Faktor-Authentifizierung im PrestaShop-Backoffice

Zwei-Faktor-Authentifizierung teilt die Anmeldung in etwas, das Sie wissen (das Passwort), und etwas, das Sie besitzen (einen Code von Ihrem Telefon). Wird eines davon gestohlen, reicht es trotzdem nicht aus. In PrestaShop führt der übliche Weg zu 2FA im Backoffice über ein vertrauenswürdiges Sicherheitsmodul oder eine externe Zugriffskontrollschicht vor dem Login. Die erste Frage ist also nicht nur, wo Sie klicken, sondern wie Sie den zweiten Faktor überhaupt hinzufügen.

Wie 2FA für das Backoffice tatsächlich hinzugefügt wird

Gehen Sie nicht davon aus, dass der Core Ihrer Version bereits einen fertigen Schalter für Zwei-Faktor-Authentifizierung mitbringt. In der Regel benötigen PrestaShop 1.6, 1.7 und 8 ein vertrauenswürdiges Drittanbieter-Modul oder eine externe Zugriffskontrollschicht, um das Backoffice mit einem zweiten Faktor zu schützen. Behandeln Sie 2FA nur dort als „nativ“, wo Sie es für Ihre exakte Zielversion anhand der offiziellen Dokumentation dieser Version überprüft haben, eine Funktion in einer Nebenversion beweist nicht, dass sie auch in der Version existiert, die Sie betreiben.

Die praktischen Optionen, grob nach Aufwand sortiert:

• Ein vertrauenswürdiges Admin-Sicherheitsmodul, das TOTP hinzufügt (den rotierenden sechsstelligen Code aus einer Authenticator-App wie Google Authenticator, Authy, Microsoft Authenticator, 1Password oder KeePass mit TOTP-Plugin). Das ist der häufigste Weg und der einzige, der einen echten appbasierten zweiten Faktor pro Mitarbeiter bietet.
• Eine externe Zugriffskontrollschicht, ein SSO-/Identity-Proxy oder eine WAF/ein Reverse-Proxy, der einen zweiten Faktor abfragt, bevor die Anfrage überhaupt PrestaShop erreicht. Das schützt die Login-Fläche, ohne den Core anzufassen.
• IP-Freigabelisten (siehe unten) als kompensierende Kontrolle, wenn Sie keine der beiden oben genannten Optionen einsetzen können. Kein echter zweiter Faktor, aber die Angriffsfläche wird drastisch kleiner.

Aktivierung

Welchen Weg Sie auch wählen: Die Einrichtung erfolgt in der Konfiguration des jeweiligen Moduls oder Proxys, nicht auf einer fest vorgegebenen Core-Seite. Folgen Sie daher den Anweisungen des konkret eingesetzten Werkzeugs. Bei einem Authenticator-App-Faktor (TOTP) sieht der Ablauf typischerweise so aus:

• Aktivieren Sie den zweiten Faktor für Ihr eigenes Konto in den Einstellungen des Moduls oder Proxys.
• Scannen Sie den QR-Code mit Ihrer Authenticator-App und geben Sie anschließend den aktuellen Code ein, um zu bestätigen, dass die Uhrzeiten synchron sind. Ein sauber gebautes Werkzeug finalisiert die Einstellung erst nach dieser Bestätigung, damit Sie sich nicht durch ein falsch gescanntes Geheimnis aussperren.
• Speichern Sie die Änderung und testen Sie sie: Melden Sie sich ab und wieder an. Nach dem Passwort sollte der rotierende Code abgefragt werden.

Zwei betriebliche Hinweise ersparen echten Ärger. Erstens hängt TOTP davon ab, dass Telefon- und Serveruhr innerhalb eines kleinen Zeitfensters übereinstimmen; wenn Codes abgelehnt werden, prüfen Sie zuerst die Serverzeit (NTP), bevor Sie von einem defekten Feature ausgehen. Zweitens: Wenn Ihr 2FA-Modul oder Proxy Wiederherstellungs-/Backup-Codes bereitstellt, speichern Sie sie außerhalb des Telefons, als Eintrag im Passwortmanager, nicht auf einem Klebezettel. Wenn es keine solchen Codes gibt, dokumentieren Sie das eigene Wiederherstellungsverfahren im Voraus, denn ein verlorenes oder zurückgesetztes Telefon ohne Ausweichweg kann einen Eingriff auf Datenbankebene erfordern (oft das Leeren der relevanten 2FA-Spalten in Ihrer ps_employee-Zeile), um den Zugriff wiederherzustellen.

Machen Sie es verpflichtend, nicht optional

Ein Mitarbeiter ohne 2FA ist das schwache Glied, an dem die ganze Kette hängt: Ein Angreifer, der in irgendeinem Konto landet, hat einen Fuß in der Tür und kann eskalieren. Das verwendete Werkzeug aktiviert den zweiten Faktor in der Regel pro Person, statt ihn kontoweit zu erzwingen. „Verpflichtend“ ist daher eine Richtlinie, die Sie durchsetzen, indem Sie prüfen, ob jeder aktive Mitarbeiter 2FA eingeschaltet hat. Wenn Sie mehrere Mitarbeiter haben und die Registrierung erzwingen möchten (neue Mitarbeiter können erst arbeiten, nachdem sie 2FA eingerichtet haben), suchen Sie nach einem Modul oder einer Zugriffskontrollschicht, die erzwungene Registrierung unterstützt. Gerade bei 1.6 und frühen 1.7-Versionen führt der Weg daran vorbei meist nur über eine Sperre des Logins per IP.

Eine Passwortrichtlinie nach aktuellem Stand

Das Ziel sind nicht „komplexe“ Passwörter, sondern Passwörter, die nicht erraten, wiederverwendet oder massenhaft durchprobiert werden können. Moderne Empfehlungen (NIST und andere) haben sich von der alten Komplexitäts- und Rotationsfolklore entfernt und setzen auf Länge und Einzigartigkeit.

Die praktische Anweisung für Mitarbeiter ist kurz: Jedes Backoffice-Konto verwendet ein einzigartiges, zufällig generiertes Passwort, das in einem Manager gespeichert ist (Bitwarden, 1Password, KeePass). Eine zufällige Zeichenfolge mit 20 Zeichen ist stärker und im Alltag einfacher als ein „cleveres“, merkbares Passwort, weil niemand es tippen oder behalten muss. Wie PrestaShop dieses Passwort speichert, hängt von Ihrer Version ab: Moderne Versionen verwenden einen starken Passwort-Hashing-Algorithmus (das kostenfaktorbasierte Hashing hinter PrestaShop\PrestaShop\Core\Crypto\Hashing), sodass ein Datenbankleck nicht den Klartext preisgibt, ältere 1.6-Installationen nutzten jedoch ein schwächeres, auf dem Cookie-Key basierendes Verfahren. Wenn Sie noch 1.6 einsetzen, behandeln Sie die gespeicherten Hashes als schwachen Schutz: Planen Sie ein Upgrade oder eine Migration, damit Passwörter mit dem modernen Algorithmus neu gehasht werden, und setzen Sie bis dahin besonders konsequent auf einzigartige, starke Passwörter. In jedem Fall ist das Hashing wertlos, wenn das Passwort admin123 lautet und in einer öffentlichen Wortliste steht.

Eine PrestaShop-spezifische Kontrolle sollten Sie kennen: Der Passwort-zurücksetzen-Ablauf wird über den Konfigurationswert PS_PASSWD_TIME_BACK gedrosselt (Minuten zwischen Zurücksetzen-Anfragen im Backoffice), sodass ein Angreifer Reset-E-Mails nicht beliebig spammen kann. Sie müssen diesen Wert selten anfassen, aber er existiert.

Mitarbeiterkonten: eine Person, ein Login, minimale Rechte

Das ist der Fehler, der jede andere Kontrolle leise untergräbt. Das Berechtigungsmodell von PrestaShop ist tatsächlich leistungsfähig. Das Problem ist fast immer, dass es viel zu offen bleibt.

Ein Konto pro Mensch

Jede Person erhält ihren eigenen Mitarbeiterdatensatz unter Erweiterte Einstellungen → Team → Mitarbeiter. Das bringt Ihnen drei Dinge auf einmal: eine Prüfspur, die zeigt, wer was getan hat (PrestaShop protokolliert Aktionen gegen den handelnden Mitarbeiter), die Möglichkeit, einen ausgeschiedenen Mitarbeiter zu deaktivieren, ohne das Passwort aller anderen zu ändern, und 2FA pro Person. Geteilte Logins verspielen alle drei Vorteile.

Profile und das Prinzip der minimalen Rechte

Berechtigungen werden in PrestaShop nicht pro Mitarbeiter gesetzt, sie hängen an einem Profil (unter Erweiterte Einstellungen → Team → Berechtigungen), und jedem Mitarbeiter wird ein Profil zugewiesen. Erstellen Sie Profile, die echten Rollen entsprechen; die Raster für Anzeigen / Hinzufügen / Bearbeiten / Löschen erledigen den Rest:

Zwei Regeln zählen: Beschränken Sie das SuperAdmin-Profil auf den Inhaber und höchstens eine vertrauenswürdige technische Leitung, und denken Sie daran, dass die Berechtigung Module praktisch Ausführungsrechte für Code bedeutet. Wer ein Modul installieren kann, kann PHP auf Ihrem Server ausführen. Behandeln Sie diese Berechtigung daher als das Kronjuwel, das sie ist, nicht als bequeme Kleinigkeit, die man nebenbei vergibt.

Die Login-Fläche selbst absichern

Zwei Faktoren schützen die Zugangsdaten; diese Maßnahmen schützen die Tür, die sie öffnen.

Den Namen des Admin-Ordners zufällig halten

PrestaShop installiert das Backoffice bewusst in ein zufällig benanntes Verzeichnis (etwa /admin47ab9c/), damit Bots es nicht durch Raten von /admin oder /backoffice finden. Lassen Sie diesen Namen zufällig. Wenn Ihr Ordner bei einer Migration in etwas Vorhersehbares umbenannt wurde, benennen Sie den Ordner auf der Festplatte wieder um; PrestaShop erkennt den neuen Pfad automatisch. Verschleierung ist für sich allein keine Sicherheitskontrolle, aber sie nimmt Sie aus dem Dauerfeuer automatisierter Scans, die offensichtliche Pfade abklopfen.

Fehlgeschlagene Logins drosseln und beobachten

Brute-Force- und Credential-Stuffing-Tools leben davon, schnell Tausende Versuche absetzen zu können. Zwei Verteidigungslinien helfen: An der Anwendungskante stellen Sie eine Prüfung vor das Login-Formular, damit automatisierte Werkzeuge ins Stocken geraten, behandelt in reCAPTCHA für PrestaShop. An der Netzwerkkante beschränken Sie, wer den Login überhaupt erreichen kann. Wenn sich Ihr Team von einer festen Büro-IP oder über ein VPN anmeldet, blockiert eine .htaccess- oder Firewall-Freigabeliste für das Admin-Verzeichnis jede andere Quelle vollständig, gültiges Passwort hin oder her, diese und weitere serverseitige Regeln finden Sie in PrestaShop .htaccess-Sicherheits- und Performance-Regeln. Prüfen Sie in jedem Fall das Muster fehlgeschlagener Logins: Eine Welle von Fehlversuchen von einer IP gegen einen Mitarbeiter ist ein laufender Angriff.

# Apache 2.4, inside the randomized back-office directory
Require ip 203.0.113.10
Require ip 198.51.100.0/24

Der Security Revolution-Bildschirm für blockierte Versuche listet Einträge nach Typ, Grund, IP-Adresse und Datum auf und meldet keine blockierten Versuche in den letzten 24 Stunden.

Sitzungssicherheit: der Teil, den fast alle vergessen

Sie können alles oben Genannte richtig machen und einem Angreifer trotzdem eine authentifizierte Sitzung überlassen, wenn das Backoffice auf einem unbeaufsichtigten Gerät geöffnet und angemeldet bleibt. Drei Kontrollen schließen diese Lücke:

• Inaktivitäts-Timeout. PrestaShop lässt Backoffice-Sitzungen anhand der Einstellung PS_COOKIE_LIFETIME_BO altern (Lebensdauer des Admin-Cookies). Halten Sie sie kurz genug, damit ein verlassener Bildschirm sich selbst abmeldet, kurz bei gemeinsam genutzten Arbeitsplätzen, länger nur dort, wo das Gerät wirklich privat ist.
• Admin nur über HTTPS. Das Backoffice muss über HTTPS erreichbar sein, damit das Sitzungscookie in einem Café- oder Hotelnetz nicht mitgelesen werden kann. Wenn Ihr Shop noch nicht vollständig auf HTTPS läuft, beheben Sie das zuerst. Die Anleitung dazu ist SSL und HTTPS in PrestaShop einrichten.
• Sichere HttpOnly-Cookies. Sobald die gesamte Website HTTPS nutzt, sollte das Admin-Sitzungscookie die Flags Secure und HttpOnly tragen, damit es nie im Klartext gesendet und nicht von JavaScript gelesen werden kann. Ein gestohlenes Cookie umgeht 2FA, also ist das nicht optional.

Sie können die aktuelle Lebensdauer des Backoffice-Cookies direkt in der Datenbank prüfen; der Wert ist in Tagen gespeichert:

SELECT name, value
FROM ps_configuration
WHERE name IN ('PS_COOKIE_LIFETIME_BO', 'PS_PASSWD_TIME_BACK');

Überwachen Sie das Backoffice, nicht nur das Frontoffice

PrestaShop protokolliert einige Backoffice-Ereignisse und Fehler, und dieses Protokoll ist ein nützliches Frühwarnsignal, behandeln Sie es aber als Teilaufzeichnung, nicht als vollständige Prüfspur oder SIEM. Das interne Protokoll zeigt Dinge wie ein neues Mitarbeiterkonto, das Sie nicht erstellt haben, eine plötzliche Berechtigungsänderung oder eine unerwartete Änderung an der Zahlungskonfiguration. Allein liefert es Ihnen jedoch keine verlässliche Anmeldung-nach-IP- oder länderbezogene Überwachung: „ein Login um 04:00 Uhr aus einem Land, in dem Sie nicht tätig sind“ erkennen Sie normalerweise nur durch Korrelation von Serverzugriffsprotokollen, einem dedizierten Sicherheitsmodul oder den Protokollen Ihrer WAF/Ihres Reverse-Proxys, in denen die Quell-IP erfasst wird. Gewöhnen Sie sich an, das interne Protokoll zu überfliegen, mindestens monatlich, bei Mitarbeiterwechseln wöchentlich, und kombinieren Sie es mit dem serverseitigen Protokoll, das die Authentifizierungsquelle zeigt. Wenn Sie bereits vermuten, dass Sie die Warnphase hinter sich haben und ein aktiver Einbruch läuft, hören Sie auf, Härtungstipps zu lesen, und folgen Sie dem Incident-Playbook in Reaktion auf Datenlecks: Was tun, wenn Ihr Shop gehackt wurde.

Wenn Sie kein 2FA-Modul einsetzen können

Viele Shops stecken in einer eingefrorenen Umgebung fest, eine alte Version, die wegen eines Legacy-Themes, eines Legacy-Moduls oder einer PHP-Version nicht aktualisiert werden kann, ohne etwas zu brechen, und dort ist das Hinzufügen eines Sicherheitsmoduls oft mühsam. Sie haben trotzdem Optionen: Ein vertrauenswürdiges Modul kann den zweiten Faktor dort ergänzen, wo es passt, eine externe Zugriffskontrollschicht kann vor dem Login sitzen, IP-Freigabelisten können das Backoffice abschirmen, und alle übrigen Hinweise zur Zugriffskontrolle gelten unverändert. Die breitere Strategie zur Härtung eines Shops, den Sie derzeit wirklich nicht bewegen können (virtuelles Patching und kompensierende Kontrollen), ist ein eigenes Thema in erweiterte PrestaShop-Härtung für Shops, die Sie noch nicht upgraden können.

Admin-Absicherung in 10 Minuten, in der richtigen Reihenfolge

• Aktivieren Sie 2FA sofort für Ihr eigenes SuperAdmin-Konto über Ihr Sicherheitsmodul oder Ihre Zugriffskontrollschicht, und bestätigen Sie, dass eine Wiederherstellungsoption außerhalb des Geräts gespeichert ist.
• Listen Sie jeden aktiven Mitarbeiter auf. Deaktivieren Sie geteilte Logins; geben Sie jedem Menschen ein eigenes Konto.
• Öffnen Sie Berechtigungen und stufen Sie alle herab, die keinen SuperAdmin-Zugriff benötigen. Prüfen Sie, dass nur 1–2 Personen ihn besitzen und dass der Zugriff auf Module eng begrenzt ist.
• Führen Sie jede verbleibende Person durch die Aktivierung ihrer eigenen 2FA.
• Bestätigen Sie, dass jedes Admin-Passwort einzigartig und vom Passwortmanager generiert ist, rotieren Sie alle, bei denen das nicht zutrifft.
• Prüfen Sie, ob der Admin-Ordnername noch zufällig ist und nicht /admin lautet.
• Verkürzen Sie die Lebensdauer des Backoffice-Cookies, damit inaktive Sitzungen abgemeldet werden.
• Bestätigen Sie, dass der Admin-Bereich nur über HTTPS erreichbar ist und das Sitzungscookie Secure + HttpOnly ist.
• Lesen Sie die Admin-Protokolle eines Monats. Merken Sie sich, wie „normal“ aussieht, damit Abweichungen beim nächsten Mal auffallen.

Häufig gestellte Fragen

Hat PrestaShop eine eingebaute Zwei-Faktor-Authentifizierung für das Backoffice?

Gehen Sie für Ihre Version nicht davon aus. PrestaShop 1.6, 1.7 und 8 benötigen im Allgemeinen ein vertrauenswürdiges Admin-Sicherheitsmodul oder eine externe Zugriffskontrollschicht (einen SSO-/Identity-Proxy oder eine WAF vor dem Login), um das Backoffice mit einem zweiten Faktor zu schützen. Behandeln Sie 2FA nur dann als nativ, wenn Sie es anhand der offiziellen Dokumentation für Ihr exaktes Release überprüft haben, eine Funktion in einer Nebenversion beweist nicht, dass sie auch in der Version existiert, die Sie betreiben.

Was passiert, wenn ich das Telefon mit meiner Authenticator-App verliere?

Wenn Ihr 2FA-Werkzeug Wiederherstellungs- oder Backup-Codes anbietet, speichern Sie sie außerhalb des Telefons (als Passwortmanager-Eintrag) und verwenden einen davon, um wieder hineinzukommen. Wenn es keine solchen Codes anbietet, greifen Sie auf das dokumentierte Wiederherstellungsverfahren zurück. In vielen Setups bedeutet das einen Eingriff auf Datenbankebene, das Leeren der relevanten 2FA-Spalten in Ihrer ps_employee-Zeile, um den zweiten Faktor für dieses Konto zu deaktivieren, damit Sie sich anmelden und 2FA erneut einrichten können. Deshalb klären Sie den Wiederherstellungsweg, bevor Sie 2FA einschalten, nicht danach.

Sollte ich erzwingen, dass meine Admin-Passwörter alle 90 Tage ablaufen?

Nein. Aktuelle Empfehlungen (NIST und andere) haben planmäßige Rotation verworfen, weil sie Menschen zu Summer2024! → Summer2025! drängt, und das ist schwächer, nicht stärker. Ändern Sie ein Passwort nur bei Verdacht auf Kompromittierung. Stecken Sie die Energie stattdessen in Länge und Einzigartigkeit: eine zufällig generierte, nie wiederverwendete Zeichenfolge mit 16+ Zeichen aus einem Passwortmanager, eine pro Konto.

Lohnt es sich wirklich, den Admin-Ordner umzubenennen?

Es lohnt sich, ihn zufällig zu halten; es lohnt sich nicht, sich daran festzubeißen. PrestaShop installiert das Backoffice bereits in ein zufällig benanntes Verzeichnis, damit Bots es nicht durch Raten von /admin oder /backoffice finden. Wenn eine Migration Ihren Ordner vorhersehbar gemacht hat, benennen Sie ihn auf der Festplatte um; PrestaShop erkennt den neuen Pfad. Das ist Verschleierung, keine Sicherheitskontrolle, sie nimmt Sie aus dem Dauerfeuer automatisierter Scans, rechtfertigt sich aber nur zusammen mit 2FA, starken Passwörtern und Login-Drosselung.

Wie stoppe ich Brute-Force- und Credential-Stuffing-Angriffe auf den Login?

Arbeiten Sie auf zwei Ebenen. An der Anwendungskante stellen Sie eine Prüfung vor das Login-Formular (reCAPTCHA), damit automatisierte Werkzeuge ins Stocken geraten. An der Netzwerkkante beschränken Sie, wer den Login überhaupt erreichen kann, wenn sich Ihr Team von einer festen Büro-IP oder über ein VPN anmeldet, weist eine .htaccess- oder Firewall-Freigabeliste im Admin-Verzeichnis jede andere Quelle ab, gültiges Passwort hin oder her. Beides ersetzt 2FA nicht; 2FA rettet Sie, wenn ein echtes Passwort abfließt.

Was bringt Ihnen das konkret?

Wenn Sie die Liste abarbeiten, ändert sich die Wirtschaftlichkeit eines Angriffs auf Ihren Shop. Credential-Stuffing scheitert am zweiten Faktor. Ein per Phishing erbeutetes Passwort ist ohne das Telefon wertlos. Ein kompromittiertes Konto eines Versandmitarbeiters erreicht den Modulmanager nicht. Ein zurückgelassener Laptop meldet sich selbst ab. Nichts davon erfordert einen Entwickler, eine Core-Änderung oder ein Upgrade, das Sie sich nicht leisten können. Es sind Backoffice-Konfiguration und ein Passwortmanager. Wir entwickeln Sicherheitsmodule und betreiben selbst Shops; deshalb ist die ehrliche Einordnung diese: Im Backoffice wird aus einem unangenehmen Vorfall ein katastrophaler Einbruch, und Zugriffskontrolle ist die günstigste Stunde mit der größten Wirkung, die Sie dafür investieren können. Wenn Sie bereit sind, die Schichten unterhalb des Logins zu härten (Dateien, Header, Patches, Bot-Traffic), ist die vollständige Härtungs-Checkliste die Karte für den Rest.