PrestaWard Authenticator

Was es leistet

Ein gestohlenes Passwort sollte nicht ausreichen, um Zugriff auf das Backoffice zu erhalten. Das Modul fügt einen zweiten Faktor hinzu, ohne das Geheimnis an APIs von Drittanbietern zu übermitteln.

So funktioniert es

Der zweite Faktor sind Einmalcodes (TOTP), die von einer Authentifizierungs-App auf dem Mobiltelefon generiert werden. Wenn Sie dies für ein Profil zulassen, können die Mitarbeiter dieses Profils stattdessen achtstellige Codes verwenden, die per E-Mail versendet werden – eine weniger sichere Methode, da jeder, der Zugriff auf den Posteingang hat, sich anmelden kann; das Dashboard und die Mitarbeiterseite weisen darauf hin. Diese Funktion ist standardmäßig deaktiviert. Die Unterstützung für Passkeys ist enthalten, in dieser Version jedoch standardmäßig deaktiviert.
Jeder Mitarbeiter richtet seinen eigenen Sicherheitsfaktor unter „Meine Authentifizierung“ ein, mithilfe eines QR-Codes, der im Shop selbst generiert wird. Die erstmalige Registrierung erfolgt schrittweise: Scannen des QR-Codes, Eingabe des Codes und eine Abschlussseite mit den Wiederherstellungscodes. Die Schaltfläche zum Weiterleiten zum Backoffice wird erst aktiviert, wenn der Mitarbeiter diese Codes heruntergeladen, kopiert oder ausgedruckt hat.
Die Installation erfolgt im Modus „Deaktiviert“. Im Modus „Nur Audit“ werden Zugriffe protokolliert, ohne dass jemand gesperrt wird, und im Modus „Erzwingen“ wird der zweite Faktor verlangt. Ein Mitarbeiter, der den zweiten Faktor noch nicht eingerichtet hat, bestätigt sein Passwort und kann bis zum Abschluss der Einrichtung nur „Meine Authentifizierung“ öffnen.
Die Richtlinie wird für den gesamten Shop festgelegt und kann je nach Profil und Shop angepasst werden. Bei Shops mit mehreren Shops gilt die strengste Richtlinie.
Bevor Sie die Umstellung erzwingen, können Sie einem Profil eine Übergangsfrist von 3 bis 14 Tagen einräumen. Mitarbeiter, die sich noch nicht registriert haben, melden sich wie gewohnt an und sehen auf jeder Seite des Backoffice einen Hinweis mit dem Datum, ab dem die Zwei-Faktor-Authentifizierung verpflichtend wird; außerdem zeigt das Dashboard an, wie viele Mitarbeiter sich noch registrieren müssen. Nach Ablauf der Frist wird das Erzwingen wie gewohnt angewendet.
Vertrauenswürdige Geräte (standardmäßig 30 Tage) verhindern, dass bei jedem Zugriff von einem bekannten Gerät aus der Code eingefordert wird. Jeder Mitarbeiter kann diese einzeln widerrufen.
Die Anzahl der Passwort- und Code-Versuche ist begrenzt (standardmäßig 5 Code-Versuche alle 5 Minuten und eine Sperre von 15 Minuten). Ein TOTP-Code kann nicht wiederverwendet werden. Wenn PrestaWard Captcha den Zugriff auf das Backoffice schützt und die Anfrage ablehnt, zählt dieser Fehler nur für das Limit pro IP-Adresse und nicht für die Sperrung des angegriffenen Administratorkontos: Ein Bot ohne Token kann ein Konto mit nur wenigen Anfragen nicht mehr sperren.
In regelmäßigen Abständen wird die MFA-Richtlinie mit der Signatur des Dienstes PrestaWard Integrity erneuert. An Integrity werden ausschließlich technische Daten der Installation übermittelt, niemals TOTP-Geheimnisse, Wiederherstellungscodes oder Daten der Mitarbeiter.

Wenn ein Mitarbeiter sein Mobiltelefon verliert

Persönliche Wiederherstellungscodes: Jeder Mitarbeiter erhält standardmäßig 10 Einmalcodes bei der Einrichtung seines Sicherheitsfaktors und muss diese außerhalb des Shops aufbewahren.
Optionale Wiederherstellung per E-Mail: Im zweiten Schritt kann der Mitarbeiter einen Code per E-Mail anfordern. Diese Funktion ist standardmäßig deaktiviert und wird von einem Superadministrator aktiviert.
Zurücksetzen über die MFA-Verwaltung ohne Konsolenzugriff: Ein Superadministrator kann den zweiten Faktor eines anderen Mitarbeiters zurücksetzen. Es verlangt das Passwort des Administrators; diese Funktion kann nicht für sich selbst verwendet werden und löscht den Authentifikator, die Wiederherstellungscodes, die vertrauenswürdigen Geräte sowie die offenen Sitzungen des Mitarbeiters, der sich bei seinem nächsten Zugriff erneut registrieren muss. Andere Profile mit Bearbeitungsrechten in der MFA-Verwaltung können nur Mitarbeiter mit geringeren Berechtigungen zurücksetzen, und nur ein Superadministrator kann einen anderen Superadministrator zurücksetzen. Jede Zurücksetzung sowie jeder abgelehnte Versuch wird im Zugriffsprotokoll festgehalten.
Notfallzugriff über die Konsole als letztes Mittel: Erfordert Zugriff auf den Server und den einmalig verwendbaren Notfallschlüssel, der im MFA-Verwaltungsbereich generiert wird. Ermöglicht es, die MFA-Faktoren eines Mitarbeiters zurückzusetzen oder die MFA-Pflicht für eine Stunde auszusetzen, falls niemand Zugang erhält. Der Vorgang wird protokolliert, und der Schlüssel kann nicht wiederverwendet werden.

