Going Passwordless with Passkeys: Erlebt Ihr auch so viele Kinderkrankheiten?

Sicherheit
1

Nach meinen ersten Gehversuchen mit Passkeys (und das nur mit den absoluten Big Players) muss ich hier mal einen Rant loslassen. Warum nennen die sich FIDO-„Alliance“, wenn jeder sein eigenes Süppchen kocht und ein verlässlicher Login von vielen verschiedenen Faktoren abhängt, also lauter ‚single points of failure‘ mitbringt? Microsoft kann es, muss man neidlos anerkennen: Passkey im Browser angelegt, in KeePassXC abgelegt und den Account auf „passwordless“ geschaltet (eine Option, die man bei kaum einem anderen Anbieter überhaupt hat – bitte zurückmelden, wenn jemandem das auch woanders gelungen ist).

Amazon und Google folgen nicht einmal der Spezifikation für Passkeys im strengen Sinne, indem sie nämlich keine „discoverable credentials“ anbieten. Das Feld Username muss zwingend ausgefüllt werden, bevor die Passkey-Abfrage kommt. Hat man einen zweiten Faktor eingerichtet, fragt Amazon sogar NACH der Passkey-Authentication noch einen TOTP-Code ab, was ebenfalls nicht im Sinne der Spezifikation ist. Passkeys gelten in sich als multifaktoriell, was sie unter anderem auch so sicher macht. Da ich im Gegensatz zu Microsoft mein Passwort nicht löschen kann, werde ich TOTP auch nicht deaktivieren.

Ganz schlimm ist schließlich Apple: Im Browser kann ich erst gar keinen Passkey anlegen, sondern exklusiv mit Hardware, auf der MacOS, iOS oder iPadOS läuft. Habe ich das gemacht, kann ich ihn nicht in Bitwarden oder KeePassXC ablegen, sondern exklusiv in Apples Keychain. Obwohl ich vier (mobile) Geräte der Marke besitze, kann ich meinen Apple-Account nicht mit einem Passkey absichern, weil ich deren Keychain überhaupt nicht aktiviert habe. Stattdessen möchte ich mit KeePassXC auf dem Desktop und KeePassium auf iOS lieber plattformübergreifende Open-Source-Software nutzen.

Auf Windows ist allerdings auch nicht immer Verlass: Auf einem hp-Notebook von 2017 mit Windows 10, TPM 2.0, Bluetooth und aktiviertem Windows-Hello kriege ich es nicht hin, mir einen QR-Code anzeigen zu lassen. Das Gerät benutze ich nur noch zu Testzwecken – hier um herauszufinden, ob ich auch ohne laufendes KeePassXC in meine Accounts komme. Was ich statt Passkey per QR angeboten bekomme, ist das Anstöpseln eines Hardwarekeys (so reagiert Discourse, also unsere Forensoftware) oder eine Abfrage des TPM-Chips per PIN. So reagieren Amazon und Microsoft und brechen dann mit einer Fehlermeldung ab, da meine Passkeys ja nicht im TPM stecken. Und nein, dort will ich sie auch nicht zusätzlich anlegen – könnte ich ja auf einem fremden Gerät auch nicht tun.

Falls jemand hier weiter weiß, bitte melden. Das Beste, was ich dazu gefunden habe, ist dieser Link, aber der kann mir nur sagen „Du musst ein TPM und Bluetooth haben, dann läuft es mit dem QR-Code“:

https://www.corbado.com/blog/passkey-troubleshooting-solutions

2 „Gefällt mir“
2

Ich kann deinen Rant (leider) gut nachvollziehen.

Ich wünschte mir, dass Passkeys besser eingesetzt werden könnten. Ich bin da ein sehr großer Fan von.

Die User Experience bei github ist da z.B. super gut. Klick auf „Login with Passkey“, bestätigen, fertig.

Amazon mit eingeschalter 2FA ist einfach ein Witz.

