JPKCom Enable Argon2 — Anleitung & Tipps

Wie du WordPress-Passwort-Hashes mit JPKCom Enable Argon2 auf Argon2id umstellst — Installation, Voraussetzungen und Praxis-Tipps zur Migration.

JPKCom Enable Argon2 stellt die Passwort-Hashes deiner WordPress-Installation auf Argon2id um — den speicher- und rechenintensiven Gewinner der Password Hashing Competition. Sinnvoll, wenn du über die seit WordPress 6.8 standardmäßige bcrypt-Variante hinausgehen willst.

Anleitung

Voraussetzungen

  • WordPress 6.9 oder neuer (getestet bis WordPress 7.1)
  • PHP 8.3 oder neuer mit Argon2id-Unterstützung (PASSWORD_ARGON2ID)
  • Multisite wird unterstützt (das Plugin ist netzwerkfähig)

Installation

  1. Gehe im Admin-Bereich zu Plugins → Installieren und klicke auf Plugin hochladen.
  2. Wähle die ZIP-Datei des Plugins und klicke auf Jetzt installieren.
  3. Klicke auf Aktivieren.

Es gibt keine Einstellungsseite — sobald das Plugin aktiv ist, wirkt es automatisch.

Wie es wirkt

Seit WordPress 6.8 verwendet der Core standardmäßig bcrypt für Passwort-Hashes (zuvor phpass). Dieses Plugin schaltet stattdessen Argon2id ein. Argon2id ist speicherhart ausgelegt und erschwert dadurch GPU-gestützte Brute-Force-Angriffe deutlich. Hintergründe zur Core-Umstellung beschreibt der WordPress-Core-Beitrag zum Passwort-Hashing (öffnet in neuem Tab).

Tipps & Tricks

  • Bestehende Hashes wandern schrittweise: WordPress schreibt einen Passwort-Hash erst beim nächsten erfolgreichen Login des jeweiligen Nutzers neu. Die Umstellung auf Argon2id passiert also nach und nach — ein Massen-Reset ist nicht nötig. Für besonders sensible Konten kannst du gezielt einen Passwort-Reset erzwingen, damit der neue Algorithmus sofort greift.
  • Argon2id-Support prüfen: Stelle sicher, dass deine PHP-Umgebung Argon2id kennt (Konstante PASSWORD_ARGON2ID vorhanden). Andernfalls steht der Algorithmus nicht zur Verfügung.
  • Nur ein Plugin sollte das Hashing bestimmen: Falls ein weiteres Security-Plugin ebenfalls am Passwort-Hashing dreht, kläre Zuständigkeiten — sonst überschreiben sich die Verfahren gegenseitig.
  • Reproduzierbare Updates: Ab Version 2.0.2 nutzt das Plugin sichere, selbst gehostete Updates über GitHub mit SHA256-Prüfsummen und arbeitet mit declare(strict_types=1). Seit 2.0.9 trägt es außerdem den Header Update URI: Die Update-Schnittstelle von wordpress.org liefert für dieses Plugin dann keine Updates mehr, ein dort veröffentlichtes Plugin mit demselben Slug kann sich also nicht als Update ausgeben. Seit 2.0.10 zeigt Dashboard → Aktualisierungen das JPKCom-Logo neben dem Plugin.
  • Updates auch im deaktivierten Zustand: Seit 2.0.11 (Updater 1.5.0) bekommt das Plugin Updates auch dann angeboten, wenn es deaktiviert ist — vorausgesetzt, ein anderes JPKCom-Plugin mit Updater 1.5.0 oder neuer ist aktiv. Dessen Updater beantwortet die Update-Abfrage für alle installierten JPKCom-Plugins, samt Update-Zeile, Icon und „Details anzeigen“, und die SHA256-Prüfung gilt genauso wie für ein aktives Plugin. Auf Multisite muss dafür mindestens ein JPKCom-Plugin netzwerkweit oder auf der Hauptseite aktiv sein. Außerdem seit 2.0.11: Die gespeicherte Update-Liste enthält keine Download-URLs von JPKCom-Plugins mehr, ein JPKCom-Updater ergänzt sie nur, solange er geladen ist; die Prüfsumme wird auch bei einem Paket geprüft, das ein anderes Plugin liefert, und für jede GitHub-Adresse der Release-Datei. Liegt das Plugin als Git- bzw. VCS-Checkout oder (aktiviert) in einem umbenannten Ordner, erfährst du von einem neuen Release, WordPress aktualisiert es aber nie automatisch — das Update würde den Checkout bzw. den Ordner löschen. Ein deaktiviertes Plugin in einem umbenannten Ordner erkennt der Updater gar nicht. Update-Informationen holt der Updater nur für Nutzer, die Plugins aktualisieren dürfen, im Update-Cron und in WP-CLI, nie für anonyme Besucher.

Weiterführende Informationen