Anforderungen

PrestaShop 1.7, 8 oder 9 sowie die von Ihrer PrestaShop-Version geforderte PHP-Version (PHP 7.1 oder höher für PrestaShop 1.7).
Eine TOTP-Authentifizierungs-App auf dem Mobiltelefon jedes Mitarbeiters, mit Ausnahme der Profile, für die Sie den Code per E-Mail als zweiten Faktor zulassen.
Für die Wiederherstellung per E-Mail, Codes per E-Mail und Benachrichtigungen muss der Shop E-Mails versenden können.
Für die Zugangsschlüssel (standardmäßig deaktiviert) ist eine HTTPS-Adresse im Backoffice erforderlich.
Die globale Richtlinie, das Mitarbeiterverzeichnis, die E-Mails und die Protokolle stehen ausschließlich Superadministratoren zur Verfügung. Die übrigen Mitarbeiter verwalten ausschließlich ihre eigenen Daten.
Bedienoberfläche und Meldungen in neun Sprachen.

Bekannte Einschränkungen

Der Dateimanager des PrestaShop-Kerns (Ordner filemanager im Administrationsbereich) führt keine Module aus, sodass er den zweiten Faktor nicht verlangen kann. Bei obligatorischer MFA entziehen Sie Profilen, die ihn nicht benötigen, diesen Zugriff oder sperren Sie ihn auf dem Webserver.
Der Schutz der Symfony-Seiten im Backoffice erfordert PrestaShop 1.7.7 oder höher. In früheren Versionen werden nur die klassischen Seiten geschützt.
Der Webservice und die Admin-API von PrestaShop verwenden eigene Schlüssel und liegen außerhalb des Geltungsbereichs des Moduls.

Was es nicht leistet

Es schützt nicht den Zugriff Ihrer Kunden auf den Shop, sondern lediglich den Bereich des Backoffice.
Es werden keine TOTP-Geheimnisse, Wiederherstellungscodes oder Daten der Mitarbeiter an externe Dienste übermittelt.
Die Fußzeile der E-Mails des Moduls enthält keine Links, Kontaktadressen oder Bilder, die außerhalb Ihres Shops gehostet werden: Das Logo von GO ON Agency ist eine Datei des Moduls selbst, die von Ihrem Shop aus bereitgestellt wird.

Kompatibilität geprüft

Die Version 0.0.16 hat am 15. Oktober 2026 die Labortests unter PrestaShop 1.7, 8 und 9 bestanden, sowohl bei einer Neuinstallation als auch bei einem Update von Version 0.0.15. Die Version 0.0.15 hat am 13. Oktober 2026 die Labortests unter PrestaShop 1.7, 8 und 9 bestanden: bei einer Neuinstallation sowie bei einem Update von Version 0.0.14 und von Version 0.0.6, wobei die Konfiguration, die TOTP-Geheimnisse und die vertrauenswürdigen Geräte beibehalten wurden und keine schwerwiegenden Fehler in den Protokollen auftraten. Die Version 0.0.13 wurde unter PrestaShop 1.7.8.11 mit PHP 7.4, PrestaShop 8.2.7 mit PHP 8.1 und PrestaShop 9.1.4 mit PHP 8.5 getestet.

Hauptfunktionen

