Anregung: Anmeldung mit Passkey im CCP

  • Präambel: Bei einem Anmeldeverfahren geht nicht einfach darum maximale Sicherheit zu erzielen, diese ist bei einem nicht verwendeten Dienst oder bei einem bei dem man das Passwort im Meer versenkt, immer am höchsten. Ein Sicherheitskonzept, dass Nutzerbedürfnisse ignoriert und deshalb aus Bequemlichkeit oder Ungeschick vom Nutzer kompromittiert wird, verfehlt seine Zielsetzung. Zum Beispiel entschlüsselt nur ein IT-Anfänger seine SSH-Keys individuell mit Passwort (oder hat gar nur einen einzigen für mehrere Server), in der Realität nutzt man einen SSH-Agent, und am Ende ist dieser schnell an eine Single-Sign-On-Lösung oder bspw. KeePassXC angebunden, damit Sicherheit auch praktikabel wird.


    Die gleiche Magie bieten Passwortmanager, wobei Passkeys (siehe Passkey Developer Resources | passkeys.dev) ein nativer Weg ist, wie man sich mit einem Passwortmanager anmelden kann. Ein Verfahren, dass derzeit in rasantem Tempo Verbreitung findet, einschließlich Open-Source-Lösungen wie bspw. kürzlich KeePassXC.


    Es gibt für Multi-Faktor-Authentifikation potentiell 3 Faktoren: Knowledge, Ownership und Biometrie. Ob diese nun Serverseitige (Passwort+TOTP) oder Clientseitig (Masterpassphrase/Fingerabdruck+Passkey) abgefragt werden, ist dabei unerheblich. Passkeys sind eine sichere Anmeldemöglichkeit und wahrscheinlich sicherer als 2FA, denn in der Praxis werden Username+Passwort+TOTP oftmals in der gleichen KeePass-Datenbank abgespeichert und mit AutoType runtergerattert. Wenn man sich verklickt, rasselt KeePass ein anderes Passwort runter und leakt dieses; dann unterstützt jeder Dienst andere Passwortzeichen und Passwortlängen; die AutoType-Sequenz muss für jeden Dienst angepasst werden, usw. Das Verfahren Passkey ist dagegen Standardisiert: Auf github.com wählt man nur die Anmeldemethode aus und von der Zuordnung des richtigen Passkeyeintrags bis zur Zuordnung des korrekten Benutzerkontos erfolgt alles automatisch - Bedienfehler werden ausgeschlossen. Gerade die Anmeldung mit QR-Code löst Bequemlichkeitsprobleme: Häufig verwendete Passwörter werden meist einfacher und kürzer gewählt, bei einem Passkey muss man gar nichts mehr abtippen. Auf manchen Endgeräten möchte man nicht seine vollständige Passwortdatenbank entsperren, nur um sich selektiv bei einem einzelnen Dienst anzumelden (bspw. Firmenlaptop oder Netflix-Anmeldung bei einem Freund), andere Geräte haben keine Tastatur (bspw. SmartTV), sodass man geneigt ist in Netflix 123456 als Passwort zu setzen, sodass die Anmeldung mittels QR-Code viele Probleme addressiert. Eine Passkey-Anmeldung kann zudem auf die explizite Wahl von Identifiern wie Benutzernamen, E-Mail-Adresse, etc. verzichten, sodass auch datensparsamere 1-Klick-Registrierungen bzw. 1-Klick-Logins möglich werden, was erheblich besser ist, als bisherige "Login wie Facebook"-Lösungen, denen genau dieses Bedürfnis zugrunde liegt. Dies könnte auch öffentliche Passwortdatenbanken (bspw. für Internetforen) erübrigen, die nur entstehen, damit man nicht überall einen 0-8-15-Registrierungsprozess mit E-Mail-Adresse (und manchmal Moderatorenfreigabe) durchlaufen muss.

    Am Ende des Tages sollte man nicht vergessen, dass ein Nutzer mehrere Passkeys für verschiedene Geräte einrichten und hinterlegen kann, dies aber gleichsam den Vorteil bietet, dass beim schon immer dagewesenen Bedürfnis des Account- und Passwortsharings jedes Gerät seinen individuell Passkey nutzen und der Passkey auch wieder individuell entzogen werden kann. Der Realität, dass Passwörter (einschließlich TOTP) weitergegeben oder öffentlich auf Whiteboards geschrieben werden, muss man sich einfach stellen und die Nutzerbedürfnisse dahinter adressieren. Gerade Domain-; Web- und Serverhosting gehört im Privat- und Hobbyumfeld zu einer besonders von Account-Sharing exponierte Serviceart - ihr möchtet nicht Wissen, wie viele uralte Root-Zugänge, Domain-Admin-Zugänge, usw. sich in meiner Passwortdatenbank anstauen, die über Jahre nicht geändert werden.


    Ich befürworte Passkeys und würde mich freuen, wenn auch netcup diese unterstützen würde, um das Sicherheitsniveau regulärer Anmeldungen auf das Fundament von Public-Key-Kryptografie zu stellen.

  • Danke für die ausführliche Beschreibung.


    Eine Unterstützung von PassKeys würde mich freuen. Gleichzeitig fände ich es auch super, wenn im CCP andere 2FA-Verfahren als OTP unterstützt werden würden (beispielsweise einen Hardware-Schlüssel wie YubiKeys).

  • Ich hab dazu schonmal in einem anderen Foreneintrag diskutiert (https://forum.netcup.de/netcup…84-2fa-im-ccp/#post210084), auch wenn ich mich beim Punkt Phishing korrigieren muss, das ist tatsächlich nahezu unmöglich (aber Ich sehe da dennoch Möglichkeiten), da ist es teils leichter, Cookies zu klauen, sofern möglich. Aber ich finde es immer noch keine gute Idee von MFA auf einen Faktor zurückzuwechseln. Von mir aus Passwort und WebAuth als zweiten Faktor, aber WebAuth als einzigen Faktor zu nutzten ist wirklich keine gute Idee aus meiner Sicht. Sobald eine Person den Private Key hat, ist die ganze Sicherheit weg, wenn der lokal gespeichert ist, kann der genauso geklaut werden, mit physischem Zugriff, wie, auch wenn der in der Cloud liegt und der Anbieter sich nicht gut um Sicherung des Private Keys sorgt (siehe LastPass). Und zu sagen, aber Biometrie, macht keinen Sinn, fast jeder Passwortmanager kann mit Biometrie geschützt werden, dennoch sind Passwörter allein nicht ausreichend.

  • Aber ich finde es immer noch keine gute Idee von MFA auf einen Faktor zurückzuwechseln. Von mir aus Passwort und WebAuth als zweiten Faktor, aber WebAuth als einzigen Faktor zu nutzten ist wirklich keine gute Idee aus meiner Sicht.

    Das kommt wohl auf die konkrete Umsetzung an. Am Beispiel YubiKey ist es idR. so, dass zwei Faktoren weiterhin benötigt werden. Einmal der Besitz des Keys und das Wissen (PIN) diesen freizuschalten.


    Klar, PassKeys z. B. in einem PW-Manager abzulegen dürfte ähnlich sinnvoll sein wie Passwort *und* 2FA-Secret gemeinsam dort abzulegen.

  • ...YubiKeys...

    Passkeys sind einfach ein standardisiertes maschinelles Anmeldeverfahren. Worauf die Keys gespeichert werden, kann man frei auswählen. Ob nun in Windows Hello, auf dem Smartphone, in einem Passwortmanager wie KeePassXC oder einem Hardwaretoken wie dem YubiKey. Serviceprovider müssen nur einen Standard für alles implementieren, während Benutzer die Kontrolle und freie Auswahl haben, ob sie Handvenenscanner oder Hardwaretokens einsetzen. Der aktuelle YubiKey unterstützt derzeit glaube ich 25 Passkeys, wobei dessen Kapazität in zukünftigen Versionen vergrößert werden soll

    Aber ich finde es immer noch keine gute Idee von MFA auf einen Faktor zurückzuwechseln. Von mir aus Passwort und WebAuth als zweiten Faktor, [...]

    Du verwechselst die Quantität der von dir getätigten Eingaben mit dem tatsächlichen vorliegen verschiedener Sicherheitsfaktoren. Jeder Faktor ist am Ende nur ein Teilschlüssel - MFA zielt darauf ab, dass diese zumindest aus 2 von 3 Faktoren (Ownership, Knowledge, Biometrie) bestehen. Wenn du Teilschlüssel auf verschiedene Geräte verteilen möchtest, so ist das kein MFA, sondern "Secret Sharing". Ein Beispiel: Es gibt Menschen, die argumentieren, dass man zusätzlich zum SSH private Key auch noch TOTP einsetzen sollte, um einen "2. Faktor" zu haben. Tatsächlich handelt es sich aber um Secret-Sharing, da beide Komponenten nur Ownership abdecken. Umgekehrt verlangst du, die wie das BSI titelt "Passkeys - anmelden ohne Passwort" nur als 2. Faktor für eine Passworteingabe einzusetzen, was bereits dem Namen nach das Konzept ad absurdum führt. Denn ein Passkey (Ownership) funktioniert nur mit einem Authenticator, der ein weiteres Sicherheitsmerkmal verifiziert (i.d.R. Biometrie). Hierzu sollte man sich verinnerlichen, dass MFA nicht voraussetzt, dass alle Faktoren serverseitig verifiziert werden (und eben dafür dann dein Fingerabdruck an den Server eingeschickt wird), sondern, dass eine Authentifizierung nur mittels mehrerer Faktoren stattfinden kann.


    Daher sind Passkeys eine MFA-Authentifizierung und werden von Internetanbietern (bspw. Google) auch als solche behandelt, wenn man MFA aktiviert. Da Passkeys vergleichbar zu Transaction-based-OTP einen Challenge-Code signieren, statt einem Time-based-OTP, sind sie neben den Problemen unsicherer Passwörter, erheblich sicherer als reguläres 2FA mit Passwort+TOTP

  • "Passkey" ist nur ein Marketing Name für WebAuth mit dessen Marketing Start Multi Device hinzukam. Und bei WebAuth hast du nur einen Faktor, das kannst du dir schönreden wie du willst, denn für die Authentifizierung ist nur der private Key von nöten, eine "kosmetische" (z.B. Biometrie) Absicherung ist da unrelevant. Wenn ich das mal nach deinen 3 Optionen vorrechne wäre das bei mir aktuell: 1. Besitz Gerät mit PW Manager 2. evt. PW/Biometrie für Zugriff auf Gerät 3. Wissen Masterpasswort/Biometrie 4. Besitz Handy mit TOTP App 5. evt. PW/Biometrie für Zugriff auf Gerät 6. Biometrie zur Entsperrung der App. Heißt das wäre 6FA (was natürlich unsinn ist). Den am Ende brauch ich nur den Seed von TOTP und das Passwort, heißt zwei Verpflichtende Faktoren, welche weiter gesicht werden können. Bei Passkey nur den private Key, heißt nur ein zwingender Faktor, Biometrie ist faktisch nicht verpflichtend beim Einsatz von WebAuth, bei Windows reicht da teils auch ne PIN und zwar die gleiche dir auch bei der Anmeldung in Windows genutzt wird.

    Denn ein Passkey (Ownership) funktioniert nur mit einem Authenticator, der ein weiteres Sicherheitsmerkmal verifiziert (i.d.R. Biometrie).

    Das ist einfach falsch, WebAuth wird in der Regel weiter abgesicht, wie auch jede TOTP App oder PW Manager, aber WebAuth funktioniert auch ohne weitere Clienseitige Absicherung.

    Hierzu sollte man sich verinnerlichen, dass MFA nicht voraussetzt, dass alle Faktoren serverseitig verifiziert werden (und eben dafür dann dein Fingerabdruck an den Server eingeschickt wird), sondern, dass eine Authentifizierung nur mittels mehrerer Faktoren stattfinden kann.

    Von mir aus nenn das MFA, aber wenn du Serverseitig nicht mindestens zwei Faktoren verifizierst, kannst du MFA auch sein lassen, da du eh nicht weißt ob mehrere Faktoren zum Einsatz kamen, letztendlich sagst du gerade, sollen sich Personen doch selbst drum kümmern, den Serverseitig verifizierten Faktor mit Clientseitigen Faktoren weiter zu sichern. Im übrigen selbst wenn du den private Key mit Biometrie sicherst, hast du wieder nur ein Faktor, da die Biometrie dann mit dem private Key im Prinzip gleichsetzbar ist.


    (Zu Beginn ich bin nicht sicher, ob das geht, aber ich halt es für sehr wahrscheinlich) Bei eigentlich jedem Gerät ist PIN/PW > Biometrie und PIN/PW ausreichend um Biometrie zu ändern, heißt wenn ich ein Handy mit PIN/PW habe auf dem WebAuth private Keys gespeichert sind, kann ich in den Einstellungen einfach die Biometrie zu mir ändern und hab am Ende nur durch Geräte PIN/PW + Besitz am Gerät zumindest temporären Zugriff auf alle private Keys ohne Biometrie.


    Zum BSI, dass kann schreiben was es will, die Öffentlichkeitsabteilung ist sowieso sinnlos aus meiner Sicht, aber genauso wie deren Passwort empfehlungen jedes Jahr anders gewürfelt werden, macht das bewerben eines "1FA" Verfahrens durch das BSI dieses Verfahrens das nicht sicher, effektiv wird damit auch beworben Anmeldedaten in der Cloud zu speichern, was nicht in jedemfall eine gute Idee ist. In den wenigsten fällen werden WebAuth private Keys nur lokal gespeichert. Es ist übrigens nich absurt wenn ich und das BSI verschiedene Ansichten haben wie von dir erwähnt.


    Ich hab ja kein Problem WebAuth neben einem anderen Faktor zu nutzten, der muss ja nichtmal ein Passwort sein. Die Zukunft kann gerne WebAuth + TOTP sein, aber nur WebAuth ist aus meiner Sicht keine gute Idee und es ist zwar zu 100% besser als nur PW, aber es bleibt weiterhin nur ein deutlich optimiertes ein Faktor Verfahren. WebAuth mit 2. Serverseitigen Faktor > Passwort mit 2. Faktor > WebAuth > Passwort


    Ich schätze du kennst das Schweizer Käse Modell, eine Käsescheibe mit wenig bzw. kleinen Löchern ist zwar gut, aber noch besser sind mehrere davon. Und Serverseitig kontrollierte Scheiben sind nochmal besser.

  • Meinungen verändern keine Fakten. Aber Fakten sollten Meinungen verändern. Ich kann dir versuchen es zu erklären, verstehen musst du es aber selber. Es gibt nur 3 Faktoren, daher ist das maximum eine 3FA. WebAuthn (mit "n") ist ein Framework, dass MFA unterstützt. Der Authenticator gibt Auskunft darüber, welcher Verifikationsgrad durchgeführt wurde, respektive kann der Serviceprovider festlegen, welche Anmeldetypen er zulässt. Wenn es ein Bedürfnis ist, kann überprüft werden, ob der Authenticator zertifiziert ist, respektive mit einer Blacklist ein Authenticator ausgeschlossen werden. All das, was du verlangst, wird durch WebAuthn erfüllt und ist möglich. In der Regel wird man aber für den Alltag nicht solch strenge Sicherheitsrichtlinien umsetzen. Auch bei herkömmlichen Verfahren kann man den Benutzer nicht beliebig bevormunden, der durch "123456" als Passwort, schwache Zufallszahlen für einen Private-Key, oder durch das Veröffentlichen der Token-Generator-Ausgabe mit einer WebCam, immer die Sicherheit schwächen kann. Auch die TOTP-QR-Codes kann man per WhatsApp verschicken oder ausdrucken und an die Tafel pinnen - dieses Problem wird immer bestehen. Aber, genau das ist der Punkt von Passkeys: Warum machen das Nutzer? Weil die bisherigeren Sicherheitskonzepte Nutzerbedürfnisse nicht befriedigten. Ein Sicherheitskonzept lässt sich nicht gegen einen Benutzer durchsetzen, sondern genau hier setzen Passkeys an, und möchten mit ihm, ein hohes Sicherheitsniveau erreichen.

  • Wir reden hier über eine Anmeldung auf ein Panel, welches root Zugriff auf alle bei Netcup gebuchten Leistungen ermöglicht (und somit auch, sofern vorhanden, Zugriff auf dort gespeicherte persönliche/sensibele Daten dritter), nicht um ein Account mit dem auf einer WordPress Seite mal ein Kommentar geschrieben hat. Da finde ich MFA Zwang schon angebracht, welcher auf dem Server mehrere Faktoren überprüft.

  • Da finde ich MFA Zwang schon angebracht.

    Selbstverständlich. 8 Daumen hoch für ein Strohmann-Argument. Das einzige worüber wir herumdiskutieren ist, dass der W3C-Standard auf dem Passkeys aufbauen, besagt, dass ein Authenticator die Sicherheitsfaktoren überprüft, du aber MFA auf dem Server überprüft wissen willst. Ein konkretes Beispiel für einen Authenticator ist Windows Hello, welcher eine 2FA aus Ownership+Biometrie bietet und daher ohne Knowledge (das klassische Passwort) als Faktor auskommt, weshalb Passkeys als "Passwortloses Anmeldeverfahren" bezeichnet werden. Deine Kritik an der Sache ist lediglich, dass der Server quantitativ nur einen einzelnen Passkey empfängt:

    Das deine zählweise für die Anzahl der vorliegenden Faktoren verkehrt ist, und sowohl

    1. Besitz Gerät mit PW Manager 2. evt. PW/Biometrie für Zugriff auf Gerät 3. Wissen Masterpasswort/Biometrie 4. Besitz Handy mit TOTP App 5. evt. PW/Biometrie für Zugriff auf Gerät 6. Biometrie zur Entsperrung der App. Heißt das wäre 6FA (was natürlich unsinn ist).

    als auch

    [...]das bewerben eines "1FA" Verfahrens durch das BSI [...]

    falsch gezählt wird, habe ich bereits versucht, zu erklären. Spätestens wenn Passkeys auf einem YubiKey gespeichert werden, genügt dieser auch den höchsten Anforderungen (AAL3) der NIST SP800-63B.

  • Ich bin gegen Passkeys, weil man damit aktuell die Kontrolle an Google Apple und MS abgibt.

    Und nicht nur die Kontrolle für einen Zugang, sondern für alle seine Passkeys.

    Mit Kontrolle meine ich nicht, dass die genannten 3 Zugriff erlangen könnten, sondern das ich den Passkey DIENST nur nutzen kann wenn die genannten möchten, oder können...

    Ente: © 2023 Craiyon LLC.

    Einmal editiert, zuletzt von ulf8000 ()

  • Ich bin gegen Passkeys, weil man damit aktuell die Kontrolle an Google Apple und MS abgibt. [...]

    Du kannst genauso KeePassXC unter Linux verwenden. Passkeys sind ein offener Standard, der dir die Freiheit gibt, eigenständig individuell einen für dich geeigneten Authenticator zu wählen. Wenn du einen YubiKey einsetzt, werden die Passwörter zum Beispiel auf diesem gespeichert.

  • Aus meiner Sicht sind Passkeys auch nicht das Wundermittel für mehr Sicherheit, sondern eine Alternative, für die man sich entscheiden kann oder auch nicht. Den größten Vorteil sehe ich tatsächlich darin, dass Passkeys eine bessere Methode zur Authentifizierung für eben jene Menschen sein kann, die mit Passwortmanagement und 2FA schon jetzt überfordert sind. Aber auch nur dann, wenn die Verwaltung der privaten Schlüssel auf einer dezidierten Hardware stattfindet und eben nicht in der Cloud.


    Meinungen verändern keine Fakten. Aber Fakten sollten Meinungen verändern. Ich kann dir versuchen es zu erklären, verstehen musst du es aber selber.

    Ich glaube, du hast dich in deinen Ausführungen selbst etwas „verrannt“.


    Hierzu sollte man sich verinnerlichen, dass MFA nicht voraussetzt, dass alle Faktoren serverseitig verifiziert werden (und eben dafür dann dein Fingerabdruck an den Server eingeschickt wird)


    Solche Aussagen sind einfach nur AUA.. 😑

  • Passkey != YubiKey


    Und KeePassXC benötigt einen PC mit sauberem (!) OS, und mobil geht da gar nichts.


    Zum Testen wurde mir "https://passkey.org/" genannt, Aber mit Firefox oder Chromium komme ich mit KeePassXC auf der Seite nicht weiter. Nutze Linux.


    Ich würde mich gerne überzeugen lassen, aber aktuell sind Passkey aus meiner Sicht nicht praxistauglich, ausser man ist bereit sich 100% in die Arme von google, apple, oder ms zu legen.

  • Zum Testen wurde mir "https://passkey.org/" genannt, Aber mit Firefox oder Chromium komme ich mit KeePassXC auf der Seite nicht weiter. Nutze Linux.

    Hast du in der KeePassXC-Browser-Extension die Einstellung geändert, dass Passkey mit KeepassXC genutzt wird?. Da dies das Webbbrowser-Standardverhalten ändert, ist es per Default deaktiviert. Zudem brauchst du mindestens KeepassXC 2.7.7 und solltest dann entsprechende Einstellungen innerhalb von KeePassXC haben.

    Du kannst es auf GitHub.com oder webauthn.io ausprobieren.

  • Solche Aussagen sind einfach nur AUA.. 😑

    Ich bin überzeugt das nicht. Ob bei der Anmeldung an der ePA, Elster, eID, usw. ist es immer das selbe Spiel: Die (in diesem Fall Karten-PIN) wird nicht an den Server geschickt , sondern dient der Freigabe der Karte (Krankenkassenkarte/Personalausweis/SIM-Karte/Kreditkarte/Girocard). Dennoch ist das Ergebnis eine sehr starke 2FA-Authentifizierung, obwohl der Server die PIN nie gesehen hat, sondern nur die digitale Unterschrift aus der Karte hat.


    Man könnte höchsten die stärke und schwäche bestimmter 2FA-Merkmalen untereinander abwägen (bspw. Handvenenscanner ist sicherer als Fingerabdruck als Biometrie-Merkmal; eine Software-Schlüsseldatei ist schwächer als ein Hardware-Modul als Ownership-Merkmal, usw), was aber nicht Gegenstand der reinen Betrachtung ob 2FA vorliegt oder nicht ist, sondern uns Offtopic führen würde in eine Art Debatte "Wie lang und welche Zeichen muss ein Passwort haben, um sicher zu sein." - nur eben bezogen auf die anderen MFA-Faktoren. Genau dafür gäbe es im Bedarfsfall die WebAuthn-Attestation, die ich bereits erwähnte.

  • Und da mache ich mich von der Firma "Bitwarden Inc." abhängig.

    Statt bei google, apple oder ms ist mein Passkey dann bei Bitwarden unter Kontrolle.

    Nein, du kannst auch Vaultwarden benutzen. Oder meinst du mit "abhängig", dass du Software fremder Leute benutzen müsstest? In diesem Fall hätte ich schlechte Nachrichten für dich...

  • Win98SE4ever hat es in diesem Beitrag erfasst. Bei Passkeys anstelle von Passwort+TOTP würde die Erforderlichkeit einen Challenge-Code zu signieren dazu führen, dass ein Angreifer nicht mehr stupide phishen kann, sondern er müsste Proxy für den Challenge-Code spielen, was aber dann bei netcup durch eine vielzahl von Challenge-Code-Anfragen auffallen würde - neben dem - dass für die Zuordnung eines Passkeys ggf. ein Domain-Abgleich stattfindet (daher würde der Authenticator melden "für diese Webseite kenne ich keinen passkey"). netcup könnte dann Maßnahmen gegen einen Phishing-Angriff ergreifen. Auch bei einem Keylogger (Android-Tastatur), bei einem MITM (Virenscanner) usw. wäre kein Replay-Angriff mehr möglich. Größtes gelöstes Problem durch passkeys ist die Mehrfachverwendung von Passwörtern.


    Passkeys erzielen auch eine höhere Inklusion, da sich auch Menschen die eine (Touch-)Tastatur weder treffsicher noch schnell bedienen können oder kognitiv Schwierigkeiten haben sich etwas über längeren Zeitraum zu merken (Passwort), das Verfahren nutzen können - was insbesondere bei älteren Menschen ein Problem ist, die ggf. mit einem Smartphone (statt einem Laptop) arbeiten und ggf. derzeit auf die Webbrowser-Passwortmanager als Vendor-Lock-in-Silo-Lösung zurückgreifen. Passkeys geben nicht vor, welche Faktoren und welcher Typus (PIN oder Muster?) genau verwendet werden muss, daher können Menschen mit Einschränkungen ganz regulär sich die für sie beste Anmeldemethode (bspw. Gesichtserkennung statt Fingerabdruck) entscheiden. Im Zweifel sind Passkeys maschinell verarbeitbar und es ließen sich auch spezielle Authenticatoren für Menschen mit besonderen Anforderungen entwickeln. Normale Passwort-Manager haben ebenso wie andere Verfahren (bspw. GPG) eine gewisse Einstiegshürde, Passkeys bieten dagegen eine wesentlich höhere universelle Gebrauchstauglichkeit (Usability).

  • Ich weiß nicht, warum du verrückt nach Passkeys bist, aber ich fasse meine Punkte nochmal kurz zusammen:

    1. Du kannst nicht davon ausgehen, dass die private Keys clientseitig ausreichend gesichert sind (wie auch bei Passwörtern). Gerade, wenn du es Menschen einfachen machen willst, ist dies eben nicht der Fall.

    2. Nur WebAuthn ist natürlich besser als nur Passwort (besonders bei Phishing, da stimme dir ich zu), aber noch besser ist eine durch den Server durch mehre Faktoren bestätigte Authentifizierung, gerne auch mit WebAuthn als einen Faktor. Zusätzlich kommt noch hinzu: Angenommen der Server hat eine Sicherheitsschwachstelle, bei der WebAuthn Überprüfung, dann wärest du davor sicher, mit dem 2. serverseitigen Faktor, weil diese ja nicht die Überprüfung des 2. Faktors auf dem Server betreffen muss.

    3. Ich weiß nicht, wo du einen Strohmann siehst, aber der Titel dieser Diskussion lautet: »Anregung: Anmeldung mit Passkey im CCP«

    4. Ich glaube nicht das sich WebAuthn so einfach mit Gesundheitskarten/Geldkarten/dem elektronischen Personalausweis, etc. vergleichen lässt. Zudem kann es da genauso zu Sicherheitsproblemen kommen.

    5. Auch WebAuthn kann Sicherheitsprobleme haben. Es ist kein Allheilmittel.