Zwei-Faktor-Verfahren sind nicht gleich gut. Der Unterschied ist nicht Bequemlichkeit, sondern ob das Verfahren gegen Weiterleitung schützt, also gegen den Angriff, der gerade tatsächlich läuft: eine nachgebaute Anmeldeseite, die deine Eingabe in Echtzeit an die echte Seite weiterreicht, Einmalcode inklusive.
Sobald eine Verwaltungsoberfläche von außen erreichbar ist, ist die Anmeldung die gesamte Verteidigung. SMS und Einmalcodes lassen sich in Echtzeit weiterreichen; ein an die Domain gebundener Schlüssel nicht, der Angreifer bekommt eine Signatur, die für seine gefälschte Adresse ungültig ist.
Die Rangfolge#
| Verfahren | Schützt gegen geratenes Passwort | Schützt gegen Weiterleitung |
|---|---|---|
| SMS-Code | ja | nein (zusätzlich: Nummernübernahme) |
| TOTP-App (6 Ziffern) | ja | nein |
| Push-Bestätigung „Ja/Nein“ | ja | nein (Ermüdungsangriff) |
| WebAuthn / Passkey / FIDO2-Schlüssel | ja | ja |
TOTP ist trotzdem besser als nichts und für Dienste ohne WebAuthn die richtige Wahl. Nur sollte niemand glauben, damit gegen Phishing geschützt zu sein.
Für Verwaltungsoberflächen#
Erst die Erreichbarkeit begrenzen (Verwaltungsoberflächen im Internet), dann den zweiten Faktor, in dieser Reihenfolge, weil der Faktor eine Anmeldemaske schützt, die idealerweise gar nicht öffentlich steht.
Praktisch bedeutet das je Oberfläche:
- Proxmox: TOTP oder WebAuthn je Benutzer, Zwang über die Realm-Einstellung.
- Anwendungen hinter Proxy: zweiter Faktor kann im Proxy sitzen (Authentifizierungsschicht davor), wenn die Anwendung selbst keinen mitbringt.
- Registrare, Paketregister, Cloud-Konten: hier zuerst, sie sind die Konten, über die man alles andere verliert.
Für SSH: der Schlüssel wandert in die Hardware#
OpenSSH kann seit Version 8.2 Schlüssel erzeugen, deren privater Teil das Token nie verlässt (ecdsa-sk, ed25519-sk). Der Schlüssel ist dann kein Dateiproblem mehr, ein kopiertes Laptop-Verzeichnis reicht nicht.
# Schlüssel im Token, Bestätigung per Berührung
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "$(whoami)@laptop-token"
# Öffentlichen Teil auf den Server, wie gewohnt
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub benutzer@host# sshd_config: nur Token-Schlüssel akzeptieren (wenn alle umgestellt sind)
PubkeyAcceptedKeyTypes [email protected],[email protected]
Dieselbe Regel wie bei Passwort-Login abschalten: zweite Sitzung offen lassen, mit einer dritten testen, und die Konsole des Anbieters einmal wirklich benutzt haben. Ein zweiter registrierter Token oder ausgedruckte Wiederherstellungscodes gehören dazu, bevor der erste Zwang aktiv wird, ein verlorenes Token ohne Zweitweg ist ein Totalverlust des Zugangs.
Alternative ohne Token: zweiter Faktor über TOTP für SSH#
Wo keine Hardware vorhanden ist, kann SSH einen Einmalcode zusätzlich zum Schlüssel verlangen:
sudo apt install libpam-google-authenticator
google-authenticator -t -d -f -r 3 -R 30 -W # je Benutzer# /etc/pam.d/sshd
auth required pam_google_authenticator.so nullok
# /etc/ssh/sshd_config
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Das ergibt Schlüssel und Code. Für Dienstkonten und automatisierte Abläufe ist das ungeeignet, die bekommen eigene, eingeschränkte Schlüssel (SSH-Schlüssel verwalten) oder laufen über einen Sprungserver.
Was der zweite Faktor nicht ersetzt#
Er schützt die Anmeldung. Er schützt nicht die Sitzung danach, kein API-Token, keinen im Repo liegenden Schlüssel (Geheimnisse gehören nicht ins Repo) und keine Lücke in der Software selbst. Wer beides zusammenlegt, Erreichbarkeit begrenzen und Anmeldung härten, schließt den Weg, der bei kleinen Betrieben am häufigsten funktioniert.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