TOTP-Registrierung mit aktuellem Passwort und lokal generiertem QR-Code.
Mit AES-256-GCM verschlüsselte Geheimnisse und einmalig verwendbare HMAC-Wiederherstellungscodes.
Replay-Schutz für TOTP durch atomares Hochzählen des Zählers.
Schutz vor Brute-Force-Angriffen auf Passwörter sowie MFA (Multi-Faktor-Authentifizierung) anhand von IP-Adresse und Identität, mit konfigurierbaren Grenzwerten und Sperren.
IPv4, IPv6, CIDR, vertrauenswürdige Proxys und Netzwerklisten, wobei eine sichere Liste die MFA nicht umgehen darf.
Vertrauenswürdige Geräte mit 256-Bit-Tokens, Hash, Ablaufdatum und Widerrufsmöglichkeit.
Selbstbedienungsfunktion für einzelne Mitarbeiter, getrennt von der globalen Verwaltung.
MFA-Richtlinien nach Profil und Shop, wobei bei mehreren Shops die strengste Richtlinie gilt.
Konfigurierbare Ungültigkeitserklärung von Sitzungen und Geräten nach einer Passwortänderung.
Wiederherstellung des Zugriffs über persönliche Codes, optionalen Code per E-Mail und, als letztes Mittel, Notfallzugriff über die Konsole mit einem Einmal-Schlüssel.
Optionaler Code per E-Mail während einer MFA-Authentifizierung, mit Ablaufdatum, HMAC und Versandbeschränkungen.
Übergangsfrist pro Profil vor der erzwungenen Einführung des zweiten Faktors, mit Benachrichtigung im Backoffice und Nachverfolgung der noch ausstehenden Mitarbeiter.
Zurücksetzen des zweiten Faktors eines Mitarbeiters über die MFA-Verwaltung unter Verwendung des Administratorpassworts und Protokollierung jedes Versuchs.
Aktuelle Aktivitäten im Dashboard: Zusammenfassung der Zugriffsprotokolle der letzten 30 Tage in einfachen Sätzen (Zugriffe von einer neuen IP-Adresse oder einem neuen Browser, wiederholte fehlgeschlagene Anmeldeversuche, Sperrungen, verwendete Wiederherstellungscodes und Zurücksetzungen). Verwenden Sie ausschließlich Ihr eigenes Protokoll, ohne Geolokalisierung oder externe Dienste, und zeigen Sie keine vollständigen Adressen an: E-Mail-Adressen werden maskiert, und IP-Adressen behalten lediglich ihr /24-Netzwerk (IPv4) oder ihre ersten drei Gruppen (IPv6) bei. Das Zugriffsprotokoll mit Integritätszeichenfolge bewahrt die exakten Werte.
Geführte Registrierung des ersten Faktors mit einer abschließenden Seite mit Wiederherstellungscodes, auf der diese heruntergeladen, kopiert oder ausgedruckt werden müssen, bevor fortgefahren werden kann.
Codes per E-Mail als optionaler zweiter Faktor, ausschließlich für von Ihnen zugelassene Profile: achtstellig, ausschließlich als Hash mit Schlüssel gespeichert, fünf Minuten gültig, einmalig verwendbar und mit einer Begrenzung der Versandanzahl. Die Mitarbeiter bestätigen ihre E-Mail-Adresse einmalig. „Nur Wiederherstellung“ funktioniert wie bisher.
Meine Authentifizierung als übersichtliche Zusammenfassung: eine Statusleiste, eine Karte pro Methode mit einer einzigen einklappbaren Aktion, die Wiederherstellungscodes, die vertrauenswürdigen Geräte und am Ende ein einklappbarer „Gefahrenbereich“. Die Deaktivierung der MFA erläutert, was entfernt wird: Das Passwort, ein aktueller Code und eine explizite Bestätigung bleiben erhalten, und die Maßnahme wirkt sich nur auf den angemeldeten Mitarbeiter aus.
Statistiken der letzten 30 Tage mit täglichen Trends (Zugriffe, verifizierte Faktoren des zweiten Faktors, Passwort- und Fehler bei der Authentifizierung mit dem zweiten Faktor, Sperrungen, genutzte Wiederherstellungen und neue vertrauenswürdige Geräte), die Abdeckung der Registrierung nach Profil sowie die verwendeten Methoden. Es werden ausschließlich Zahlen aus Ihrem eigenen Zugriffsprotokoll ausgewertet: IP-Adressen und E-Mail-Adressen werden nicht angezeigt.
Ein Bot, der das PrestaWard Captcha nicht überwindet, kann das Konto eines Administrators nicht mehr sperren: Dieser Fehler wird lediglich auf das IP-Limit angerechnet.
Synchronisierung mit Integrity beim Öffnen des Panels mittels einer Hintergrundanfrage, die die Seite nicht verlangsamt.
Dashboard mit fünf Registerkarten („Übersicht“, „Mitarbeiter und Registrierung“, „Richtlinien“, „Statistiken und Aktivitätsprotokoll“ sowie „Einstellungen“) sowie einer Registerkarte „Support“, die stets an letzter Stelle steht: Die „Übersicht“ zeigt den Modus, den Umfang der Registrierung, Fehler und Ausfälle der letzten 24 Stunden sowie höchstens eine Warnmeldung an; jede Registerkarte enthält ausschließlich ihre eigenen Einstellungen.
HMAC-verknüpfte Protokolle mit Aufbewahrungsfrist, signiertem Export, Filtern und Paginierung.
Entsprechende E-Mail-Benachrichtigungen in PrestaShop 1.7, 8 und 9, mit dem Logo Ihres Shops in der Kopfzeile und in der Fußzeile dem Logo der GO ON Agency mit dem Vermerk „PrestaWard by GO ON Agency“.
Gemeinsame Filterleiste im Zugriffsprotokoll: Die Auswahlfelder sind in einem Raster gleicher Breite angeordnet, das Suchfeld und die Schaltfläche „Filtern“ befinden sich in derselben Zeile, und die sekundären Aktionen sind rechtsbündig ausgerichtet.
Einheitliches Erscheinungsbild des Dashboards in allen vier PrestaWard-Modulen: Abschnittsüberschriften, Formularfelder mit neutralen Rahmen und einheitliche ausklappbare Blöcke, einzeilige Statistiken sowie ein größeres Logo der GO ON Agency in der Kopfzeile. Die Hauptschaltfläche erhält nun eine einheitliche Farbe der Marke ohne Farbverlauf.
Mindestquarantänezeit ohne Navigationsmöglichkeit bis zum Abschluss der MFA.
Installationsprotokoll und MFA-Richtlinie, signiert mit Integrity, ohne Übertragung von TOTP-Geheimnissen, Wiederherstellungscodes oder Daten der Mitarbeiter. Auf dem Modulbildschirm aktualisiert die Schaltfläche „Synchronisieren“ die Verbindung.
Support-Panel der GO ON Agency mit einem herunterladbaren Diagnosebericht. Dieser wird von einem Mitarbeiter mit Bearbeitungsberechtigung heruntergeladen, wobei ein Shop ausgewählt wird. Er enthält lediglich Versionen, Status und Zählerstände, jedoch keine Pfade oder Anmeldedaten und wird nicht automatisch versendet.

