Passwort-Manager vs. Passkeys: Wo stehen wir wirklich?

Seit Apple, Google und Microsoft 2022 gemeinsam Passkeys ankündigten, überschlagen sich die Schlagzeilen: "Das Ende des Passworts", "Phishing unmöglich gemacht", "Die Zukunft der Authentifizierung". Technisch ist das alles korrekt. Die praktische Realität von 2026 ist differenzierter — und Passwort-Manager sind noch nicht bereit für den Ruhestand.

Was Passkeys technisch sind

Passkeys sind eine Implementierung des FIDO2-Standards, genauer: der WebAuthn-API (Web Authentication). Statt eines Passworts, das auf einem Server gespeichert und durch Phishing gestohlen werden kann, basieren Passkeys auf asymmetrischer Kryptographie:

Bei der Registrierung erzeugt dein Gerät ein Schlüsselpaar: privater Schlüssel (bleibt auf dem Gerät) und öffentlicher Schlüssel (wird beim Dienst hinterlegt)
Beim Login sendet der Dienst eine zufällige Challenge
Dein Gerät signiert die Challenge mit dem privaten Schlüssel — nach Biometrie-Freigabe (Fingerabdruck, Face ID, Windows Hello)
Der Dienst prüft die Signatur mit dem öffentlichen Schlüssel

Das Ergebnis: Der private Schlüssel verlässt das Gerät nie. Phishing funktioniert nicht, weil der Schlüssel origin-gebunden ist — eine gefälschte Login-Seite auf app1e.com bekommt niemals eine gültige Signatur für apple.com.

Discoverable Credentials vs. Non-Discoverable

Ein technisches Detail, das in den meisten Artikeln fehlt: Es gibt zwei Arten von FIDO2-Credentials. Non-Discoverable Credentials (auch "server-side" oder "resident key = false") speichern den verschlüsselten privaten Schlüssel auf dem Server — das Gerät speichert nur einen Schlüssel zur Entschlüsselung. Discoverable Credentials (Passkeys im Sinne von Apple/Google) speichern alles auf dem Gerät oder in der Cloud-Synchronisation.

Discoverable Credentials ermöglichen echtes "Password-free Login" ohne Benutzername — das Gerät weiß selbst, welche Credentials für welche Site relevant sind. Das ist die nutzerfreundliche Variante, die Apple und Google meinen, wenn sie von "Passkeys" sprechen.

Synchronisation: Apples iCloud Keychain, Googles Password Manager, Windows

Passkeys auf einem iPhone werden in der iCloud Keychain synchronisiert — verschlüsselt, über alle Apple-Geräte verfügbar. Analoges gilt für Google Password Manager auf Android. Microsoft synchronisiert via Windows Hello Business in Enterprise-Umgebungen.

Das klingt praktisch, hat aber eine implizite Plattformbindung: iPhone-Passkeys sind nicht ohne weiteres auf Android nutzbar und umgekehrt. Das FIDO Alliance hat mit dem "Cross-Device Authentication"-Standard nachgebessert — ein QR-Code ermöglicht das Nutzen eines anderen Geräts zur Authentifizierung. Aber reibungslos ist das noch nicht.

Bitwarden und 1Password unterstützen inzwischen Passkeys als Passkey-Manager — plattformübergreifend, ohne Herstellerbindung. Das ist für ernsthafte Nutzer die richtige Lösung.

Wo Passkeys noch nicht funktionieren

Stand 2026 unterstützen die meisten großen Dienste Passkeys: Google, Apple, Microsoft, GitHub, PayPal, viele Banken. Aber:

Viele kleinere Dienste und Unternehmens-Apps haben Passkeys noch nicht implementiert
SSH unterstützt FIDO2-Hardware-Keys (YubiKey), aber keine Cloud-Passkeys
Viele Legacy-Systeme und Enterprise-Anwendungen sind Passwort-only
Sharing von Credentials (Familien-Accounts, Team-Accounts) ist bei Passkeys konzeptionell schwieriger

Passwort-Manager: Der aktuelle Stand

Die drei ernstzunehmenden Optionen 2026:

Bitwarden: Open-Source, self-hostbar (Vaultwarden als leichtgewichtige Alternative), kostengünstiger Premium-Plan, plattformübergreifend, Browser-Extensions für alle gängigen Browser. Unterstützt Passkeys. Empfehlung für Selbsthoster und alle, die Open-Source bevorzugen.

1Password: Proprietär, hervorragende UX, ausgezeichnete Team-Features, teurer. Passkey-Unterstützung gut implementiert. Für Teams und Profis, die Komfort über Kostenkontrolle stellen.

KeePassXC: Lokal, kein Cloud-Sync ohne eigene Lösung (Nextcloud, Syncthing). Maximale Kontrolle, null Abhängigkeit von Drittservices. Komplexer in der Einrichtung, null laufende Kosten.

