Das "Klicken Sie keine verdächtigen Links"-Ablenkungsmanöver

Jedes Jahr predigen Security-Trainings dasselbe Mantra: URL prüfen, auf HTTPS achten, Passwörter niemals auf unbekannten Seiten eingeben. Theoretisch klingt das vernünftig. In der Praxis haben wir aber Authentifizierungssysteme geschaffen, die so vertrackt sind, dass wir von Nutzern verlangen, ein Puzzle zu lösen – mit wechselnden Regeln jedes Quartal.

Hier ist die unbequeme Wahrheit: Phishing ist nicht immer ein Nutzerversagen. Oft ist es ein Architekturproblem.

Wenn legitime Seiten wie Betrug aussehen

Werfen wir einen Blick auf den eigenen Anmeldeprozess. Bei den meisten Unternehmen leitet der Login-Button Nutzer durch ein Gewirr aus Drittanbieter-Identitätsdiensten, föderierten Authentifizierungsservices und tokenisierten Endpunkten – die verdächtig stark nach Phishing-Versuchen aussehen.

https://app.deinunternehmen.de → 
https://auth.identitätsanbieter.io/deinunternehmen →
https://sso.föderierterdienst.com/session/token →
https://verify.authentifizierungs-prozessor.com/mfa

Keine dieser URLs gehört zur eigenen Domain. Keine ist einprägsam. Und keine gibt Nutzern eine echte Chance, das Echte vom Falschen zu unterscheiden.

Ein Angreifer braucht nur drei Dinge, um dieses Erlebnis nachzubauen: eine überzeugende Vorlage, ein gestohlenes Logo und ein Passwortfeld. Die URL selbst ist bedeutungslos geworden, weil wir Nutzern beigebracht haben, sie zu ignorieren.

Warum URLs nie für diesen Zweck gemacht wurden

Mal ehrlich – URL-Strukturen sind von Natur aus verwirrend. Wir können nicht erwarten, dass nicht-technische Nutzer sie wie Entwickler analysieren.

Betrachten wir diese URL:

https://login.staging.internal.beispiel-corp.de/auth/verify

Die meisten Nutzer sehen "staging" und "internal" und ihre Augen gehen glasig vorüber. Sie suchen nach dem Firmennamen, und selbst wenn sie ihn finden, können sie nicht erkennen, ob die umgebende Infrastruktur legitim oder eine geschickte Imitation ist.

Der Hostname liest sich vom Speziellen zum Allgemeinen (login → staging → internal → beispiel-corp → de), was bedeutet, dass der wichtigste Identifikator – die eigentliche Domain – irgendwo in der Mitte versteckt ist. Nutzer lernen, nach einem Markennamen irgendwo in der URL zu suchen. Und genau diese Gewohnheit machen sich Phisher zunutze.

Protokoll → Subdomain(s) → Domain → TLD → Pfad
     |          |           |       |      |
   HTTPS      login      beispiel  de    /auth

Entwickler verstehen das instinktiv. Normale Nutzer haben keine Chance, wenn wir URLs wie diese zur Normalität erklären:

https://auth.firma.verdächtiger-anbieter.io
https://firma.auth-anbieter.io/sso/abc123
https://auth-anbieter.io/firma-anmeldung

Die Verantwortung der Entwickler

Hier wird es relevant für dich: Du hast die Macht, Authentifizierungsabläufe zu gestalten, die Nutzer standardmäßig schützen.

Anstatt Nutzer durch ein Labyrinth von Drittanbieter-Domains zu leiten, consideriere diese Grundsätze:

1. Besitze deine Identitäts-Domain. Deine Haupt-Domain sollte die Authentifizierung abwickeln. Wenn du Drittanbieter nutzen musst, erzwinge zumindest eigene Subdomains:

✓ https://login.deinunternehmen.de
✗ https://auth.anbieter.de/deinunternehmen

2. Konsistente Subdomain-Hierarchie. Wenn deine Haupt-App unter app.firma.de erreichbar ist, sollte der Login unter auth.firma.de sein – nicht versteckt hinter der Infrastruktur eines Drittanbieters.

3. Intelligent weiterleiten. Wenn du zu externen Services verlinken musst (Umfragen, Zahlungsabwickler, Support-Portale), nutze serverseitige Redirects von deiner eigenen Domain. Das gibt Nutzern ein konsistentes Erlebnis und verstärkt: "Was nicht von unserer Domain kommt, gehört nicht zu uns."

4. SMS und Telefonnummern genauso behandeln. "Nennen Sie diese Nummer" oder "Schreiben Sie diesen Code"-Nachrichten sind genauso gefährlich wie E-Mail-Links. Stelle immer Kontaktinformationen auf einer Seite bereit, die deine Nutzer bereits kennen.

Sicherheit bauen, die mit Nutzern skaliert – nicht gegen sie

Die RFC 2119-Terminologie ist kein bürokratisches Gerede – sie ist eine Design-Philosophie. Wenn Authentifizierungssicherheit ein "SOLLTE" statt ein "MUSS" ist, entsteht genau die Situation, die wir heute haben: ein Wildwest föderierter Identitätsdienste, bei dem legitime Seiten kaum von Betrug zu unterscheiden sind.

Die Organisationen, die bei Sicherheit gewinnen werden, sind diejenigen, die aufhören, Nutzer als schwächstes Glied zu behandeln, und anfangen, Systeme zu bauen, die das sichere Verhalten zum einfachen Verhalten machen.

Denn die Realität ist: Du kannst dich nicht mit Sicherheitsschulungen aus einem Designproblem heraustrainieren.

Was das für dein Startup oder Unternehmen bedeutet

Wenn du Authentifizierungsabläufe baust oder wartest, ist jetzt der Zeitpunkt für ein Audit. Frag dich:

• Kann ein Erstnutzer deine Login-Seite allein anhand der URL identifizieren?
• Führen alle authentifizierten Erlebnisse durch Domains, die deine Nutzer kennen?
• Nutzt du BYO-Domain-Funktionen von Drittanbietern, oder akzeptierst du deren Standard-URLs?

Das hier geht nicht nur um Security-Theater – es geht um Vertrauen. Nutzer, die sich bei deinem Authentifizierungserlebnis sicher fühlen, vertrauen deinem Produkt.

Bei NameOcean haben wir gesehen, wie Domain-Strategie und Sicherheitsarchitektur zusammenhängen. Deine Domain ist nicht nur eine Adresse – sie ist das Fundament von Nutzervertrauen. Stell sicher, dass sie für dich arbeitet, nicht gegen dich.