Sichere Nutzung

Der Anfangsmodus ist „Deaktiviert“. Jeder Mitarbeiter richtet sein Konto unter „Meine Authentifizierung“ ein; der Administrator überprüft die Bereitstellung, wechselt zunächst in den Modus „Nur Audit“ und aktiviert „Erzwingen“, sobald die Wiederherstellung überprüft wurde.

Änderungsprotokoll

0.0.16

Das Dashboard ist in Registerkarten unterteilt: „Übersicht“ (Modus, Registrierungsabdeckung, Fehler und Abstürze der letzten 24 Stunden sowie maximal eine Warnzeile), „Mitarbeiter und Registrierung“, „Richtlinien“, „Statistiken und Aktivitätsprotokoll“ sowie „Einstellungen“. Das Support-Dashboard verfügt über eine eigene Registerkarte „Support“, die immer an letzter Stelle steht; der Status von Integrity wird unterhalb aller Registerkarten angezeigt, und in der Kopfzeile ist das Logo von GO ON Agency zu sehen. Jede Registerkarte speichert nur ihre eigenen Einstellungen.
Stellt sicher, dass eine Anfrage, die das PrestaWard Captcha nicht besteht, zur Sperrung des angegriffenen Administratorkontos zählt. Zuvor wurden Anfragen ohne Captcha-Token als Passwortfehler gewertet, sodass ein Bot ein Konto bereits mit wenigen Anfragen sperren konnte. Wenn PrestaWard Captcha den Zugriff auf das Backoffice schützt und die Anfrage ablehnt, zählt der Fehler nur für das IP-Limit. Ohne PrestaWard Captcha (oder im Modus der Beobachtung) ändert sich nichts.
Neu: Codes per E-Mail als optionaler zweiter Faktor. In den E-Mail-Einstellungen wählen Sie „Zweiter Faktor (schwächer)“ aus und aktivieren diese Option anschließend für jedes Mitarbeiterprofil. Mitarbeiter mit diesen Profilen bestätigen ihre E-Mail-Adresse einmalig mit einem per E-Mail versendeten Code und können sich anschließend mit E-Mail-Codes anmelden: achtstellige Codes, die ausschließlich als verschlüsselter Hash gespeichert werden, fünf Minuten lang gültig sind, nur einmal verwendet werden können und einer Versandbeschränkung unterliegen – genau wie die aktuellen Wiederherstellungscodes. In den Einstellungen und auf der Seite der Mitarbeiter wird darauf hingewiesen, dass diese Methode weniger sicher ist als eine Authentifizierungs-App: Wer das Postfach lesen kann, erhält Zugriff. „Nur Wiederherstellung“ funktioniert genau wie bisher.
Neu: Geführte Registrierung des ersten Faktors. Wenn sich ein Mitarbeiter registrieren muss (oder sich in der Übergangsfrist befindet), führt ihn „Meine Authentifizierung“ durch den Vorgang: QR-Code scannen, Code eingeben und eine abschließende Erfolgsmeldung mit den Wiederherstellungscodes (herunterladen, kopieren oder ausdrucken). Die Schaltfläche „Weiter zum Backoffice“ funktioniert erst, nachdem die Codes heruntergeladen, kopiert oder ausgedruckt wurden. Zugangsschlüssel und Codes per E-Mail werden, sofern sie für den Mitarbeiter aktiviert sind, unter „Weitere Möglichkeiten, Ihr Konto zu schützen“ angezeigt.
Meine Authentifizierung wird zu einer übersichtlichen Zusammenfassung: ein Statusbalken (Status, Methoden, Wiederherstellungscodes und vertrauenswürdige Geräte), eine kompakte Karte pro Methode (Authentifizierungs-App, Zugangsschlüssel und Codes per E-Mail) mit einer einzigen einklappbaren Aktion, eine Karte mit Wiederherstellungscodes, die eingeklappten vertrauenswürdigen Geräte und schließlich eine eingeklappte „Gefahrenzone“. Die Deaktivierung der MFA erklärt nun, was entfernt wird und was anschließend geschieht, und behält eine rote Schaltfläche, das Passwort, einen aktuellen Code sowie eine ausdrückliche Bestätigung bei. Es wirkt weiterhin ausschließlich auf den angemeldeten Mitarbeiter und wird im Zugriffsprotokoll mit Integritätskette festgehalten.
Datenschutz: Unter „Aktuelle Aktivitäten“ werden keine vollständigen Adressen mehr angezeigt. E-Mail-Adressen erscheinen als j***@d***.com, und IP-Adressen behalten nur ihr /24-Netz (IPv4) oder ihre ersten drei Gruppen (IPv6) bei, genau wie in den Statistiken. Das Zugriffsprotokoll mit Integritätszeichenfolge behält die exakten Werte bei und bleibt die maßgebliche Quelle.
Neu: Statistiken. Ein neuer Abschnitt zeigt die letzten 30 Tage als kleine tägliche Trends an (Zugriffe, verifizierte Authentifizierungen mit zweitem Faktor, Passwortfehler, Fehler bei Authentifizierungen mit zweitem Faktor, Sperrungen, genutzte Wiederherstellungen und neue vertrauenswürdige Geräte), zusammen mit der Erfassungsquote der Mitarbeiter, die sich registrieren müssen (nach Profil), sowie den verwendeten Methoden. Es werden ausschließlich Zahlen aus Ihrem eigenen Zugriffsprotokoll ausgewertet; IP-Adressen oder E-Mail-Adressen werden nicht angezeigt.
Passkeys (Touch ID, Face ID, Windows Hello und Sicherheitsschlüssel) als zweiter Faktor für die Authentifizierung: Der Code ist enthalten, diese Funktionen sind jedoch standardmäßig deaktiviert und erfordern eine HTTPS-Adresse im Backoffice. Ein Administrator aktiviert sie in den Einstellungen, und jeder Mitarbeiter fügt sie unter „Meine Authentifizierung“ hinzu, wobei er sein Passwort und den aktuellen Code eingeben muss.
Behebt das Problem, dass die Verbindung zu Integrity im Backoffice unter „Alle Shops“ beeinträchtigt war: Die Identität der Installation wurde nur für den ersten Shop gespeichert; die Synchronisierung im Hintergrund las sie als leer aus, es kam zu einem Fehler mit der Meldung „Invalid RSA public key“ und der verbundene Shop wechselte in den Status „Registrierung ausstehend“. Die Identität wird nun in jedem Kontext als Einheit aus dem globalen Bereich (oder aus dem Shop, in dem sie gespeichert ist) gelesen; die Aktualisierung überträgt eine in einem Shop gespeicherte Identität in den globalen Bereich, ohne sie neu zu generieren, und falls sie nicht gelesen werden kann, bleibt der Status von Integrity unverändert, und der letzte Fehler wird als lokaler Fehler protokolliert.
Es wurde korrigiert, dass die Installation über die Konsole (prestashop:module install) die PWA_*-Einstellungen nur für den ersten Shop erstellt, während das Backoffice unter „Alle Shops“ die globalen Einstellungen liest. Die Installation erstellt nun die globalen Einstellungen, und das Update kopiert die fehlenden Einstellungen aus dem ersten Shop, ohne dabei bestehende Werte zu überschreiben.
Neu: Gemeinsame Filterleiste im Zugriffsprotokoll. Die Auswahlfelder sind in einem Raster gleicher Breite angeordnet, das Suchfeld und die Schaltfläche „Filtern“ befinden sich in derselben Zeile, und die sekundären Aktionen sind rechtsbündig ausgerichtet.
Die E-Mails des Moduls zeigen das Logo Ihres Shops in der Kopfzeile (mit dem Namen des Shops als Alternativtext) und eine einheitliche Fußzeile mit dem Logo von GO ON Agency sowie der Signatur „PrestaWard by GO ON Agency“, ohne Links oder Kontaktadressen. Das Logo in der Fußzeile ist eine Datei des Moduls selbst, die von Ihrem Shop bereitgestellt wird.
Einheitliches Erscheinungsbild des Dashboards in allen vier PrestaWard-Modulen: Abschnittsüberschriften, Formularfelder mit neutralen Rahmen und einheitliche ausklappbare Blöcke, einzeilige Statistiken sowie ein größeres Logo der GO ON Agency in der Kopfzeile. Die Hauptschaltfläche erhält nun eine einheitliche Farbe der Marke ohne Farbverlauf.
Behebt das Problem, dass in PrestaShop 9 die Registerkarten im Administrationsbereich als unterstrichene Links und die Abschnittsüberschriften in Großbuchstaben angezeigt wurden. Die allgemeinen Stile heben diesen Effekt nur innerhalb des PrestaWard-Panels auf, sodass PrestaShop 1.7 und 8 unverändert wie zuvor dargestellt werden.
Behebt das Problem, dass in PrestaShop 1.7 das Stylesheet des Moduls beim Registrieren mit der Versionsnummer in der Adresse verworfen wurde. Nun wird die Datei überprüft und ohne Parameter registriert, sodass das neue Erscheinungsbild in den Versionen 1.7, 8 und 9 angezeigt wird.
Behebt das Problem, dass in PrestaShop 9 beim Zurücksetzen des zweiten Faktors eines anderen Mitarbeiters und bei der Synchronisierung mit Integrity das Sicherheitstoken mit einer Methode überprüft wurde, die PrestaShop 9 nicht verwendet, wodurch es möglicherweise abgelehnt wurde. Die Validierung erfolgt nun über den PrestaShop-9-Dienst; in PrestaShop 1.7 und 8 bleibt die Überprüfung unverändert.
Wenn die Verbindung zu Integrity derzeit nicht aktualisiert werden kann, zeigt das Dashboard eine einzige Meldung an: Die gespeicherte Verbindung ist weiterhin gültig und der Versuch wird automatisch wiederholt. Die Bezeichnungen aller Registerkarten sind in die neun Sprachen übersetzt.
Das Update erstellt fehlende globale Einstellungen, führt den Schema-Schritt durch (Profilspalte für E-Mail-Codes und Passwortschlüssel-Tabellen) und hält E-Mail-Codes und Passwortschlüssel deaktiviert, bis ein Administrator sie aktiviert. An einer bestehenden Installation ändert sich nichts, bis ein Administrator eine Option aktiviert.