Paypal schränkt die Nutzung von Passkeys im mobilen Browser so ein, dass man das zwangsweise nur mit Google-Diensten nutzen kann.
Da ich Google-frei unterwegs bin, geht das mobile bei mir also gar nicht.

Und dann wäre da noch der teils fehlende Support von Drittanbieter-Passkey-Apps (hier Bitwarden) im Zusammenspiel mit Chromium-basierten Browsern (z.B. Brave) auf mobilen Geräten. Mit Google-Account kein Problem, aber wehe man will die Passkeys nicht von Google verwalten lasse. Dann funktioniert es einfach nicht. Im Chromium-Bugtracker steht das seit Jahren auf der Liste.
Browser auf Firefox-Basis machen das problemlos mit.
Vanadium (Standard-Browser von GrapheneOS, auch Chromium-basiert) funktioniert seit einiger Zeit glücklicherweise auch. Hat mir aber etwas zu wenig Funktionen.

Dass Apple das allgemein nur mit Apple-Hardware zulässt, ist mir auch schon sehr negativ aufgefallen. Ich bin kein Apple-User, habe damit aber an der Arbeit teilweise Kontakt.

Ich hoffe einfach mal, dass sich das in Zukunft noch bessert, denn Passkeys erhöhen die Sicherheit deutlich und sind, wenn sie denn mal funktionieren und gut implementiert sind, sehr komfortabel in der Benutzung.

3

Kann dem leider nur zustimmen.
Finde die Funktion wie se gedacht ist auch super.

Aber wenn davor oder danach noch was eingeben werden muss oder die alten Logins nicht löschbar sind, macht es keinen Sinn.

4

Die Umsetzung des Konzeptes Passkey wird sich entwickeln. Aktuell stecken noch eine Menge Kinderkrankheiten drin, ich finde es aber für mich durchaus schon nutzbar.

Meine Umgebung besteht aus dem Enpass Passwortmanager zur Verwaltung meiner Passkeys da potentiell plattformübergreifend, Synchronisierung über WebDAV mit einer Nextcloud, meine Geräte sind Apple macOS, iOS und iPadOS Geräte und als Browser primär Safari oder DuckDuckGo.

Bisher leider nur drei Accounts auf Passkeys umgestellt.

Nach erfolgreicher Aktivierung eines Passkeys, ändere ich das Passwort zum Acoount in ein sehr zufällig generiertes, langes und komplexes Passwort. Dieses Passwort speichere ich mir nicht ab, sodass mir dieses nach der Änderung selbst nicht mehr bekannt ist.

Ein Risiko eines Einbruchs über das Passwort ist nach der Änderung (solange nicht diese mitgelauscht wurde) quasi nicht mehr relevant, da

(a) Die Komplexität des Passwortes einen. Brute-Force-Angriff in relevanter Zeit verhindert.

(b) Ein späteres Phishing oder Abgreifen des Passwortes nicht mehr geschehen kann, da dieses ja nicht mal mehr mir bekannt ist.

In meiner Umgebung ist derzeit das größte Problem, dass ich mich derzeit vom Mac über Enpass nicht direkt mit dem Passkey-Anmelden kann. Das ist aber ein bereits bekannter Bug den ich durch Scannen eines QRCodes mit dem
iPhone als Alternative Lösen kann.

Aber auch Dienste von Amazon erfordern zuerst die Eingabe des Benutzernamens vor der Passkey-Authentisierung.

Es ist also Luft nach oben und nicht perfekt, aber aus meiner Sicht durchaus nutzbar.

5

Kann ich für Brave on iOS leider bestätigen. Keepassium wird nicht erkannt; stattdessen soll ich in Apples Keychain (das ich für Autofill gar nicht aktiviert habe) einen neuen Passkey anlegen.

Das nehme ich inzwischen mit Humor: Habe nämlich rausbekommen, dass die schräge Formulierung „Hauptschlüssel“, die immer mehr ihren Weg in die Benutzeroberflächen findet, die offizielle deutsche Übersetzung von Passkey ist. Das Passwort, TOTP und andere Authentifizierungsmethoden werden nach dieser Logik wohl als ‚Zweitschlüssel‘ verstanden und bleiben weiterhin aktiv. Um ehrlich zu sein: Bei den oben geschilderten Kinderkrankheiten wäre ich ohne weiterhin aktives Passwort öfters gar nicht mehr in meinen Account gekommen.

