Ein passwortgeschützter Kurzlink ist eine kurze URL, die ein Passwort verlangt, bevor sie jemanden weiterleitet. Man öffnet den Link, trifft auf eine kleine Zwischenseite statt auf das Ziel, tippt das Passwort - und erst dann feuert der Redirect. Gibt man das Passwort falsch ein, bleibt man auf der Abfrage. Das Ziel wird erst preisgegeben, wenn die Prüfung bestanden wurde.
Das ist die ganze Idee - und es lohnt sich, sie präzise zu formulieren, weil der Name zu viel verspricht. Ein Passwort-Gate ist Zugangshürde vor einem Link. Es ist keine Verschlüsselung der Seite hinter dem Link. Das sind verschiedene Garantien, und ihre Verwechslung führt zu späteren Überraschungen. Dieser Beitrag behandelt, wofür das Gate gut ist, welche Anwendungsfälle wirklich passen, wie die Prüfung beim Redirect funktioniert, wo die Sicherheit endet und was man kombinieren sollte, damit das Ganze hält.
Wofür ein passwortgeschützter Kurzlink ist#
Die nützlichen Fälle haben eine gemeinsame Form: Man teilt einen Link über einen Kanal, den man nicht vollständig kontrolliert, und möchte, dass für den Zugang neben der URL noch etwas Zweites erforderlich ist.
Ein sensibles Dokument ist der naheliegendste Fall. Man sendet einen Vertragsentwurf, ein Finanzmodell oder eine interne Präsentation an jemanden außerhalb des Unternehmens. E-Mails werden weitergeleitet. PDFs werden weitergegeben. Ein Kurzlink, den jeder mit der URL öffnen kann, ist nur so privat wie die am wenigsten vorsichtige Person, die ihn je hatte. Schützt man ihn mit einem Passwort, bedeutet eine versehentliche Weiterleitung keinen automatischen Zugang mehr.
Kunden-Deliverables sind dasselbe Muster mit einer Frist. Eine Agentur übergibt eine Sammlung von Assets, einen Videoschnitt, einen Kampagnenbericht. Der Kunde soll es erreichen, nicht das gesamte Adressbuch des Kunden. Eine gesperrte URL hält das Deliverable hinter einem gemeinsamen Geheimnis, das man beim Erstellen des Links festlegt.
Private Kampagnen und gesperrte Inhalte runden die Liste ab. Eine Pre-Launch-Landingpage, die eine kleine Gruppe vorab sehen soll. Ein Early-Access-Angebot für eine Warteliste. Eine Mitgliederressource, wo die Zielgruppe bereits ein Passwort von woanders hat. In jedem Fall reist der Link per E-Mail oder Chat, und das Passwort ist das, was "Ich habe das bekommen" von "Ich bin darauf gestoßen" unterscheidet.
Was nicht passt: alles wirklich Geheime, alles Regulierte, alles, bei dem ein Leak ein meldepflichtiger Vorfall ist. Für diese Fälle ist ein gemeinsames Link-Passwort zu stumpf. Man braucht personalisierte Authentifizierung am Ziel selbst - eine andere Kontrolle, auf die ich zurückkommen werde.
Wie ein Passwort-Gate beim Redirect funktioniert#
Hier ist der mechanische Teil, weil die Reihenfolge der Operationen das Gate sinnvoll macht.
Ein normaler Kurzlink ist ein Redirect. Der Edge schlägt den Slug nach, findet das Ziel und schreibt einen 302 in den Browser des Besuchers. Schnell, zustandslos, keine Fragen gestellt. Ein passwortgeschützter Kurzlink fügt einen Schritt vor dem Redirect ein: Der Edge sieht, dass der Link ein Passwort gesetzt hat, also leitet er nicht weiter, sondern gibt eine Herausforderung zurück. Der Besucher bekommt eine Zwischenseite, die nach dem Passwort fragt. Er sendet es ab. Der eingegebene Wert wird gegen den gespeicherten Hash geprüft. Stimmt er überein, wird der Redirect ausgeführt. Stimmt er nicht, bleibt man auf der Abfrage, und die Ziel-URL wird nie an den Browser gesendet.
Zwei Details entscheiden, ob das Gate etwas taugt.
Erstens wird das Passwort gehasht und nie im Klartext gespeichert. Das gespeicherte Geheimnis eines Links sollte ein Einweg-Hash sein, damit ein Datenbankzugriff einem Angreifer nicht alle Link-Passwörter des Systems preisgibt. Argon2id ist die aktuelle Empfehlung für Passwort-Hashing - und das ist es, was Elido für Link-Passwörter verwendet, mit der Verifikation im Prozess unter Verwendung eines Constant-Time-Vergleichs, damit die Prüfung selbst keine Informationen durch Timing preisgibt. Die API für einen Link gibt nie den Hash zurück; sie gibt einen Boolean zurück, der sagt, ob ein Passwort gesetzt ist. Ein Besucher, der auf einen geschützten Link trifft, erhält eine 401 mit einem password_required-Flag und einem Challenge-Token und muss das korrekte Passwort in einer Folgeanfrage einreichen, bevor der Redirect erfolgt. Die Mechanik dieser Speicherung ist in der URL-Shortener-Sicherheits-Checkliste im Abschnitt über Link-Passwortschutz beschrieben.
Zweitens erfolgt die Prüfung, bevor das Ziel offenbart wird. Das klingt offensichtlich, aber eine überraschende Anzahl von "privaten" Link-Schemata leakt das Ziel im clientseitigen Code oder in einer Redirect-Kette, die ein entschlossener Besucher vom Netzwerk ablesen kann. Der Sinn der serverseitigen Prüfung am Redirect ist, dass die Ziel-URL auf dem Server bleibt, bis das Passwort korrekt ist. Wenn man schon einmal ein Gate gesehen hat, das als JavaScript implementiert wurde, das die echte URL abruft und dann weiterleitet, hat man ein Gate gesehen, das jeder mit den Browser-Entwicklertools direkt durchgehen kann. Serverseitige Auswertung ist der Unterschied - dieselbe Überlegung, die Smart Links am Edge statt in einem JS-Shim auf einer Landingpage routen lässt.
Die Sicherheitsgrenzen, klar ausgesprochen#
Das ist der Abschnitt, den Menschen überspringen und dann bereuen, also steht er in der Mitte, wo er schwer zu übersehen ist.
Ein Passwort-Gate schützt den Kurzlink. Es schützt nicht das Ziel. Wenn das Ziel eine öffentliche URL ist, die jeder durch direktes Eintippen erreichen kann, dann hält das Passwort nur Leute auf, die den Kurzlink haben - nicht Leute, die die zugrundeliegende Seite erraten oder zufällig finden können. Das Gate erhöht die Hürde für den häufigen Teilungsfall, bei dem jemand nur die kurze URL hat. Es tut nichts für ein Ziel, das bereits zugänglich ist.
Die Regel ist also einfach: Das Ziel sollte auch zugangskontrolliert sein. Ein Dokument hinter einem passwortgeschützten Kurzlink sollte auch irgendwo liegen, das überprüft, wer man ist - nicht nur irgendwo, das zufällig einen langen unratbaren Pfad hat. Das OWASP Authentication Cheat Sheet und die begleitende Access-Control-Anleitung sind hier die Referenz: Authentifizierung beweist, wer jemand ist, Zugangskontrolle entscheidet, was er erreichen kann, und ein gemeinsames Link-Passwort ist eine schwache Form des Ersten, das nichts über das Zweite sagt. Verwenden Sie es als Komfortschicht, nicht als das, was zwischen einem Angreifer und regulierten Daten steht.
Einige weitere ehrliche Grenzen.
Ein gemeinsames Passwort ist geteilt. Jeder, der es hat, ist für das Gate dieselbe Identität. Es gibt keine personalisierte Aufzeichnung, wer den Link geöffnet hat, keine Möglichkeit, einer einzelnen Person den Zugang zu entziehen, ohne das Passwort für alle zu wechseln. Wenn man wissen muss, dass Dana das Deliverable speziell geöffnet hat, wird ein gemeinsames Link-Passwort das nicht verraten.
Der Link sollte immer über HTTPS bedient werden. Ein über einfaches HTTP übermitteltes Passwort ist ein im Klartext gesendetes Passwort für jeden auf dem Netzwerkpfad. Transport-Verschlüsselung ist das Mindestmaß, kein Feature; MDNs Übersicht über HTTPS erklärt warum. Elido bedient Redirects standardmäßig über HTTPS, auch auf eigenen Domains - aber das Prinzip gilt überall, wo man ein Gate setzt.
Und ein Passwort ist kein Ersatz für einen Ablauf. Ein Link, der für immer live bleibt, ist eine Haftung, ob er ein Passwort hat oder nicht, weil das Geheimnis langsam durchsickert, je mehr Orte es teilen. Koppeln Sie das Gate mit einer Lebensdauer.
Was man kombinieren sollte#
Ein Passwort-Gate ist eine Kontrolle. Es funktioniert am besten, wenn es mit anderen kombiniert wird, die abdecken, was es nicht kann.
Ablauf und Max-Klick-Caps begrenzen den Link in Zeit und Nutzung. Setzen Sie ein expires_at, damit ein Kunden-Deliverable nach Ende des Engagements nicht mehr erreichbar ist, und einen Max-Klick-Cap, damit ein Einmal-Download-Link nach einmaligem Öffnen deaktiviert wird. Beide werden am Redirect durchgesetzt, bevor ein Klick-Event aufgezeichnet wird - das heißt, ein falscher Passwortversuch gegen einen bereits abgelaufenen Link erreicht das Gate gar nicht erst. Die Abwägungen rund um die Lebensdauer behandelt der Beitrag Link-Ablauf und selbstzerstörende Links.
IP- oder Geo-Limits schränken ein, wer das Gate überhaupt versuchen kann. Wenn ein Kunden-Deliverable immer nur aus einem Büro geöffnet wird, bedeutet die Einschränkung des Links auf diesen Bereich, dass ein geleaktes Passwort plus ein geleakter Link von überall sonst immer noch scheitert. Regionskontrolle wird im Beitrag Geo-Targeting für Kurzlinks behandelt, und sie ergänzt das Passwort, anstatt es zu ersetzen.
Für Teams ist die richtige Antwort meistens gar kein gemeinsames Passwort, sondern SSO. Wenn die Personen, die einen Link erreichen sollen, Mitarbeiter in einem Identity-Provider sind, sperrt man das Ziel hinter SCIM und SSO, damit der Zugang dem Verzeichnis folgt: Verlässt jemand das Unternehmen, ist sein Zugang weg, ohne Passwort-Rotation. Ein gemeinsames Link-Passwort ist für Ad-hoc-externes Teilen; verzeichnisverwalteter Zugang ist für alles, bei dem man personalisiertes Widerrufen braucht. Der SCIM- und SSO-Einrichtungsleitfaden führt durch die Einrichtung, und die Enterprise-Lösungsseite zeigt, wo es passt.
Das allgemeine Prinzip ist Verteidigung in Schichten. Keine einzelne Kontrolle hier ist allein stark. Ein Passwort stoppt zufälligen Zugang, ein Ablauf begrenzt das Zeitfenster, HTTPS schützt die Übertragung, Ziel-Zugangskontrolle schützt den Inhalt, und SSO erledigt den Team-Fall. Stapeln Sie die, die Ihre Situation braucht.
Eine praktische Anleitung#
Wenn man einen Link absichern möchte, ist die Form der Arbeit unabhängig vom Tool dieselbe.
Setzen Sie das Passwort, wenn Sie den Link erstellen oder bearbeiten. Die Link-Einstellungen sollten es erlauben, ein Passwort anzuhängen; einmal gesetzt, ist der Link kein einfacher Redirect mehr und gibt die Challenge zurück. Wählen Sie ein Passwort, das nicht trivial zu erraten ist und das nicht von woanders wiederverwendet wird, weil ein gemeinsames Geheimnis, das auch Ihre E-Mail entsperrt, ein schlechtes gemeinsames Geheimnis ist.
Teilen Sie Link und Passwort über getrennte Kanäle. Das ist die einzelne wichtigste Gewohnheit. Senden Sie den Kurzlink in der E-Mail oder im Dokument, und senden Sie das Passwort über eine Chat-Nachricht, eine separate E-Mail oder einen kurzen Anruf. Wenn beide in derselben Nachricht reisen, gibt eine einzige abgefangene Nachricht alles preis - und das Gate hat nichts gebracht. Durch die Trennung braucht ein Angreifer zwei Kanäle, nicht einen.
Setzen Sie gleichzeitig einen Ablauf. Entscheiden Sie schon am Anfang, wie lange der Link leben soll und ob er nach einer bekannten Anzahl von Öffnungen erlöschen soll, und setzen Sie das bei der Erstellung - anstatt sich zu versprechen, es später zu bereinigen. Das wird nicht passieren.
Prüfen Sie, ob das Ziel seine eigene Zugangskontrolle hat, wenn der Inhalt sensibel ist. Das Gate erledigt seinen Job für den Teilungsfall. Wenn das zugrundeliegende Dokument auch Widerstand gegen jemanden braucht, der die URL errät, muss dieser Schutz am Ziel liegen, nicht am Kurzlink. Für eine umfassendere Behandlung, wie diese Teile in ein Bedrohungsmodell passen, geht Sind URL-Shortener sicher durch das breitere Bild, und die Vertrauensseite deckt Elidos Positionierung ab.
Das ist die ehrliche Version von passwortgeschützten Kurzlinks. Sie sind eine nützliche, reibungsarme Möglichkeit, eine geteilte URL davor zu schützen, für jeden offen zu sein, der sie zufällig erhält. Sie sind kein Tresor. Als eine Schicht in einem Stapel verwendet - mit Ablauf und einem ordentlich zugangskontrollierten Ziel - erledigen sie genau den Job, den sie sollten. Als einziges Ding zwischen einem Angreifer und etwas Wichtigem verwendet, werden sie enttäuschen. Gate setzen, Kanäle trennen, Lebensdauer begrenzen, Ziel sperren - und man hat einen Teilungsablauf, der hält.
Wer sehen möchte, welche Kontrollen auf welchem Plan verfügbar sind, findet sie auf der Preisseite, und die Custom-Domains-Funktion behandelt das Bedienen von gesperrten Links auf einer eigenen gebrandeten Domain über HTTPS. Die Einrichtung ist in Wie man gebrandete Kurzlinks einrichtet beschrieben.