0.0.15

Neu: Zurücksetzen des zweiten Faktors eines Mitarbeiters über die MFA-Verwaltung. Sollte jemand sein Mobiltelefon und die Wiederherstellungscodes verlieren, benötigt der Administrator keinen Konsolenzugriff mehr. Durch die Zurücksetzung werden der Authentifikator und die Wiederherstellungscodes des Mitarbeiters gelöscht, seine vertrauenswürdigen Geräte und offenen Sitzungen werden geschlossen, und der Mitarbeiter muss sich beim nächsten Zugriff erneut registrieren. Es wird das Administratorpasswort abgefragt; die Funktion kann nicht für sich selbst verwendet werden, und ein Superadministrator kann nur von einem anderen Superadministrator zurückgesetzt werden. Jede Zurücksetzung sowie jeder abgelehnte Versuch wird im Zugriffsprotokoll festgehalten, und Sie können den Mitarbeiter per E-Mail benachrichtigen.
Neu: Übergangsfrist vor der erzwungenen Authentifizierung. In den Profilrichtlinien können Sie einem Profil eine Übergangsfrist von 3 bis 14 Tagen einräumen, bevor die Funktion „Erzwingen“ Mitarbeiter sperrt, die sich noch nicht registriert haben. Die Mitarbeiter melden sich wie gewohnt an und sehen auf jeder Seite des Backoffice einen Hinweis mit dem Datum, ab dem die Zwei-Faktor-Authentifizierung verpflichtend wird; diejenigen, die sich bereits registriert haben, fordern weiterhin ihren Code an. Das Dashboard zeigt die Frist für jedes Profil sowie die Anzahl der Mitarbeiter an, die sich noch registrieren müssen. Profile ohne Übergangsfrist verhalten sich wie in früheren Versionen.
Neu: „Aktuelle Aktivitäten“ im Dashboard fasst in einfachen Sätzen die letzten 30 Tage des Zugriffsprotokolls zusammen: Zugriffe von einer IP-Adresse oder einem Browser, die bzw. den dieser Mitarbeiter zuvor noch nicht verwendet hatte, wiederholte fehlgeschlagene Anmeldeversuche, Sperrungen, verwendete Wiederherstellungscodes und Rücksetzungen durch den Administrator. Verwenden Sie ausschließlich Ihre eigenen Protokolle, ohne Geolokalisierung oder externe Dienste.
Die Verwendung eines persönlichen oder per E-Mail versandten Wiederherstellungscodes wird nun im Zugriffsprotokoll als „Wiederherstellungscode verwendet“ erfasst.
Das Update fügt den Profilrichtlinien zwei Spalten hinzu (standardmäßig ohne Übergangsfrist) und registriert den Hook, der den Hinweis auf die Übergangsfrist anzeigt.
Das Support- und Diagnose-Panel wird – wie bei allen anderen PrestaWard-Modulen – direkt vor dem Abschnitt Integrity platziert und verschwindet im Kontext „Alle Shops“ nicht mehr: Es weist darauf hin, dass ein Shop ausgewählt werden muss.
Die Stylesheets werden mit der Modulversion geladen, sodass das neue Erscheinungsbild nach der Aktualisierung angezeigt wird, ohne dass der Browser-Cache geleert werden muss.
Die Synchronisierung mit Integrity erfolgt bei jedem Öffnen des Panels über eine Hintergrundanfrage, die die Seite niemals verlangsamt und höchstens einmal pro Minute und Shop durchgeführt wird.