Aus diesem Grund finde ich die Praxis von @Reklow mutig, aber konsequent:

Bei mir liegen die alten, starken Passwörter immer noch in der KDBX-Datei und werden von Autofill vorgeschlagen. Je häufiger aber der ‚Hauptschlüssel‘ genutzt wird (was meist auch der komfortablere Zugang ist), desto weniger Chancen haben die Phisher. Wenn sich Passkeys mal durchgesetzt haben werden (wird wohl noch Jahre dauern - bei Microsoft kann man schon seit 2021 passwortlos sein, ohne dass das ein Gamechanger gewesen wäre), dann werden bei vielen Usern hoffentlich die Alarmglocken läuten, wenn doch mal der Zweitschlüssel (Passwort) abgefragt werden sollte - und dann entsprechend vorsichtig sein.

6

Eigentlich braucht man da keinen Mut. Ich nutze im Vorfeld die Passwort-Reset-Funktion zum neu Setzen des Passwortes. Dann weiß ich, dass ich immer noch an den Account komme.

7

Was meinst du damit, dass Apple das nur mit Apple-Hardware erlaubt? Ich benutze privat fast nur macOS und iOS und habe weder mit den Passkeys in KeePassXC noch in Yubikey Probleme. Bei mir sind keine Passkeys in der iCloud oder in der Co-Prozessoreinheit Secure Enclave gespeichert.

8

Ich meine damit, dass ich mich mit einem Apple-Account nicht an einem Windows oder Linux-Rechner im Browser mit einem Passkey anmelden kann.
Noch schlimmer sogar: Ich muss jedes Mal ein MacOS- oder iOS-Gerät zur Hand haben, um den Login zu bestätigen. Ich habe das MacBook aber nicht immer zur Hand. Das bedeutet: Ohne das MacBook kann ich mich gar nicht bei Apple anmelden.
Mit einem regulären Passkey, der nach der Spezifikation arbeiten würde, gäbe es das Problem nicht, da dann ja der zweite Faktor entfällt.

9

Ist tatsächlich in den Passkey-Spezifikationen festgelegt, dass es nach der Passkey-Authentisierung keinen zweiten Authentisierungs-Faktor mehr abgefragt werden darf?

Von der Bedrohung

„Vertraulichkeit eines Benutzer-Passwortes ist verloren gegangen“

her gesehen wäre der Einsatz der Zwei-Faktor-Authentisierung beim Einsatz eines Passkeys nicht mehr notwendig. Kann es noch weitere Bedrohungen geben, die der Zwei-Faktor-Authentisierung begegnet?

10

Wenn dem so wäre, dann wäre Passkeys nicht nur überflüssig, sondern ein erhöhtes Sicherheitsrisiko.

Denn ein Passkey in einer Hardware würde jedem Dieb ebendieser Hardware unmittelbaren Zugriff geben.
Selbstredend ist es absolut zwingend notwendig, eine weitere Sperre per default zu ermöglichen.

Letztlich ist auch ein Masterpasswort in einem Keepass oder ein Fingerabdruck/PIN auf einem Handy ein „zweiter Faktor“, der „lästigerweise“ einzugeben ist, bevor der Passkey Zutritt erteilt.
Dummerweise an dieser Stelle sogar dasselbe Passwort für viele Passkeys.

1 „Gefällt mir“
11

