Einführung des OXID Security Module

Kundenkonten enthalten Adressen, Bestellhistorien und Zahlungsreferenzen - und sind damit ein attraktives Angriffsziel. Deshalb führen wir das OXID Security Module ein: ein Paket von Schutzmaßnahmen, das die Schwachstellen bei Konten und Formularen eines Shops stärkt - von der Passwortqualität über die Bot-Abwehr bis hin zur Zwei-Faktor-Authentifizierung.
Das Modul bündelt drei Funktionsbereiche, die unabhängig voneinander arbeiten. Aktiviere, was dein Shop benötigt, und lasse den Rest ausgeschaltet.
Warum Kontosicherheit wichtig ist
Die meisten Angriffe auf einen Shop sind nicht besonders ausgeklügelt. Sie sind automatisiert: Credential Stuffing gegen das Login-Formular, Bots, die Kontakt- und Newsletter-Formulare ausfüllen, oder schwache Passwörter, die einem Wörterbuchangriff in Sekunden zum Opfer fallen. Dafür braucht es keine Schwachstelle in der Shopsoftware - ausgenutzt wird, dass Formulare öffentlich zugänglich sind und Menschen Passwörter wiederverwenden.
Das Modul setzt genau bei diesen drei Mustern an: Es erhöht den Aufwand für das Knacken schwacher Passwörter, macht automatisierte Formularübermittlungen unattraktiv und setzt einen zweiten Faktor zwischen ein gestohlenes Passwort und das Kundenkonto.
Alles wird an einer Stelle konfiguriert. In der Shopadministration fügt das Modul unter Erweiterungen → Module → OXID Security Module → Einstellungen drei Gruppen hinzu - eine pro Funktionsbereich:

Diese eine Ansicht ist die gesamte Konfigurationsoberfläche. Der oben gezeigte Zustand entspricht dem Zustand direkt nach der Installation: Passwortrichtlinien und Bot-Schutz sind aktiviert, die Zwei-Faktor-Authentifizierung ist deaktiviert.
Passwortrichtlinie
Passwortregeln werden überall dort durchgesetzt, wo ein Kunde ein Passwort festlegt: bei der Registrierung, beim Ändern des Passworts unter „Mein Konto“ und im Änderungsformular am Ende des „Passwort vergessen“-Ablaufs. Da die Prüfungen in der shopinternen Eingabevalidierung liegen, gelten sie auch für das zugrunde liegende Modell - nicht nur für das Formular im Browser.

Standardmäßig ist alles aktiviert, bei einer Mindestlänge von acht Zeichen. Wird eine Regel verletzt, sieht der Kunde alle nicht erfüllten Anforderungen gleichzeitig statt Fehlermeldung für Fehlermeldung. Wichtig, falls dein Shop bereits eine eigene Passwortlänge vorgibt: Der strengere der beiden Werte gewinnt. Konfigurierst du im Modul einen niedrigeren Wert als in den Shop-Einstellungen, gilt weiterhin die Shop-Einstellung. Genau das erklärt auch der Hilfetext hinter dem „?“ neben „Mindestlänge“.
Damit ein starkes Passwort einfach statt lästig ist, ergänzt das Modul die Passwortfelder um drei Funktionen: eine Live-Anzeige der Passwortstärke mit fünf Stufen von sehr schwach bis sehr stark, eine Schaltfläche zum Erzeugen eines starken Passworts und einen Ein-/Ausblenden-Schalter, damit Nutzer überprüfen können, was sie eingegeben haben, statt raten zu müssen.

Captcha- und Honeypot-Schutz
Öffentliche Formulare müssen für Kunden gut nutzbar und für Bots unattraktiv sein. Das Modul bietet dafür zwei voneinander unabhängige Mechanismen.

Das Bild-Captcha zeigt verzerrte Zeichen, die eingegeben werden müssen. Da ein Bild mit Text Menschen ausschließt, die einen Screenreader verwenden, gibt es eine Audio-Alternative: Die Zeichen werden aus vorab aufgezeichneten Audiodateien vorgelesen - Englisch und Deutsch sind enthalten - und mit Hintergrundgeräuschen gemischt. Das Bild-Captcha verwendet die PHP-GD-Erweiterung, die Bestandteil einer Standardinstallation von OXID eShop ist.

Der Honeypot verfolgt den entgegengesetzten Ansatz. Er fügt dem Formular eine Falle hinzu, die ein normaler Besucher weder sieht noch ausfüllt, während automatisierte Absender darauf hereinfallen. Für den Kunden gibt es nichts zu lösen und auf einem Screenshot nichts zu sehen - genau das ist der Zweck. Die Bedienbarkeit wird überhaupt nicht beeinträchtigt. Deshalb lohnt es sich, den Honeypot aktiviert zu lassen, auch wenn du ein Captcha an anderer Stelle für zu hinderlich hältst.
Beide Mechanismen schützen die Formulare, auf die Angreifer tatsächlich zielen: Kontakt, Newsletter, Registrierung, „Passwort vergessen“, Login (auf der Login-Seite und in der Login-Box im Header) sowie Checkout ohne Registrierung. Beide sind standardmäßig aktiviert und können jeweils einzeln ausgeschaltet werden. Ein erzeugtes Captcha bleibt für den konfigurierten Zeitraum gültig, standardmäßig 15 Minuten.
Zwei-Faktor-Authentifizierung
Die Zwei-Faktor-Authentifizierung ergänzt den Login um einen Einmalcode. Nachdem das Passwort akzeptiert wurde, sendet der Shop einen sechsstelligen Code per E-Mail. Erst mit der Eingabe dieses Codes wird die Anmeldung abgeschlossen.

