Wer meldet sich an – und was darf diese Person?
Eine Nachricht behauptet, dein Konto werde heute gesperrt. Der Link führt zu einer täuschend ähnlichen Anmeldeseite. Du hast ein langes Passwort und einen Zahlencode auf dem Telefon: Reicht das? Die Antwort hängt davon ab, was dein Anmeldeverfahren tatsächlich prüft. Ein zusätzliches Feld kann einen gestohlenen Passwortdatensatz weniger gefährlich machen und trotzdem bei einer live weitergeleiteten Anmeldung versagen.
Identifikation benennt zunächst das behauptete Konto, beispielsweise über einen Benutzernamen. Authentifizierung prüft einen Nachweis dafür, dass du einen diesem Konto zugeordneten Authentifikator kontrollierst. Autorisierung entscheidet anschließend über erlaubte Aktionen. Eine erfolgreiche Anmeldung ist deshalb keine Berechtigung, jede Datei zu öffnen oder neue Administratoren anzulegen. Das Konto verbindet Identifikator, Anmeldemittel und Rechte; es ist nicht mit einer einzelnen E-Mail-Adresse oder einem Gerät gleichzusetzen.
Im Betrieb hilft diese Trennung beim Fehlersuchen: „Passwort akzeptiert, Zugriff verweigert“ kann ein Berechtigungsproblem sein. „Konto nicht gefunden“ betrifft womöglich den falschen Mandanten. Administrative Rechte sollten über ein getrenntes Konto und nur für erforderliche Aufgaben verfügbar sein. Dieses Prinzip heißt Least Privilege. Wie Rechte und Konten unter Linux zusammenhängen, erklärt Benutzer, Rechte und SSH.
Ein Passwort muss lang und pro Dienst einzigartig sein.
Ein Passwort ist ein wiederverwendbares Geheimnis. Wer es kennt, kann es grundsätzlich ebenfalls vorlegen. Länge erschwert das Erraten; Einzigartigkeit begrenzt den Schaden eines Datenlecks. Beim Credential Stuffing werden bereits bekannte Kombinationen aus Konto und Passwort bei anderen Diensten ausprobiert. Ein besonders kompliziertes Passwort verliert diesen Vorteil, wenn du es überall wiederverwendest. Kleine Varianten desselben Grundworts sind ebenfalls vorhersehbar.
Ein Passwortmanager kann für jedes Konto einen eigenen zufälligen Wert erzeugen und speichern. Du musst diese Werte nicht auswendig lernen. Für das zentrale Tresorpasswort eignet sich eine lange, eigenständige und nicht aus einem bekannten Zitat übernommene Passphrase. Geräteschutz, Updates, Tresorsperre und ein vorbereiteter Wiederherstellungsweg gehören dazu. Prüfe, für welche Website ein Manager das Ausfüllen anbietet. Ein unerwartet leeres Feld ist ein Anlass, die Adresse zu kontrollieren; die Erkennung ist kein Freibrief, jede andere Warnung zu ignorieren.
Die finale NIST SP 800-63B-4 unterscheidet Mindestlängen nach Einsatz: Bei alleiniger Passwortanmeldung verlangt sie mindestens 15 Zeichen, bei Passwörtern als Teil einer MFA mindestens acht. Das sind Anforderungen innerhalb ihres Anwendungsrahmens, keine Empfehlung, eigene lange Passwörter auf acht Zeichen zu kürzen. NIST fordert Sperrlisten für häufige oder kompromittierte Werte und lehnt willkürliche Zusammensetzungsregeln sowie regelmäßige Wechsel ohne Anlass ab. Bei einem erkannten Abfluss muss das betroffene Passwort dagegen ersetzt werden. Diese Aussagen beziehen sich ausdrücklich auf die finale Revision 4, nicht auf ältere Entwürfe.
Praktisch beginnt die Absicherung bei den Konten, die andere Konten zurücksetzen können: E-Mail, Passwortmanager und zentrale Anmeldung. Danach folgen Verwaltung, Finanzen und weitere sensible Dienste. Erstelle dafür eine eigene Bestandsliste ohne Geheimnisse: Dienst, Kontoverantwortung, erlaubte Anmeldemethoden, Recovery und Datum der letzten Prüfung. Diese Dokumentation hilft auch bei einem Gerätewechsel.
Der Server braucht einen Prüfwert, kein lesbares Passwort.
Ein Dienst sollte Passwörter weder im Klartext noch lediglich reversibel verschlüsselt ablegen. Stattdessen berechnet er mit einer geeigneten Passwortfunktion einen Prüfwert. Ein zufälliges Salt pro gespeichertem Passwort verhindert, dass gleiche Passwörter automatisch gleiche Prüfwerte ergeben und vorberechnete Tabellen beliebig wiederverwendbar sind. Das Salt darf zusammen mit dem Prüfwert gespeichert werden. Es ist kein Ersatz für ein starkes Passwort.
Argon2id ist eine dafür entwickelte speicherintensive Passwortfunktion. Arbeitsspeicher, Rechenaufwand und Parallelität sind einstellbar; jede Vermutung soll ausreichend teuer werden. Parameter müssen anhand aktueller Bibliotheken, verfügbarer Ressourcen und erwarteter Last bewusst gewählt und später aktualisiert werden. Ein schneller SHA-256-Hash allein erfüllt diesen Zweck nicht. Betreiber sollten bewährte Bibliotheken verwenden und keine eigene Passwortprüfung erfinden. Die technischen Unterschiede vertieft Verschlüsselung, Hashing und Signaturen.
Bei der Anmeldung wird der Prüfwert mit dem gespeicherten Salt und denselben Parametern erneut berechnet und sicher verglichen. Das Passwort muss dabei über einen geschützten Kanal zum Dienst gelangen; HTTPS und TLS schützt diesen Transport. Nach einem Diebstahl der Passwortdatenbank können Angreifer trotzdem offline raten. Ratenbegrenzung am Login hilft gegen Onlineversuche, bremst aber keine bereits kopierte Datenbank. Darum ergänzen sich Passwortqualität, sichere Speicherung und weitere Anmeldenachweise.
Zwei Faktoren sind mehr als zwei Eingabefelder.
Multi-Faktor-Authentifizierung, kurz MFA, kombiniert unterschiedliche Faktortypen: Wissen wie ein Passwort, Besitz wie ein Authentifikator und ein biometrisches Merkmal. Passwort plus Sicherheitsfrage bleibt zweimal Wissen. Ein Telefon ist nicht allein deshalb ein zweiter Faktor, weil eine Webseite auf seinem Bildschirm geöffnet wird. Entscheidend ist, welcher Besitznachweis tatsächlich an der Anmeldung beteiligt ist und wie dessen Nutzung freigegeben wird.
Bei TOTP berechnen App und Server aus einem gemeinsamen geheimen Startwert und dem aktuellen Zeitabschnitt einen kurzen Einmalcode. Der Startwert aus der Einrichtung, häufig in einem QR-Code dargestellt, ist dauerhaft schützenswert. Wer ihn kopiert, kann weitere Codes erzeugen. Der Server benötigt Zugriff auf dieses Geheimnis, anders als bei einem bloßen Passwortprüfwert. Kleine Zeitabweichungen werden je nach Implementierung toleriert; große Abweichungen erklären manche abgelehnten Codes. Ein bereits verwendeter Code darf im Gültigkeitsfenster nicht erneut akzeptiert werden.
Passwort plus TOTP schützt beispielsweise dann, wenn nur das Passwort aus einem fremden Dienst bekannt ist. Manuell eingegebene TOTP-Codes sind nicht phishingresistent. Eine gefälschte Seite kann Passwort und gerade gültigen Code sofort an den echten Dienst weiterleiten. Kurze Gültigkeit begrenzt die Zeit, bindet den Code aber nicht an die richtige Website.
Push-Verfahren fordern eine Bestätigung auf einem registrierten Gerät an. Eine unerwartete Anfrage wird abgelehnt und über einen bekannten Kontaktweg gemeldet. Wiederholte Anfragen können Menschen zur Zustimmung drängen. Nummernabgleich und aussagekräftige Transaktionsinformationen verbessern einfache Ja/Nein-Abfragen, machen eine beliebige Push-Methode aber nicht automatisch phishingresistent. Die tatsächlichen Protokolleigenschaften zählen. SMS bringt zusätzlich Risiken rund um Rufnummernübernahme und Zustellung mit; ein vorhandener besser geschützter Faktor sollte bewusst bevorzugt werden.
Drei Abläufe: Welcher Nachweis landet wo?
| Verfahren | Beim Nutzer | Beim Dienst | Grenze |
|---|---|---|---|
| Passwort | Passwort im Gedächtnis oder Manager | Salt, Parameter und Passwortprüfwert; Prüfung des übertragenen Passworts | Abgreifbares, wiederverwendbares Geheimnis |
| Passwort + TOTP | Passwort und TOTP-Startgeheimnis in der App | Passwortprüfwert und geschütztes TOTP-Geheimnis; Prüfung beider Eingaben | Echtzeitweiterleitung bleibt möglich |
| Passkey/WebAuthn | Privater Schlüssel im Authentifikator beziehungsweise geschützten Passkey-Anbieter | Öffentlicher Schlüssel und Kontozuordnung; Prüfung von Signatur, Challenge, RP-ID, Origin und geforderten Flags | Recovery, Endgerät und Sitzung bleiben eigene Angriffsflächen |
Ein Passkey beweist Schlüsselbesitz für den richtigen Dienst.
WebAuthn ist die Browser-Schnittstelle für öffentliche Anmeldeschlüssel. Zusammen mit dem Client-to-Authenticator-Protokoll CTAP bildet sie FIDO2. Ein Passkey ist ein entsprechender Anmeldeschlüssel, mit dem eine passwortlose Anmeldung möglich wird. Beim Registrieren wird ein Schlüsselpaar erzeugt. Der Dienst, die Relying Party oder RP, erhält den öffentlichen Schlüssel und ordnet ihn dem Konto zu. Der private Schlüssel wird nicht als Anmeldegeheimnis an diesen Dienst übertragen.
Beim späteren Login sendet der Dienst eine frische Challenge. Der Authentifikator signiert nach der erforderlichen Freigabe einen Nachweis, der unter anderem RP-bezogene Authentifikatordaten und die gebundenen Clientdaten abdeckt. Der Browser kontrolliert die zulässige RP-ID im Verhältnis zur aufrufenden Domain; der Server prüft die erwartete Origin, Challenge, Signatur und verlangte Benutzerverifikation. Die Origin bezeichnet Schema, Host und Port; die RP-ID bezeichnet den zulässigen Domainbereich des Schlüssels. Beide Begriffe sind verwandt, aber nicht austauschbar.
Eine ähnlich geschriebene fremde Domain erhält dadurch keinen verwendbaren Nachweis für den legitimen Dienst. Das ist der Kern der Phishingresistenz: Der Nutzer muss kein übertragbares Geheimnis in ein fremdes Formular eintippen. Die Prüfungen müssen korrekt implementiert sein. Sonderfunktionen wie bewusst eingerichtete Related Origins ändern die erlaubten Beziehungen nicht beliebig. Eine kompromittierte legitime Website oder ein vollständig übernommenes Endgerät liegt außerdem außerhalb des einfachen Phishingvergleichs.
Fingerabdruck, Gesichtserkennung oder Geräte-PIN können die lokale Nutzung freigeben. Biometrische Daten werden dabei nicht als Fingerabdruck an den Webserver geschickt. Der Server erhält einen kryptografischen Nachweis und Angaben zur erfolgten Verifikation. Schlüsselbesitz plus lokale Verifikation kann mehrere Faktoren in einem Authentifikator verbinden; ein bloßes Berühren eines Schlüssels belegt dagegen nicht automatisch dieselbe Benutzerverifikation. Deshalb lässt sich das Sicherheitsniveau nicht allein am Wort „Passkey“ ablesen.
Gerätegebundene Passkeys verbleiben auf einem bestimmten Authentifikator, etwa einem geeigneten Hardware-Sicherheitsschlüssel. Synchronisierbare Passkeys können geschützt über den Anbieter auf weitere eigene Geräte gelangen. Das erleichtert Wiederherstellung, erweitert aber die Vertrauensbeziehung auf Synchronisationskonto, dessen Geräteaufnahme und Recovery. Passkeys sind daher nicht pauschal an ein einziges Telefon gebunden. Für besonders privilegierte Konten kann eine Vorgabe nicht exportierbarer Hardware-Schlüssel sinnvoll sein; die Organisation muss diese Entscheidung mit Nutzbarkeit und Notfallzugang abstimmen.
Praxis: Eine Nachricht will deine Anmeldung erzwingen.
Im rein gedanklichen Beispiel heißt der echte Dienst konto.example; die Nachricht führt auf konto-pruefung.example. Es werden keine Konten, echten Eingaben oder nachgebauten Loginformulare verwendet. Schließe den Nachrichtenlink und öffne den Dienst über einen vorher bekannten Zugang. Vergleiche dort Hinweise und melde den Verdacht über einen unabhängig bekannten Weg. Auch die falsche Seite kann HTTPS besitzen: Das bestätigt ihre eigene Verbindung, nicht die behauptete Zugehörigkeit.
Mit Passwort kann die fremde Seite einen unmittelbar verwendbaren Wert erhalten. Bei Passwort plus TOTP kann sie zusätzlich den aktuellen Code an den echten Dienst durchreichen und dort eine Sitzung eröffnen. Ein korrekt eingerichteter WebAuthn-Passkey für konto.example steht der anderen Domain nicht für diese Anmeldung zur Verfügung. Wenn die fremde Seite stattdessen „Aus Sicherheitsgründen Passwort und Recovery-Code eingeben“ fordert, versucht sie, auf einen schwächeren Wiederherstellungsweg auszuweichen. Gib auch dort nichts ein.
Falls bereits Daten eingegeben wurden, gehört zur Reaktion mehr als das Schließen des Tabs: Über einen vertrauenswürdigen Zugang das betroffene Passwort ändern, aktive Sitzungen und registrierte Anmeldemittel prüfen sowie den zuständigen Support beziehungsweise die IT informieren. Welche Sitzungen widerrufen und welche Recovery-Wege ersetzt werden müssen, hängt vom tatsächlich offengelegten Nachweis ab. Eine fremde erfolgreiche Anmeldung ist ein Vorfall, auch wenn das Passwort inzwischen geändert wurde.
Recovery und Sitzungen gehören zur Kontosicherheit.
Registriere, soweit der Dienst es unterstützt, einen zweiten unabhängigen Authentifikator. Bewahre einmalige Recovery-Codes getrennt und zugriffsgeschützt auf. Speichere sie nicht ausschließlich auf dem Gerät, dessen Verlust sie überbrücken sollen. Prüfe den vorgesehenen Ablauf und die Zuständigkeit, ohne den letzten funktionierenden Zugang zu entfernen. Beim Anbieterwechsel muss außerdem klar sein, welche Passkeys übertragbar sind und welche neu registriert werden müssen.
Nach erfolgreicher Anmeldung erhält der Browser häufig eine Sitzung mit einem Sitzungstoken. Wer einen gültigen Token stiehlt, kann unter Umständen die bereits erfolgte MFA umgehen. Updates, Schutz vor Schadsoftware, abgesicherte Cookies und serverseitige Sitzungsbegrenzung bleiben wichtig. Logout sollte die betreffende Sitzung beim Dienst beenden; „alle Geräte abmelden“ und das Sperren eines verlorenen Authentifikators sind davon getrennte Funktionen. Browserfenster schließen oder einen Passkey löschen widerruft nicht zwangsläufig alle vorhandenen Sitzungen.
Typische Fehler sind gemeinsame Administratorkonten, unbestätigte Geräteaufnahmen, Recovery nur über ein schlecht geschütztes E-Mail-Konto und dauerhaft offene Sitzungen auf fremden Rechnern. Auch eine sehr starke Anmeldung begrenzt keine bereits zu weit vergebenen Rechte. Für Serverzugänge gelten dieselben organisatorischen Fragen; Linux-Server administrieren ergänzt Betrieb, Protokollierung und Änderungen.
Entscheidungen selbst begründen
Aufgabe 1: Verhindert ein frischer TOTP-Code die Weiterleitung?
Eine falsche Seite verlangt Passwort und den gerade angezeigten Code. Beide werden sofort an den echten Dienst weitergereicht. Erkläre, warum der kurze Zeitablauf nicht genügt und welche Eigenschaft ein Passkey ergänzt.
Lösung
Der Code kann während seines Gültigkeitsfensters beim echten Dienst eintreffen. TOTP bestätigt das gemeinsame Startgeheimnis und die Zeit, aber nicht die Domain des Formulars. WebAuthn bindet den kryptografischen Nachweis an die zulässige RP-ID und die geprüfte Origin. Ein Nachweis der fremden Domain passt deshalb nicht zum echten Dienst. Sicheres Verhalten bleibt: abbrechen, bekannten Zugang verwenden und melden.
Aufgabe 2: Das einzige Telefon geht verloren. Was fehlt im Plan?
Passkeys, E-Mail-Recovery und Recovery-Codes liegen ausschließlich auf diesem Telefon. Ein Passwortwechsel soll „alle Zugänge erledigen“. Welche zwei Denkfehler liegen vor?
Lösung
Erstens teilen alle Wiederherstellungswege denselben Ausfallpunkt. Ein vorher registrierter, getrennt verwahrter Ersatz-Authentifikator und ein erreichbarer geschützter Recovery-Weg fehlen. Zweitens sind Passwort, Authentifikatorregistrierung und Sitzung verschiedene Zustände. Über den sicheren Ersatzweg müssen verlorene Anmeldemittel gesperrt, aktive Sitzungen geprüft beziehungsweise widerrufen und Recovery-Wege kontrolliert werden. Ein Passwortwechsel allein garantiert das nicht.
Quellen und fachlicher Stand
Fachlich geprüft am . Die Beispiele sind fiktiv; es findet keine Authentifizierung statt.
- NIST SP 800-63B-4, finale Veröffentlichung vom 31.07.2025: Passwortanforderungen, Faktortypen, Phishingresistenz, Recovery und Sitzungen; ergänzend die aktuelle HTML-Fassung, insbesondere Abschnitte 3–5 und Anhang B. CSRC verweist seit 06.10.2026 auf neue Implementierungshilfen.
- W3C WebAuthn Level 3, Recommendation vom 25.08.2026: RP-ID, Origin, Registrierung, Anmeldung und Benutzerverifikation, insbesondere Abschnitte 5, 6 und 7.
- FIDO Alliance: Passkeys: Passkey-Typen und plattformübergreifende Einordnung. Die Sicherheit von Sync und Recovery muss gesondert bewertet werden.
- RFC 6238: TOTP, Mai 2011: gemeinsames Geheimnis und Zeitfenster.
- RFC 9106: Argon2, September 2021: Argon2id, Salt und Ressourcenparameter. Konkrete Produktionsparameter sind kein Bestandteil dieses Lernbeispiels.