Hm, ich habe gerade festgestellt, dass mir noch die Passkeys für meinen Apple Account fehlen. Bei der Einrichtung sind mir zwei Dinge aufgefallen:

  • Zum einen kann ich bestätigen, dass es tatsächlich nicht möglich ist, einen Passkey in einem Software-Authenticator wie z.B. KeePassXC zu hinterlegen. Da der Passkey in den Einstellungen von macOS angelegt werden muss und nicht im Browser, geht das mit einem Software-Authenticator nicht. Nun, das ist nicht weiter schlimm. Apple verlangt von den Passkeys eben die strikte Einhaltung der FIDO-Spezifikation. Die Kompromisslösung über einen Software-basierten Authenticator lässt Apple nicht zu. Das spricht eher für als gegen Apple. Auch wenn es unbequem ist.

  • Wenn man den Passkey in einen Security-Stick unterbringt, verlangt Apple mindestens zwei Hardware-Authenticatoren, damit man bei Verlust eines Gerätes noch ein Backup hat. Auch das mag unpraktisch erscheinen, widerspricht aber nicht der FIDO-Spezifikation. Bei der Verwendung von Hardware-Authenticatoren fällt aber laut Aisstenten der zweite Faktor weg. Ich kann das jetzt nicht ausprobieren, weil ich keine zwei Yubikeys habe.

Frage: Deaktiviert Apple bei der Verwendung von Passkeys automatisch die Anmeldung mit Passwort?

Ich brauche sowieso einen zweiten YubiKey, also sollte das kein Problem sein. Aber die Frage, die ich mir jetzt stelle, ist, ob ich dann jedes Mal einen Yubikey zur Hand haben muss, wenn ich etwas mit meiner Apple ID mache. Zum Beispiel irgendeine App auf mein Handy lade oder so. Das wäre ziemlich umständlich, aber ich fürchte, das wird so sein.

Im Großen und Ganzen muss ich aber sagen, dass Apple es einfach ernst meint mit der Umsetzung der FIDO-Spezifikation. Ich würde das nicht als Kinderkrankheit bezeichnen.

Tipp: Nachdem ich eine Weile mit einem YubiKey unterwegs war, ist mein größter Kritikpunkt, dass ich keine Kontrolle mehr darüber habe, welche Passkeys dort gespeichert sind. Das kann ich nicht einsehen. Da ich das am Anfang nicht aufgeschrieben habe, habe ich den Überblick verloren. Das kann natürlich problematisch werden, wenn man unterwegs ein wichtiges Login nicht zur Hand hat. Da muss ich sorgfältiger werden.

Bildschirmfoto 2025-05-11 um 10.49.23
Bildschirmfoto 2025-05-11 um 10.49.231856×1474 266 KB

12

Die Aussage ist jetzt ein wenig zu kurz gesprungen. Passkeys (oder besser FIDO2) versuchen eine Vielzahl an Verbesserungen gegenüber einer Passwort-baserienden Authentisierung zu implementieren:

https://de.wikipedia.org/wiki/FIDO2#Passkey

Insbesondere wäre hier aus meiner Sicht Maßnahmen gegen die folgende Bedrohung zu nennen:

  • Abfangen und Wiederverwenden des Benutzer-Geheimnisses zum Beispiel durch einen Phishing-oder Man-in-the-Middle-Angriff direkt im Challange-Response-basierenden Authentisierungsverfahren.

Zwei-Faktor-Authentisierungen wie TOTP befassen sich mit derselben Bedrohung, lösen diese jedoch durch einen zweiten, unabhängigen Authentifizierungsschritt bei dem das zweite Benutzer-Geheimnis ebenfalls nicht übertragen wird.

Aus diesem Aspekt heraus würde der Einsatz von Passkeys die Zwei-Faktor-Authentisierung dann unnötig machen.

13

Der geheime Schlüssel wird während des Onboarding-Prozesses des TOTP-Verfahrens schon über das Netzwerk übertragen. Der QR-Code mit dem geheimen Schlüssel wird vom Zielserver generiert und (einmalig) an den Client übertragen. Ein einzelnes TOTP wird ebenfalls über das Netzwerk übertragen und kann abgefangen werden. Das ist ja das Problem bei der 2FA-Authentifizierung, dass sie nicht Phishing-resistent ist.

https://www.golem.de/news/modlishka-phishing-tool-umgeht-zwei-faktor-authentifizierung-1901-138674.html

