Kundenpasswörter in PrestaShop: wie sie gespeichert werden und was Sie vermeiden sollten

Ein Kunde ruft an, weil er sein Passwort vergessen hat, und bittet Sie, es ihm zu sagen. Das können Sie nicht, und das ist gut so: Der Shop kennt es nicht. Was PrestaShop in der Datenbank speichert, ist nicht das Passwort, sondern ein daraus berechneter Wert, aus dem es kein Zurück gibt. Wer versteht, wie dieser Wert funktioniert, vermeidet Fehler bei der Migration von Kunden, beim Import von Konten und im Support.

Was der Shop tatsächlich speichert

Wenn ein Kunde sein Konto anlegt, schickt PrestaShop das Passwort durch eine Hash-Funktion: eine Berechnung, die aus einem Text eine Zeichenkette fester Länge erzeugt. Dasselbe Passwort ergibt immer ein überprüfbares Ergebnis, aber aus dem Ergebnis lässt sich das Passwort nicht ermitteln. Beim Login berechnet der Shop den Hash der Eingabe erneut und vergleicht ihn mit dem gespeicherten. Stimmen sie überein, ist der Kunde drin.

Der Hash steht in der Spalte passwd der Kundentabelle (ps_customer mit dem üblichen Präfix) und für Mitarbeiter in ps_employee. Wer diese Spalte sieht, hat damit noch nicht das Passwort, kann aber außerhalb Ihres Servers beliebig viele Kandidaten durchprobieren, ohne Begrenzung der Versuche. Deshalb ist der verwendete Algorithmus so wichtig.

Wie es sich je nach Version verändert hat

PrestaShop 1.6 und älter

Der Hash war ein MD5 aus dem Passwort, verkettet mit dem Cookie-Schlüssel der Installation. MD5 lässt sich extrem schnell berechnen, und was anderswo ein Vorteil ist, ist hier ein Nachteil: Ein gewöhnlicher Rechner probiert riesige Mengen an Kandidaten pro Sekunde. Wer die Datenbank und den Cookie-Schlüssel aus der Konfigurationsdatei erbeutet, knackt schwache Passwörter sofort.

PrestaShop 1.7, 8 und 9

Seit 1.7 wird bcrypt über die Passwortfunktionen von PHP verwendet. Bcrypt ist absichtlich langsam und nutzt pro Benutzer ein eigenes Salt, das Durchprobieren wird also deutlich teurer. Der Shop kann alte Hashes weiterhin prüfen: Meldet sich ein Kunde mit einem Hash aus 1.6 erfolgreich an, berechnet PrestaShop ihn mit dem neuen Algorithmus neu und speichert ihn. Kunden, die nie zurückkommen, behalten den alten Hash.

Ab PrestaShop 8 gibt es außerdem eine konfigurierbare Passwortrichtlinie in den Sicherheitseinstellungen des Shops (Länge und geforderte Stärke), die für neue Passwörter gilt.

Kunden von einer anderen Plattform migrieren

Beim Wechsel von WooCommerce, Magento, Shopify oder einem anderen PrestaShop stellt sich immer dieselbe Frage: Können sich die Kunden mit ihrem Passwort anmelden? Das hängt vom Format des Quell-Hashes ab:

• Nutzt die Quelle Standard-bcrypt, ist der Hash meist kompatibel und kann einfach übernommen werden, sofern Sie es vorher mit mehreren echten Konten in der Testkopie prüfen.
• Nutzt sie ein eigenes Format (Hashes mit Plattform-Präfixen, mehrere Runden eines anderen Algorithmus), kann PrestaShop ihn nicht prüfen. Dann bleibt ein Brückenmodul, das das alte Format beim ersten Login prüft und umwandelt, oder alle Kunden setzen ihr Passwort zurück.
• Liefert die Quelle keine Hashes (manche geschlossenen Plattformen exportieren sie nicht), bleibt nur das Zurücksetzen.

Wenn Sie das Zurücksetzen erzwingen, bereiten Sie es vor: eine E-Mail, die den Shopwechsel erklärt, in Etappen über einen Mailserver verschickt, der nicht im Spam landet, und eine Wiederherstellungsseite, die auf dem Smartphone funktioniert. Viele Kunden kommen über die E-Mail einer Bestellung und nicht über diese Mitteilung.