Die realistische Empfehlung für 2026

Nicht entweder-oder, sondern eine gestaffelte Strategie:

Passwort-Manager als Basis: Bitwarden (oder 1Password) für alle Passwörter. Einzigartiges, starkes Passwort für jeden Dienst.
Passkeys wo verfügbar: Google, GitHub, Microsoft, PayPal — überall wo Passkeys angeboten werden, aktivieren. Bitwarden speichert sie plattformübergreifend.
Hardware-Key für Hochwertziele: YubiKey für Google-Account, GitHub, Banking — als FIDO2-Hardware-Authenticator, nicht ersetzbar durch Phishing, nicht durch Cloud-Kompromittierung.
TOTP als Fallback: Für Dienste ohne Passkeys, 2FA mit TOTP (Authenticator-App) statt SMS.

Fazit

Passkeys sind technisch brillant und langfristig der richtige Weg. Aber "das Passwort ist tot" ist 2026 noch Marketing, keine Realität. Passwort-Manager bleiben für Jahre unverzichtbar. Die sinnvolle Strategie: Passkeys dort nutzen wo sie verfügbar und gut implementiert sind, Passwort-Manager für den Rest, Hardware-Keys für die kritischsten Accounts.

FIDO2-Hardware-Keys: YubiKey und Alternativen

Hardware Security Keys sind physische USB/NFC-Geräte, die FIDO2/WebAuthn implementieren. Im Gegensatz zu software-basierten Passkeys (die in der Cloud synchronisiert werden) verlässt der private Schlüssel den Hardware-Key nie — er ist unveränderlich im Gerät gespeichert und kann nicht extrahiert werden.

Der YubiKey 5 (NFC + USB-A/C) ist der Marktführer. Alternativen: Google Titan Key, Nitrokey (Open-Source), OnlyKey. Für kritische Accounts (Google-Account, GitHub, Banking) ist ein Hardware-Key die sicherste mögliche Authentifizierungsmethode.

# YubiKey unter Linux einrichten
# FIDO2-Resident Key erstellen (Passkey auf Hardware)
fido2-token -L              # Verfügbare Token anzeigen
fido2-token -I /dev/hidraw0  # Token-Info anzeigen

# SSH mit FIDO2-Key (OpenSSH 8.2+)
ssh-keygen -t ed25519-sk -O resident  # resident = discoverable credential
# Erzeugt Schlüssel der auf dem YubiKey gespeichert ist
# -sk = security key

Passwort-Manager: Self-Hosting mit Vaultwarden

Wer Bitwarden self-hosten will, ohne den offiziellen Server (der relativ ressourcenintensiv ist) zu betreiben, greift zu Vaultwarden — einer Community-Implementierung des Bitwarden-Server-Protokolls in Rust.

# Vaultwarden mit Docker
docker run -d   --name vaultwarden   -e DOMAIN="https://vault.example.com"   -e SIGNUPS_ALLOWED=false   -e ADMIN_TOKEN=$(openssl rand -base64 48)   -v /opt/vaultwarden:/data   -p 127.0.0.1:8080:80   vaultwarden/server:latest

# Nginx-Reverse-Proxy davor schalten
# (Vaultwarden benötigt HTTPS für WebAuthn)

Vaultwarden läuft mit ca. 20–30 MB RAM und ist damit für kleine Server ideal. Es ist vollständig kompatibel mit den offiziellen Bitwarden-Clients — Browser-Extension, Desktop-App, Mobile-App — da es das Bitwarden-API-Protokoll implementiert.

Passkeys im Enterprise-Kontext

Für Unternehmen ist die Passkey-Einführung komplexer als im Privatbereich. Herausforderungen:

Gerätemanagement: Passkeys sind gerätegebunden (oder cloud-synchronisiert). Bei Geräteverlust muss ein Wiederherstellungsprozess definiert sein
Shared Accounts: Team-Accounts (z.B. ein gemeinsames Admin-Konto) funktionieren nicht mit Passkeys — sie sind an einzelne Personen gebunden
Legacy-Systeme: Viele Enterprise-Applikationen unterstützen nur Passwörter oder ältere MFA-Methoden
Compliance: Einige Regulierungsframeworks kennen Passkeys noch nicht und verlangen explizit Passwörter + MFA

1Password for Business und Bitwarden Teams lösen das Shared-Account-Problem teilweise: "Shared Items" können Passkeys enthalten, die von mehreren Teammitgliedern genutzt werden — über den Passwort-Manager als Vermittler.

Phishing-Resistenz: Warum Passkeys überlegen sind

Das stärkste Argument für Passkeys gegenüber Passwörtern und TOTP ist die inhärente Phishing-Resistenz. Bei einem klassischen Phishing-Angriff:

Nutzer besucht app1e.com statt apple.com
Gibt Passwort und TOTP-Code ein
Angreifer nutzt beides sofort für echten Apple-Login

Mit Passkeys schlägt Schritt 2 fehl: Der Browser (als WebAuthn-Implementierung) prüft die Origin der anfragenden Seite kryptographisch. Ein Passkey für apple.com wird für app1e.com keine gültige Signatur erzeugen — der Angriff scheitert, ohne dass der Nutzer etwas bemerken muss.

Praktische Migration: Schritt für Schritt

Passwort-Manager installieren: Bitwarden (kostenlos, open-source) oder 1Password. Alle Passwörter importieren (von Browser-Keychain, anderen Managern)
Alle Passwörter einzigartig machen: Bitwarden-Passwort-Generator für alle Accounts nutzen. Mindestens 16 Zeichen, zufällig
2FA aktivieren: Für jeden Account der es unterstützt. TOTP-App (Aegis auf Android, Raivo auf iOS) besser als SMS
Passkeys aktivieren: Für Google, GitHub, Microsoft — überall wo Passkeys angeboten werden. Im Bitwarden speichern
Hardware-Key für Hochwertziele: Mindestens für Google-Account und GitHub ein YubiKey registrieren

Sicherheitsaudit: Wie oft prüfen?

Ein Passwort-Manager ist nur so gut wie seine regelmäßige Pflege. Empfohlener Audit-Rhythmus:

Monatlich: Neue Accounts in den Manager aufnehmen, alte entfernen
Vierteljährlich: Passwörter für hochwertige Accounts rotieren (Banking, E-Mail, Domain-Registrar)
Bei Data-Breach-Meldung: Sofortiger Passwortwechsel für betroffene Services. Bitwarden und 1Password integrieren HaveIBeenPwned-Checks
Jährlich: Hardware-Security-Keys prüfen, Recovery-Codes testen, Backup des Passwort-Tresors verifizieren

# Bitwarden CLI: Schwache und doppelte Passwörter finden
bw login
bw list items | python3 -c "
import json, sys, collections
items = json.load(sys.stdin)
passwords = [i['login']['password'] for i in items if i.get('login',{}).get('password')]
dupes = {p: c for p, c in collections.Counter(passwords).items() if c > 1}
print(f'Doppelte Passwörter: {len(dupes)}')
print(f'Schwache (< 12 Zeichen): {sum(1 for p in passwords if len(p) < 12)}')"

Notfall-Zugang: Was wenn der Passwort-Manager nicht erreichbar ist?

Ein oft vergessenes Szenario: Was wenn der Bitwarden-Server (ob self-hosted oder Cloud) nicht erreichbar ist und man dringend auf einen Account zugreifen muss? Strategien:

Offline-Zugriff: Bitwarden-Desktop-App und Browser-Extension cachen den Tresor lokal. Offline-Zugriff auf gespeicherte Passwörter ist möglich, neue Passwörter werden synchronisiert sobald die Verbindung wieder besteht
Emergency Sheet: Die 5–10 kritischsten Passwörter (E-Mail, Banking, Passwort-Manager-Master) auf Papier, verschlüsselt aufbewahrt
Recovery-Codes: Für jeden Account mit 2FA die Recovery-Codes sicher speichern — getrennt vom Passwort-Manager

TOTP vs. Passkeys: Direkte Gegenüberstellung

Für Accounts die weder Passkeys noch Hardware-Keys unterstützen, ist TOTP (zeitbasierte Einmalpasswörter via Authenticator-App) der beste verfügbare zweite Faktor. Im Vergleich zu Passkeys:

Phishing-Resistenz: TOTP ist phishbar (ein Angreifer kann den Code in Echtzeit abfangen), Passkeys nicht
Geräteverlust: TOTP: Recovery-Codes oder Backup-Authenticator. Passkeys: Recovery-Codes oder alternatives Gerät
Komfort: TOTP erfordert App-Wechsel, Passkeys sind in den Login-Flow integriert
Verbreitung: TOTP ist überall verfügbar, Passkeys noch nicht

Keepass-Ökosystem: Wenn Cloud nicht in Frage kommt

Für Nutzer, die absolut keine Cloud-Synchronisation wollen, ist das KeePass-Ökosystem die Antwort. KeePass ist Open-Source, speichert die Datenbank lokal als verschlüsselte .kdbx-Datei, und hat keinerlei Server-Abhängigkeit. Die Synchronisation zwischen Geräten erfolgt über eigene Mittel.

KeePassXC: Plattformübergreifend (Windows/Linux/Mac), moderne UI, Browser-Integration, TOTP-Support
KeePassDX: Android-Client, stark, keine Cloud-Abhängigkeit
Strongbox: iOS-Client, ebenfalls .kdbx-kompatibel
Synchronisation: Syncthing (P2P, kein Server), Nextcloud, Samba-Share — die .kdbx-Datei liegt wo man sie haben will