14

Du hast Recht, dass bei der Einrichtung von TOTP das Geheimnis einmalig übertragen wird.

Mir ging es darum darauf hinzuweisen, dass die Schutzfunktion des zweiten Faktors bei der Authentisierung bereits durch den Passkey mit abgebildet wird.

15

Ich denke, wir müssen hier unterscheiden zwischen der (älteren) Technologie Hardwarekey und der jüngeren Passkey, obwohl beide heutzutage unter dieselbe Spezifikation fallen. Den Apple-Account mit einem USB-Stick abzusichern, geht schon länger und ist für besonders Sicherheitsbewusste eine gute Lösung.

Zur Apple-ID und Passkeys war bei Heise bereits 2023 zu lesen:

Jede Apple-ID hat künftig auch einen Passkey zur passwortlosen Anmeldung: Mit iOS 17, iPadOS 17 und macOS 14 Sonoma richtet der Betriebssystemhersteller für jeden Apple-ID-Nutzer automatisch einen Passkey ein. […] sie sind an den iCloud-Schlüsselbund geknüpft, sodass die Passkeys zwischen den Geräten des Nutzers synchronisiert werden – und praktisch auch ein Backup bestätigt, falls alle Geräte verloren gehen sollten.

https://www.heise.de/news/Passwortlose-Anmeldung-Apple-ID-erhaelt-ab-iOS-17-automatisch-einen-Passkey-9193472.html

Das zeigt gut den verbesserten Komfort durch Backup & Sync, aber die geschwächte Sicherheit gegenüber den von Dir eingesetzten FIDO2-Key.

Das Problem: Third-Party-Software wie Bitwarden, KeePassXC und 1Password (bei Apple-Nutzern sehr beliebt) bleibt außen vor. Hier monopolisiert Apple mal wieder sich selbst, obwohl alle diese Dienste wie Apples Keychain E2EE implementiert haben.

Interessant auch (wie gesagt: Artikel von 2023):

Passkeys sind bei Apple bislang für den Nutzer unzugänglich gespeichert und lassen sich nur über AirDrop teilen. Künftig soll aber auch ein Exportieren der Passkeys zu anderen Passwort-Managern (und damit auch Betriebssystemen) möglich werden.

Keine Ahnung, was daraus geworden ist - vielleicht wissen die Mac-User hier im Forum mehr.

16

Hm. Klappt „ykman fido credentials list“ auf der Kommandozeile nicht mehr, wie hier beschrieben?
https://www.codingblatt.de/passkeys-mit-yubikey-linux-verwenden/

17

Mir ging es primär darum, das Passkeys-Risiko zu betonen, das auftritt, wenn User tatsächlich komplett „passwortlos“ arbeiten und ihnen dann die Hardware geklaut wird.
Diese Hardware ist der Generalschlüssel für alles, was sie abgesichert haben und dann in den Händen von einem bösen Mädchen, welches nun völlig stressfrei („passwortlos“) direkten Zugang zu allem hat.

18

Bei mir funktionieren Passkeys prima und ich benutze sie auf nahezu allen Services die es anbieten, sowohl unter Arch Linux, GrapheneOS, als auch Windows 11. Die meisten Passkeys werden in Bitwarden gespeichert, bis auf ein paar besonders schützenswerte, die ich hardwaregebunden via Security Key oder Security Chip verwende. Nahezu keine Probleme im Alltag.

19

Ist bei mir auch so unter Arch Linux und iOS. Die Passkeys sind gespeichert in Proton Pass.

20

Bei den meisten Passkey-Nutzern wird das Problem des Verlust einer ungeschützten Hardware nicht auftreten, da sie die Software-Version zur Speicherung der Passkeys in ihrem Passwort-Manager / Betriebssystem nutzen und der Zugang dazu mit Passwort / Biometrie geschützt ist.

Aber bei einem Hardware-Schlüssels der ohne Authentisierung des berechtigten Benutzers die Authentsierungsdaten freigibt hast Du natürlich recht.