Passwörter zurücksetzen, ohne Lücken zu öffnen

Der richtige Ablauf ist der, den PrestaShop mitbringt: Der Kunde fordert die Wiederherstellung an, erhält einen Link mit einem ablaufenden Einmalcode und wählt ein neues Passwort. Fehler entstehen, wenn man abkürzen will:

• Selbst ein Passwort festlegen und es am Telefon diktieren oder per E-Mail schicken. Es bleibt an Orten stehen, die Sie nicht kontrollieren, und der Kunde ändert es selten.
• Bei einem Import für alle dasselbe Passwort verwenden („Shop2024“ für jeden migrierten Kunden). Genau das probiert jeder als Erstes.
• Passwörter im Klartext in der Willkommens-E-Mail verschicken. Manche alten Module tun das. Prüfen Sie die E-Mail-Vorlagen und entfernen Sie diese Variable.
• Den Kunden nach seinem Passwort fragen, um in sein Konto zu gehen und nachzusehen, was los ist. Wenn Sie sehen müssen, was er sieht, geht das auch ohne.

Was Sie nie tun sollten

1. Passwörter im Klartext oder umkehrbar verschlüsselt speichern, „für alle Fälle“, in einer eigenen Tabelle, einer CSV-Datei oder einem Notizfeld. Ein Drittanbietermodul, das so etwas tut, macht aus jedem Leck eine Katastrophe.
2. Die vollständige Kundentabelle exportieren, um sie an eine Agentur oder einen Dienstleister zu schicken. Exportieren Sie nur die benötigten Spalten und niemals passwd.
3. Datenbank-Dumps in einem öffentlichen Ordner des Servers liegen lassen. Eine .sql-Datei im Stammverzeichnis enthält alle Hashes und den Schlüssel, um sie anzugreifen.
4. Denselben Cookie-Schlüssel in Testkopie und Produktivshop verwenden und die Kopie ohne Passwort aus dem Internet erreichbar lassen.
5. Den Inhalt von Login-Formularen in Debug-Protokolle schreiben. Das passiert bei Modulen im Debug-Modus häufiger, als man denkt.

Wenn Sie ein Leck vermuten

Wenn jemand Zugriff auf die Datenbank hatte, handeln Sie so, als wären die Hashes bereits draußen:

• Schließen Sie zuerst den Zugangsweg: verwundbares Modul, FTP- oder Panel-Zugangsdaten, öffentlicher Dump.
• Ändern Sie das Datenbankpasswort und die Passwörter aller Mitarbeiter.
• Klären Sie mit einer Fachperson, ob Sie die Verletzung melden müssen, an die Datenschutzbehörde und an die Betroffenen. Die DSGVO verlangt, das Risiko zu bewerten und je nach Fall zu melden.
• Bitten Sie die Kunden, ihr Passwort zu ändern, besonders wenn sie es bei anderen Diensten wiederverwenden. Stammte der Hash aus 1.6, ist die Empfehlung dringender.

Warum Updates auch die Passwörter schützen

Ein Shop, der noch auf 1.6 läuft, speichert Passwörter schwach und wird das tun, solange er nicht migriert wird. Außerdem kommen Lecks, die die Datenbank offenlegen, fast immer über nicht aktualisierte Module. PrestaShop, PHP und Module aktuell zu halten, ist nicht nur eine Frage neuer Funktionen: Es entscheidet, wie viel Schaden ein Leck anrichtet, wenn es passiert.

So lösen Sie es in PrestaShop

RKR Security Alert verwaltet keine Passwörter, überwacht aber das, was einem Leck meist vorausgeht. Seine Prüfung meldet erreichbare .sql- oder .zip-Backups im Stammverzeichnis, Konfigurationsdateien mit zu offenen Rechten, die die Datenbank-Zugangsdaten preisgeben, aktiven Entwicklungsmodus und display_errors im Produktivbetrieb sowie inaktive Administratorkonten. Außerdem erkennt es neu angelegte und geänderte Mitarbeiter, auch wenn das direkt per SQL geschieht, Backoffice-Zugriffe von neuen IP-Adressen und Web-Shells in den Dateien, und benachrichtigt Sie per Telegram, ohne eine einzige Datei vom Server zu schicken.