# KeePassXC: Datenbank erstellen und sichern
# CLI-Interface für Automation
keepassxc-cli db-create -p /path/to/database.kdbx

# Eintrag hinzufügen
keepassxc-cli add -p /path/to/database.kdbx "Email/Gmail"

# Passwort abrufen (für Scripte)
keepassxc-cli show -s -a password /path/to/database.kdbx "Email/Gmail"

Der Angriff auf Passwort-Manager: Was wirklich gefährlich ist

LastPass hatte 2022 einen schwerwiegenden Breach: Angreifer stahlen verschlüsselte Tresore. Die Daten sind verschlüsselt — aber die Verschlüsselung ist nur so stark wie das Master-Passwort. LastPass-Nutzer mit schwachen Master-Passwörtern sind real gefährdet.

Die Lektion: Der Passwort-Manager ist nur so sicher wie sein Master-Passwort. Empfehlungen:

Master-Passwort: mindestens 20 Zeichen, Diceware-Passphrase (6 zufällige Wörter)
MFA für den Passwort-Manager selbst aktivieren
Self-hosted Lösungen (Vaultwarden) reduzieren die Angriffsfläche
Bitwarden und 1Password haben starke Kryptographie (AES-256, PBKDF2 mit hohen Iterationszahlen)

# Diceware-Passphrase generieren (6 Würfelwörter)
# Unter Linux mit der EFF-Wortliste:
for i in {1..6}; do
  echo -n "$(shuf -n 1 /usr/share/dict/words) "
done
echo

# Oder mit Python
python3 -c "
import secrets
words = open('/usr/share/dict/words').read().split()
passphrase = ' '.join(secrets.choice(words) for _ in range(6))
print(passphrase)"

Recovery-Szenarien durchdenken

Der häufigste Grund warum Menschen keinen Passwort-Manager nutzen: Angst vor dem Aussperrungsszenario. Was wenn das Master-Passwort vergessen wird? Was wenn das Gerät mit dem Passwort-Manager kaputt ist? Diese Szenarien haben Lösungen:

Encrypted backup: Bitwarden-Export (verschlüsselt) monatlich auf einem USB-Stick
Emergency Sheet: Die 5 wichtigsten Passwörter handschriftlich, in einem Umschlag beim Notar oder einem Vertrauensperson
Zweites Gerät: Bitwarden auf Telefon und Laptop — Ausfall eines Geräts blockiert nicht alles
Account Recovery: Bitwarden Premium hat einen "Emergency Access" — eine Vertrauensperson kann nach definierter Wartezeit Zugang beantragen

Die Prognose: Wie sich das Ökosystem entwickelt

Die nächsten drei bis fünf Jahre werden entscheidend für die Passkey-Adoption sein. Apple, Google und Microsoft haben sich alle committet — das bedeutet, dass Passkeys auf praktisch allen Endgeräten verfügbar sein werden. Die Frage ist, wann Dienste und Unternehmens-IT nachziehen.

Realistisch gesehen: Passwörter werden noch eine Dekade relevanter Teil der Authentifizierungslandschaft bleiben. Legacy-Systeme, Enterprise-Anwendungen, und das schiere Volumen bestehender Passwort-basierter Accounts garantiert das. Passwort-Manager sind also noch lange nicht obsolet — aber sie werden zunehmend zu Passkey-Managern mit Passwort-Kompatibilitätsmodus.

Die pragmatische Strategie für 2026: Passkeys aktivieren wo verfügbar, Passwort-Manager als Fundament behalten, Hardware-Key für die kritischsten Accounts. Wer das umsetzt, ist für die nächste Phase der Authentifizierungslandschaft gut aufgestellt — egal in welche Richtung die Entwicklung geht.

Die Transition von Passwörtern zu Passkeys ist nicht schlagartig, sondern fließend. Passwort-Manager werden dabei noch lange eine zentrale Rolle spielen — als Brücke zwischen der alten Passwort-Welt und der neuen Passkey-Welt, als Tresor für Accounts die noch keine Passkeys unterstützen, und als Backup-Mechanismus wenn Passkeys nicht verfügbar sind. Wer heute einen guten Passwort-Manager nutzt und Passkeys aktiviert wo sie angeboten werden, ist optimal positioniert für jeden nächsten Schritt dieser Entwicklung.

Zusammenfassung: Bitwarden als Passwort- und Passkey-Manager, YubiKey für die wichtigsten Accounts, TOTP als Fallback. Diese drei Schichten ergeben eine Authentifizierungssicherheit die den Aufwand von Phishing und Credential-Stuffing erheblich erhöht — ohne im Alltag nennenswert umständlicher zu sein.