0.0.14

Empfohlenes Sicherheitsupdate: Verstärkt die Authentifizierung mit dem zweiten Faktor im Backoffice, sodass geschützte Seiten und Aktionen erst nach deren Abschluss zugänglich sind.
Erweitert die MFA-Überprüfung auf Backoffice-Pfade von PrestaShop 1.7.7 bis 9, die nicht die klassische Vorlage verwenden, wie beispielsweise Exporte und AJAX-Anfragen.
Es begrenzt die Anzahl der Versuche bei allen Codeüberprüfungen unter „Meine Authentifizierung“, auch pro Mitarbeiter von verschiedenen IP-Adressen aus, und erfordert eine verifizierte Sitzung für sensible Kontoänderungen.
Behebt eine Weiterleitungsschleife in PrestaShop 9 beim Öffnen von „Meine Authentifizierung“ mit ausstehendem zweiten Faktor.
Mitarbeiter, deren Profile nach der Installation angelegt wurden, können nun auf „Meine Authentifizierung“ zugreifen.
Behebt Probleme bei der Installation und den erneuten Versuchen von Integrity unter PHP 7.1 und 7.2.
Erneuert die signierte MFA-Richtlinie, bevor sie abläuft, und zeigt im Dashboard an, wenn sie abgelaufen ist.
Fügt einen einmalig nutzbaren Notfallzugang über die Konsole hinzu, um die MFA-Pflicht vorübergehend auszusetzen, falls sich niemand anmelden kann. Dies ist das letzte Mittel: Es erfordert Zugriff auf den Server und den Notfall-Schlüssel; die Aussetzung dauert eine Stunde und wird protokolliert. Die Mitarbeiter können ihren Zugang weiterhin mit ihren persönlichen Codes oder über die optionale Wiederherstellung per E-Mail wiedererlangen.
Übersetzt alle Ereignisse des Zugriffsprotokolls in die neun Sprachen.

0.0.13