Zwei Hinweise, bevor du sie aktivierst. Erstens ist 2FA standardmäßig deaktiviert - sowohl shopweit als auch pro Kunde. Du aktivierst die Funktion für den Shop; anschließend entscheidet jeder Kunde für das eigene Konto unter „Mein Konto → Sicherheit“. Durch ein Update wird also niemand ausgesperrt. Zweitens schützt die Funktion Logins im Storefront und Logins über die OXAPI. Anmeldungen im Admin-Backend sind derzeit noch nicht abgedeckt.
Der Code ist nur kurz gültig: Er läuft nach der konfigurierten Gültigkeitsdauer ab, standardmäßig nach 300 Sekunden. Ein Kunde, der die E-Mail nicht erhalten hat, kann einen neuen Code anfordern; zwischen zwei Sendungen gilt eine Wartezeit von einer Minute. Auch falsche Codes sind begrenzt: Vier falsche Eingaben werden mit einem erneuten Versuch abgewiesen, die fünfte macht den Code ungültig, sodass ein neuer angefordert werden muss.



Zwei-Faktor-Authentifizierung über OXAPI
Headless-Frontends waren lange ein Grund, 2FA deaktiviert zu lassen - ein zweiter Faktor und eine tokenbasierte API passten nicht zusammen. Jetzt tun sie es.
Bei einem Konto mit aktivierter 2FA liefern die üblichen Login- und Token-Operationen keinen vollständigen Access Token mehr zurück. Stattdessen geben sie einen kurzlebigen Challenge-Token aus, der den laufenden 2FA-Prozess kennzeichnet und keinen Refresh Token enthält. Der Client tauscht diesen anschließend zusammen mit dem Code aus der E-Mail gegen echte Zugangsdaten aus:
mutation { verifyTwoFactorLogin(otp: "123456") { accessToken refreshToken } }
Zwei weitere Mutationen vervollständigen den Ablauf: resendTwoFactorOtp sendet den Code für eine noch offene Challenge erneut, und setTwoFactorAuth(enabled: true|false) ermöglicht einem authentifizierten Kunden, die eigene 2FA-Einstellung umzuschalten - das Headless-Gegenstück zum Schalter unter „Mein Konto“.
Dieser Teil des Moduls baut auf dem GraphQL-Base-Modul von OXID auf. Dessen Code wird automatisch als Composer-Abhängigkeit installiert, sodass nichts separat heruntergeladen werden muss. Du musst es lediglich aktivieren - und auch nur dann, wenn du den API-Ablauf verwenden möchtest. Alles andere im Modul funktioniert ohne dieses Modul.
Code-E-Mail an dein Corporate Design anpassen
Der Einmalcode kommt in einer HTML-E-Mail an, deren Betreff und Inhalt CMS-Inhalte sind und im Admin-Backend pro Sprache bearbeitet werden können - genauso wie andere Shop-E-Mails. Passe den Text an, füge dein Logo hinzu und gleiche die Farben an dein Corporate Design an.

Ist kein CMS-Inhalt vorhanden, sendet der Shop eine integrierte Standard-E-Mail. Jede HTML-E-Mail wird zusätzlich mit einer Plain-Text-Fallback-Version für Clients ausgeliefert, die kein HTML darstellen.

Kompatibilität
Das Modul unterstützt OXID eShop Compilation 7.5 und benötigt PHP 8.3 oder eine spätere Version aus der 8.x-Reihe (getestet bis PHP 8.5).
Installation
Installiere das Modul mit Composer aus dem Stammverzeichnis deines Shops:
composer require oxid-esales/security-module ^4.0.2
Führe anschließend die Datenbankmigrationen aus und aktiviere das Modul:
./vendor/bin/oe-eshop-doctrine_migration migrations:migrate
./vendor/bin/oe-console oe:module:activate oe_security_module
Für die Zwei-Faktor-Authentifizierung über die OXAPI musst du zusätzlich das GraphQL-Base-Modul von OXID aktivieren. Es ist bereits als Abhängigkeit installiert; dieser Befehl schaltet es lediglich ein:
./vendor/bin/oe-console oe:module:activate oe_graphql_base
Ausblick
Das Modul ist darauf ausgelegt, weiterzuwachsen: Der zweite Faktor verwendet einen austauschbaren Notifier. Einmalcodes per E-Mail sind damit die erste Versandmethode und nicht die einzig denkbare. Auch die Captcha-Schicht vereint bereits zwei unabhängige Mechanismen hinter einer gemeinsamen Schnittstelle. Wie es weitergeht, hängt davon ab, worauf Shops in der Praxis stoßen - welche Authentifizierungsmethoden für dich wichtig sind und welche Formulare du zusätzlich geschützt sehen möchtest.
Das Modul befindet sich unter github.com/OXID-eSales/security-module, die Dokumentation unter docs.oxid-esales.com. Wenn du Fragen hast oder auf einen Fall stößt, den das Modul noch nicht abdeckt, freuen wir uns über dein Feedback.
