Kurz gesagt: Ein WordPress Magic Link ist ein langes, zufälliges Token, dessen HMAC-SHA256-Hash — nicht das Token selbst — in deiner Datenbank gespeichert wird. Wer den Link hat, kommt ohne Passwort rein; wer deine Datenbank stiehlt, bekommt einen Hash, der sich nicht in einen funktionierenden Link zurückverwandeln lässt. Das ist das gesamte Sicherheitsmodell in einem Satz — der Rest dieses Beitrags erklärt, warum es funktioniert.
Das Problem mit dem alten Weg, Zugriff zu teilen
Wenn du je einem Kunden eine Staging-URL oder ein geteiltes Seitenpasswort gegeben hast, kennst du die Schwachstellen bereits:
- Ein geteiltes Passwort ist für alle identisch. Du kannst nicht erkennen, wer es weitergegeben hat, und ein Widerruf wirft alle Besucher gleichzeitig raus — auch den Kunden, der gerade mitten in der Prüfung ist.
- Staging-URLs werden indexiert. Ein vergessener
noindex-Header, und Google findet sie. "Nicht gelistet" ist nicht dasselbe wie "privat". - Keines von beidem läuft von selbst ab. Sechs Monate später funktioniert der Link, den ein ehemaliger Staging-Tester eines Kunden im Browserverlauf gespeichert hat, immer noch.
Keines davon ist ein Problem der Passwortstärke. Es sind Identitätsprobleme — das System hat keine Möglichkeit zu wissen, wer die Zugangsdaten nutzt, nur dass sie korrekt waren.
Was ein Magic Link eigentlich ist
Ein Magic Link tauscht "beweise, dass du ein Geheimnis kennst, das alle kennen" gegen "beweise, dass du ein Token besitzt, das sonst niemand hat". In Erdo Client Preview ist dieses Token eine kryptografisch zufällige Zeichenfolge — lang genug, dass Erraten praktisch unmöglich ist —, erzeugt pro Person, pro Zweck, mit eigenem Label, eigener Ablaufzeit und eigenem Nutzungszähler.
Entscheidend: Das rohe Token wird dir nur einmal, bei der Erstellung, in der URL angezeigt, die du kopierst und verschickst. In lesbarer Form landet es niemals in der Datenbank.
Warum HMAC statt einfach das Token zu speichern
Das ist der Teil, den die meisten "Magic Link"-Erklärungen auslassen. Das rohe Token in der Datenbank zu speichern — selbst in einer Spalte, die niemand anschaut — erzeugt dasselbe Risiko wie das Speichern von Klartext-Passwörtern: Eine SQL-Injection oder ein geleaktes Datenbank-Backup entfernt, und jeder aktive Link ist für einen Angreifer nutzbar.
Die Lösung ist HMAC (Hash-based Message Authentication Code), definiert in RFC 2104 und seit PHP 5 fest in PHPs hash_hmac()-Funktion eingebaut. HMAC kombiniert eine Nachricht (das Token) mit einem geheimen Schlüssel (einzigartig für deine WordPress-Installation) zu einer Signatur — in diesem Fall HMAC-SHA256.
Was das bringt:
- Die Datenbank enthält nur den Hash. Eine gedumpte
wp_options-Tabelle oder ein geleaktes Backup liefert einem Angreifer einen Einweg-HMAC-SHA256-Digest, keinen nutzbaren Link. - Der Hash lässt sich nicht wiederverwenden, um ein anderes Token zu fälschen. Da für einen passenden HMAC der geheime Schlüssel nötig ist, kann ein Angreifer weder von einem Hash auf ein gültiges Token zurückrechnen noch ein beliebiges Token einreichen und dessen Akzeptanz erzwingen, ohne den Schlüssel zu kennen.
- Die Verifizierung ist eine einfache Neuberechnung. Öffnet ein Besucher einen Link, berechnet das Plugin den HMAC des vorgelegten Tokens neu und vergleicht ihn mit dem gespeicherten Hash. Stimmen sie überein, ist der Link echt; sonst wird der Zugriff verweigert.
Der Kernpunkt: HMAC verwandelt "hat der Besucher die richtige Zeichenfolge vorgelegt" in "hat der Besucher eine Zeichenfolge vorgelegt, die nur der Server — und nur er, mit seinem geheimen Schlüssel — ursprünglich signiert haben kann". Das ist eine deutlich stärkere Garantie als ein Klartextvergleich.
Schritt für Schritt: Von der Erzeugung bis zum Zugriff
- Du klickst im WordPress-Admin auf "Magic Link erstellen". Das Plugin erzeugt ein zufälliges Token und berechnet sofort dessen HMAC-SHA256-Hash mit einem für deine Seite einzigartigen Geheimnis.
- Nur der Hash wird gespeichert — zusammen mit Metadaten: einem Label, einer optionalen Ablaufzeit, einer optionalen Weiterleitung und einem Nutzungszähler. Das rohe Token steckt in der URL und wird nirgendwo sonst dauerhaft gespeichert.
- Du kopierst die URL und schickst sie an die Person, die Zugriff braucht — einen Kunden, einen Stakeholder, einen Reviewer.
- Die Person öffnet den Link. Das Plugin extrahiert das Token aus der URL, berechnet dessen HMAC neu und vergleicht ihn mit dem gespeicherten Hash.
- Bei Übereinstimmung setzt das Plugin ein signiertes, HttpOnly-Cookie, sodass die Besucherin die ganze Live-Seite durchsuchen kann, ohne auf jeder Seite erneut auf den Link zu klicken. Bei Nichtübereinstimmung oder abgelaufenem Link sieht sie nur die gesperrte Wartungs- oder Coming-Soon-Seite.
- Du widerrufst jederzeit — genau diesen einen Link sofort ungültig machen, ohne andere aktive Links zu berühren.
Magic Links vs. die Alternativen
| Ansatz | Zugriff pro Person | Übersteht ein DB-Leak | Einzeln widerrufbar | Aufwand |
|---|---|---|---|---|
| Geteiltes Seitenpasswort | Nein — ein Passwort für alle | Nein — klartextäquivalent, ein Reset sperrt alle aus | Nein | Gering |
| Nicht gelistete Staging-URL | Nein — eine URL für alle | Entfällt — es gibt keine Auth | Nein (URL muss geändert werden) | Gering |
| Magic Link (HMAC-verifiziert) | Ja — ein Token pro Person | Ja — nur ein Hash wird gespeichert | Ja — pro Link | Gering (vom Plugin verwaltet) |
Wenn du das speziell mit dem eingebauten Passwortschutz von WordPress vergleichen willst — diesen Vergleich haben wir ausführlicher in Passwortgeschützte Seiten vs. sichere Preview-Links behandelt.
Warum das für Kundenarbeit wichtiger ist, als es aussieht
Agenturen und Freelancer brauchen nicht einfach irgendeine Zugriffskontrolle — sie müssen wissen, wer sich was angesehen hat, wann es aufhört zu funktionieren, und dass das Entziehen des Zugriffs eines Kunden nie den eines anderen berührt. Ein Zugangsdatum pro Person, das sich einzeln widerrufen und einzeln ablaufen lässt, ist das einzige Modell, das alle drei liefert. Ein geteiltes Passwort liefert keins davon.
Das erklärt auch, warum Magic Links so natürlich zu Funktionen wie Besucher-Feedback und Live-Anmerkungen auf Elementebene passen: Sobald du weißt, welches Token die Seite geöffnet hat, weißt du auch, welcher Kunde welche Anmerkung hinterlassen hat — ohne vorher ein Konto zu verlangen.
Sieh es im Code, nicht nur in diesem Beitrag
Erdo Client Preview ist Open Source, daher musst du nichts davon einfach glauben. Token-Erzeugung und HMAC-Verifizierung liegen im GitHub-Repository des Plugins — lies den Quellcode, erstelle ein Issue oder sende einen Pull Request, wenn dir etwas Verbesserungswürdiges auffällt.
Fazit
Ein Magic Link ist nur so vertrauenswürdig wie das, was mit dem Token nach der Erzeugung passiert. Es als Klartext zu speichern macht deine Datenbank zu einer Liste funktionierender Zugangsdaten; es als HMAC-SHA256-Hash zu speichern macht aus einem Leak eine Liste von Digests, die ohne den geheimen Schlüssel, der sie erzeugt hat, nutzlos sind. Ein kleines Implementierungsdetail mit großer Wirkung darauf, was dich ein Worst-Case-Datenbankeinbruch am Ende wirklich kostet.
Installiere Erdo Client Preview kostenlos von WordPress.org und erstelle deinen ersten Magic Link in unter einer Minute.