Behebt einen Fehler beim Kompilieren des Backoffice-Containers in älteren Versionen ohne request_stack.
Behält MFA und die Begrenzung der Anmeldeversuche in PrestaShop 9 bei; fehlt der erforderliche Kontext, wird der Zugriff verweigert.
Fügt einen begrenzten manuellen Diagnosebericht hinzu: Laden Sie diesen herunter und fügen Sie ihn Ihrer Support-Anfrage zusammen mit der Problembeschreibung und den Schritten zur Reproduktion des Problems bei. Es werden keine Daten automatisch übermittelt.
Vollständige Benutzeroberfläche in neun Sprachen, mit übersetzten Texten und Hilfetexten.

0.0.12

Korrigiert den Test-Controller für die Registrierung in PrestaShop 9 und zeigt die tatsächliche Ursache an, wenn Integrity fehlschlägt.
Aktualisiert das allgemeine Design des Backoffice und entfernt den in der Addons-Edition integrierten Update-Checker.

0.0.11

Sicherheitspatch: Unterbindet automatische Wiederholungsversuche bei der Registrierung, wenn sich der Registrierungsschlüssel des Shops ändert, und zeigt im Backoffice eine eindeutige Warnmeldung an.

0.0.10

Automatischer Heartbeat ohne Cron mittels einer lokalen, nicht blockierenden Abfrage und authentifizierter Server-zu-Server-Kommunikation über die Integrity-API.
Pro Shop versiegelte Anmeldedaten, unterzeichnete MFA-Richtlinie und letzter gültiger Status ohne Remote-Aufrufe während der Anmeldung.
Atomische Sperre, Sechs-Stunden-Intervall und Wartezeit nach Fehlern, um Duplikate zu vermeiden.
Lebenszyklus und Aktualisierung in PrestaShop 1.7, 8 und 9 validiert.

0.0.9

Sichere Verbindung zu Integrity pro Shop, versiegelte Zugangsdaten und Synchronisierung über das Backoffice.
Die signierte Remote-Richtlinie kann lediglich die lokale MFA-Richtlinie ergänzen und greift niemals in den Anmeldevorgang ein.
Die Konfiguration wurde in vier Registerkarten neu gegliedert: MFA und Benachrichtigungen, Richtlinien für Mitarbeiterprofile, Anmeldeversuche und Sperrungen sowie Netzwerk und IP.
Die Richtlinien nach Profil und Shop werden in einen eigenen Abschnitt verschoben, um sie von der globalen Richtlinie zu trennen.
Die redundante Quelle für Updates wird aus den Einstellungen entfernt: Der offizielle Kanal wird vom Modul festgelegt.
Jedes Konfigurationsfeld enthält einen direkten Link zur entsprechenden Erklärung im Hilfehandbuch.

0.0.8

Sicherheitszeitraum pro Mitarbeiter zum Ungültigmachen früherer Sitzungen, Herausforderungen und Geräte.
Konfigurierbare Deaktivierung nach jeder Passwortänderung, nur nach einer Wiederherstellung oder einer administrativen Änderung oder niemals.
Richtlinien „Vererben“, „Obligatorisch“, „Optional“ und „Deaktiviert“ nach Profil und Shop.
Superadministratoren sind im Modus „Erzwingen“ stets verpflichtet; bei mehreren Shops gilt die strengste Richtlinie.
Einmalig verwendbarer Notfallschlüssel und Wiederherstellung ausschließlich über die Konsole, ohne dauerhaften Web-Bypass.
Optionale Wiederherstellung per E-Mail während einer MFA-Abfrage mit einem achtstelligen Code, HMAC, einer Gültigkeitsdauer von fünf Minuten und einer Begrenzung der Versandanzahl.
HMAC-verkettete Protokolle, Integritätsprüfung, Aufbewahrungsdauer von 30 bis 730 Tagen und signierter JSON-Export.
Idempotente Migration 0.0.8 und validiertes Update von 0.0.7 in PrestaShop 1.7, 8 und 9.

0.0.7

„Sicherheitsstatus“, unterteilt in „MFA und Benachrichtigungen“, „Anmeldeversuche und Sperrungen“ sowie „Netzwerk und IP“, mit atomarer Speicherung.
Tastaturzugängliche Navigation über Registerkarten, Beibehaltung der Auswahl und automatisches Öffnen des Fensters bei Validierungsfehlern.
Echte Paginierung von Datensätzen in der Datenbank mit 25, 50 oder 100 Zeilen pro Seite.
Filter für Datensätze nach Datumsbereich, Mitarbeiter oder E-Mail-Adresse, Ereignis, Ergebnis und IP-Adresse.
Die Kopfzeile von „Meine Authentifizierung“ wurde neu gestaltet und bietet nun einen besseren Kontrast, eine verbesserte Hierarchie, eine optimierte Anpassung an mobile Geräte sowie Unternehmenslinks.
Der E-Mail-Test überprüft den Versand und die Empfänger, ohne dass die operativen Benachrichtigungen aktiviert sein müssen.
Sichtbare Diagnose des PrestaShop-Mailtransports, wobei zwischen Capture-Servern und dem tatsächlichen SMTP-Server unterschieden wird.
Fehlerdiagnose, kompatibel mit den Protokollen SwiftMessage und MailerMessage von PrestaShop 1.7, 8 und 9.
Das doppelte Präfix des Shops in den Betreffzeilen wurde entfernt und der alternative Link zum Backoffice verstärkt.
Unternehmensinterner E-Mail-Versand, validiert über Exchange Online in allen drei kompatiblen Versionen.
Mit Snapshot über das PrestaWard Update Manifest v1 vereinheitlichtes Update-Panel: Status, Schweregrad und SHA-256.
Idempotente Migration 0.0.7 und validiertes Update von 0.0.6 in PrestaShop 1.7, 8 und 9.

0.0.6

Transaktionsbasierter Schutz vor Brute-Force-Angriffen auf Passwörter sowie MFA über IP-Adresse und Identität.
Unterstützung für IPv4, IPv6, CIDR, vertrauenswürdige Proxys, Whitelist und Blacklist.
Begrenzte Sperrhinweise, um absichtlich ausgelöste E-Mail-Flutwellen zu verhindern.
Server-Quarantäne ohne Menü, Schnellzugriffe oder Backoffice-Inhalte.
„Meine Authentifizierung“ wurde neu gestaltet und umfasst nun vier Schritte, barrierefreie Beschriftungen, eine exportierbare Wiederherstellungsfunktion sowie die Möglichkeit zur individuellen Widerrufung.
Entsprechende und übersetzte E-Mails in PrestaShop 1.7, 8 und 9, mit Ergebnis pro Empfänger.
Verstärkter Tester: Unternehmens-HTTPS, keine Weiterleitungen, TLS, Begrenzung des Hauptteils und striktes Manifest v1.
Migration 0.0.6, Update von 0.0.5 und vollständige Kompatibilitätsmatrizen für alle drei unterstützten Versionen.

0.0.5

Stufenweiser Zugriff: PrestaShop überprüft zunächst das Passwort und fordert anschließend die Eingabe des TOTP-Codes oder die Wiederherstellung an.
Authentifizierte Sitzung in Quarantäne, mit dem Mitarbeiter verknüpft und auf „Meine Authentifizierung“ beschränkt, bis die MFA abgeschlossen ist.
Absicherung des seitlichen Zugriffs über direkte Controller und AJAX/XHR-Anfragen.
Obligatorische Registrierung für Mitarbeiter und Superadministratoren ohne bestätigte TOTP-Authentifizierung.
Vertrauenswürdige Geräte wurden in PrestaShop 9 korrigiert und sind nun mit dem Mitarbeiter und dem Browser verknüpft.
Zweiter Faktor, neu gestaltet auf Spanisch mit dem visuellen System PrestaWard.
Erweiterte Anleitung mit tatsächlichen Screenshots zum zweiten Faktor in PrestaShop 1.7, 8 und 9.
Vollständige, bereinigte Matrix: E-Mail, TOTP, Anti-Replay, Wiederherstellung, Vertrauenswürdigkeit und Quarantäne.

0.0.4

Obligatorische Registrierung unter „Meine Authentifizierung“ für Konten ohne TOTP, wenn der Modus auf „Erzwingen“ eingestellt ist.
Der zweite Schritt des Anmeldevorgangs wird erst nach der Überprüfung des Passworts angezeigt.
Superadministratoren, die in denselben persönlichen Authentifizierungsablauf eingebunden sind.
Das MFA-Formular für die Anmeldung wurde neu gestaltet und ins Spanische übersetzt.
Fehler 500 bei der Test-E-Mail behoben.
Separater MFA-Selbstbedienungszugang für jeden Mitarbeiter.
Richtlinien, Bestandsverwaltung, E-Mail und Protokolle sind auf den Superadministrator beschränkt.
Moderne und veraltete Berechtigungen wurden idempotent neu aufgebaut.
Präzise Diagnose von Empfängern, SMTP-Konfiguration und Datenübertragung.
Einheitliche reale IP-Adresse in Protokollen, bei der Ratenbegrenzung, in E-Mails und bei vertrauenswürdigen Geräten.
Ereignisse und Texte im Backoffice wurden ins Spanische übersetzt.
Kopfzeilen und Design im Stil der PrestaWard-Familie.
Der Unternehmens-Support wurde unter hola@go-onagency.es wiederhergestellt.
Update 0.0.4 und bereinigte Matrix in PrestaShop 1.7, 8 und 9.

0.0.3

Vereinheitlichte visuelle Geometrie mit PrestaWard Snapshot.
Widerrufbare vertrauenswürdige Geräte mit zufälligen 256-Bit-Tokens, die als Hash gespeichert sind.
Cookies vom Typ „Secure“, „HttpOnly“ und „SameSite=Lax“ sind auf das Backoffice beschränkt.
Entsprechende Warnmeldungen in den Legacy- und Symfony-Integrationen.
Branding, Produktlinks, Anleitung, Support und Test-E-Mail.
Überprüfung der Ratenbegrenzung in PrestaShop 1.7, 8 und 9.

0.0.2

Passwortgeschützte TOTP-Registrierung und lokaler QR-Code.
Einmalig verwendbare Wiederherstellungscodes, die als HMAC gespeichert sind.
Atomarer Schutz gegen TOTP-Replay-Angriffe.
Ratenbegrenzung nach Konto und IP-Adresse.
Spezifische Integrationen für die Legacy-Anmeldung und PrestaShop 9 Symfony.
Passwort- und faktorgeschützte Rotation des Authentifikators sowie Deaktivierung der MFA.

0.0.1

Sicheres Scaffold standardmäßig deaktiviert.
MFA-Tabellen, TOTP, Dashboard, Audit, Protokolle, Warnmeldungen und erste Übersetzungen.