Lock-In-Vorwurf und iCloud-Zwang
Passkeys: Freier Im- und Export soll möglich sein
Solltet ihr bisher noch keine Erfahrungen mit den so genannten Passkeys gemacht haben, dann solltet ihr diese mal auf der Demo-Webseite webauthn.io ausprobieren.
Virtuelle Zugangsschlüssel
Beim ersten Aufruf der Webseite vergebt ihr einfach einen Nutzernamen und lasst euch einen Passkey erstellen. Neu geladen, könnt ihr dann die Login-Prozedur über den soeben erstellten Passkeys ausprobieren und damit schon mal einen Blick auf eine passwortfreie Zukunft werfen.
Statt Logins stets mit der Kombination aus Nutzernamen und Kennwort zu schützen, planen Online-Giganten wie Apple und Google langfristig vor allem mit so genannten Passkeys zu arbeiten. Dabei handelt es sich um kryptografische Schlüssel, die auf iPhone oder Android-Geräten von biometrischen Zugangssperren, wie etwa der Gesichtserkennung Face ID oder der Fingerabdruckerkennung Touch ID gesichert werden.
Lock-In-Vorwurf und iCloud-Zwang
Eine bequeme Passwort-Alternative, die sich kürzlich den Vorwurf gefallen lassen musste, dass Google und Apple diese nutzen würden, um Anwender noch stärker an die eigenen Betriebssysteme und Endgeräte zu binden. Weder sei der Export bereits vorhandene Passkeys noch deren Import auf aktuellen Systemen möglich, so der App-Entwickler Jeff Johnson.
Zudem kritisierte Johnson, dass die Passkeys auf Apple-Geräten nur genutzt werden können, wenn Anwender sich auch für den Einsatz des iCloud-Schlüsselbunds entschieden haben.
Freier Im- und Export soll möglich sein
Hier hat der in Apples Safari-Team aktive Entwickler Ricky Mondello nun mit einer Wortmeldung reagiert, die nicht übersehen werden sollte: Passkeys so Mondello, werden sich langfristig geräteübergreifend importieren und exportieren lassen und dies über die Passkey-Manager unterschiedlicher Unternehmen hinweg.
Die entsprechenden Funktionen seien momentan zwar noch nicht verfügbar, man sei jedoch dabei diese zu planen, zu entwerfen und zu definieren.
Zuletzt hatte Google am 3. Mai angekündigt, den Login in vorhandene Gmail-Konten auch per Passkey zuzulassen.
Finde ich SEHR gut! Sollte sich schneller als neuer Standard etablieren.
Kurze Frage: Habe jetzt z.B. bei eBay und Google einen Passkey erstellt. Bleibt dann eigentlich das Passwort gültig oder wie sieht es damit aus? Macht ja wenig Sinn auf den Passkey zu wechseln, wenn das (bei vielen vermutlich unsichere) Passwort weiterhin gültig bleibt, oder?
Ja, bleibt gültig. Passkey ist nur eine zusätzliche Option.
Ggf. wird es zukünftig dann die Mögkichkeit geben bei der Neuanlage eines Accounts nur noch Passkey zu verwenden? Schauen wir mal.
Letztlich bringt Passkey versierten Passwort-Manager-Nutzern keinen Vorteil. Ob ich mein 30-satellites zufällig generiertes Passwort automatisch eintragen lasse oder einen Passkey verwende. Tja.
Gerade die eBay-Integration ist auch etwas blöd. Ich würde mit 2FA für normalen Login mit Passwort wünschen und kein 2FA beim Passkey-Login. Dort habe ich ja die 2FA bereits bei mir (Besitz des Passkeys auf dem Gerät & passendes Gesicht/Finger zum freigeben).
Öhm. Doch. Da der passkey beim phosgene und umleiten des requests direkt nicht funktionieren würde.
Phishing
Der Passkey Ist lediglich auf dem Gerät per Face oder Touch ID verschlüsselt gespeichert und wir damit entschlüsselt. Ein zweiter Faktor ist das nicht.
@“Olli“: Uns, den „versierten“ (was ist da kompliziert? Höchstens am Anfang das Einrichtens, aber dann kann dies nahezu jeder nutzen …) Passwort-Manager-Nutzern bringt dies tatsächlich etwas (zwar weniger, aber doch etwas), da der private Schlüssel (hier Passkey genannt, sonst wie PGP, das man z.B. mit SSH & authorization keys verwendet) nie übertragen wird. Da dies zum Großteil nicht (obwohl damit gut möglich) alle oder der größte Teil der Daten E2E-verschlüsselt gelagert wird, hält sich dies gegenüber einem sicheren Passwort in Grenzen.
Ich hoffe, dass dies für Keepass (ich nutze unter i(Pad)OS Strongbox und Keepassium dafür) bald möglich wird und die Clients dann entsprechend dafür aktualisiert werden.
Berechtigte Frage … und Du hast Recht: solange Dein altes Password noch parallel aktiv ist, profitierst Du nicht von einem Sicherheitsgewinn.
Im Moment sieht es (bei Google) so aus, dass der User entscheiden kann; defaultmäßig läuft das alte Password parallel aber der User kann es löschen.
Solange man sich jedoch nicht der Gefahr von Kinderkrankheiten der Passkey-Implementierung aussetzen will (und im Fall der Fälle seinen Konto-zugriff verliert), sollte man meiner Meinung nach hier nicht zu vorschnell handeln. Zudem ist immer die Empfehlung zu beachten, dass der Passkey physisch min. auf 2 separaten Medien zu speichern ist.
@“iProf“: Doch, man profitiert von einem Sicherheitsgewinn, der allerdings in diesem Fall nicht enorm ist.
Bzgl. möglichen Kinderkrankheiten warne ich auch davor dies sofort ausschließlich zu verwenden, auch wenn die Technik durch PGP und authorized key bei SSH längst bekannt ist und „oft“ genutzt wird).
Passkeys bieten dennoch einen Gewinn an Sicherheit. So sind sie zum Beispiel immun gegen Phishing.
Natürlich können sie keine Brute-Force-Angriffe auf ein parallel weiter nutzbares Kennwort verhindern.
@“Cookiemonster“: Doch, etwas schon, weil während dem Anmelden der private Schlüssel (den man als Passkey bekommt) nie übertragen wird. Also kann es beim Anmelden nicht gestohlen werden, falls bei der Übertragungstechnik eine Sicherheitslücke ist. Solange jedoch das Passwortsystem gültig bleibt und man mind. 1 vorrätig hat, ist der Vorteil bei gut und sicher gewählten Passwörtern gering, denn Einbrüche in die „Anmeldeserver“ sind sind leider nicht selten.
Damit man mich nicht falsch versteht, Einrüche in Server sind leider nicht selten, weshalb das Passwort mit Benutzername gestohlen werden kann (das ja momentan bestehen bleiben soll!). Bei Passkey liegt nur der öffentliche Teil auf dem Server, wodurch „Metadatenspionage“ möglich wird (also unberechtigtes Anmelden wird zwar mit dem öffentlichen Schlüssel nicht möglich, aber durch „Mitm-Attacken“ (also ohne Entschlüsselung des Datenstromes, was aber nicht unbedingt leicht durchführbar ist) können Metadaten gesammelt werden (was zum Teil wichtiger ist als das Verschlüsselte), weshalb Betreiber dies auch möglichst vermeiden sollten und man bei einem Einbruch in den Server dennoch das Passkey wechseln sollte, auch wenn sich der Einbrecher anschließend nicht als ein anderer Nutzer ausgeben kann … jedoch da dies als Ersatz für das Passwortsystem gedacht ist, werden die Daten natürlich nicht vermehrt auf dem Server E2E-verschlüsselt lagern und der Einbrecher wird zum Ausspionieren zum Großteil sowieso nicht das Passkey benötigen, weshalb die gewonnene Sicherheit nicht immens ist …).
Doch, das ergibt Sinn. Sicherheitsgewinn bei den Passkeys entsteht durch deren Nutzung und nicht dadurch, dass sie die einzige mögliche Anmeldemethode sind. Passkeys (bzw. WebAuthN/FIDO2) sind strukturell immun gegen Phishing, weil die Anmeldung damit nur über einen direkten kryptographischen Handshake zwischen deinem Endgerät und dem Server möglich ist. Man-in-the-Middle ist damit ausgeschlossen. Also z.B. kein Angriff darüber, dass du auf einer Phishing-Seite direkt eine PIN-Aufforderung der Bank angezeigt bekommst, die von den Angreifern direkt genutzt werden kann.
In der Datenbank der Betreiber ist nur ein öffentlicher Schlüssel von dir gespeichert. wenn die gehackt werden, ist das kein Problem. Vor dem Hintergrund wäre es natürlich schön, wenn man das Passwort komplett entfernen könnte (weil das ja immer noch gehasht gespeichert wird). Ist aber kein großes Problem, wenn man da einfach ein langes zufälliges Passwort eingetragen hat.
Bei Passkeys geht es um sichere Logins „for the masses“.
Freue mich drauf endlich 1Password aufgeben zu können. Ein Abo weniger.
Passwordmanager werden dann auch für Passkeys einen Nutzen haben. Du kannst ja auch heute schon Logins in der Keychain speichern oder einen anderen Manager nutzen.
FAIL – Setzen 6!!! XD
1Password arbeitet bereits daran das Speichern von Passkeys zu supporten.
Mit 1Password habe ich aber geräteübergreifend Mac, iOS, Windows alle Passkeys immer zur Hand.
Außerdem dauert es Jahre, bis alle Websites umgestiegen sind. Solange braucht man Passwörter.
Ich hoffe doch dass 1Password weiter als Standard Passwortmanager behalten werden darf für Passkeys.
Wenn 1P Passkeys unterstützt. Von nichts kommt nichts.
Wirde offiziell von Agile Bits angekündigt … wird es für andere sicherlich auch geben …
Privat key and public key.. das es so lange braucht, bis das von der linux welt in den Mainstream kommt…
Habe jetzt gefunden wie ich den Passkey anlegen kann, dafür im mobilen Browser auf bei eBay einloggen und dann bekommt man die Möglichkeit den Passkey zu erzeugen. Habe ich gemacht.
Wenn ich mich auslogge und erneut anmelden will fragt er ob ich den Login mittels Passkey machen will, ich sage ja, und dann muss der Login doch noch mal über die App bestätigt werden.
Also wirklich einfacher ist der Login dadurch nicht geworden. Brauche immer noch genauso viele Klicks/Bestätigungen wie vorher.
Darum geht es bei Passkeys auch gar nicht.
Vielmehr wird hier die Authentifizierung vom Anbieter auf das Userdevice verschoben.
Stelle es dir so vor: bislang bist du zur Hotellobby gegangen und hast dem Portier deine „Parole“ genannt, damit er dich rein lässt. Jeder mit der Parole kam aber auch rein.
Mit Passkeys hast du den Schlüssel in der Tasche. Aber die Tasche ist biometrisch abgeschlossen. Das Hotel hat nur das passende Schloss (Public Key) und du nur den Schlüssel (Private Key).
Macht es nicht unbedingt komfortabler (wahrscheinlich wird 2FA zukünftig unnötig dadurch), aber sicherer.
Ich weiß nicht genau, was der eigentlich will. Irgendwo müssen die Passkeys synchronisiert gespeichert werden. Viele Passwort-Apps arbeiten bereits an Support (z.B. 1Password u. Bitwarden). Zudem steht es ja jedem offen als Passkey ein externes Device zu nehmen. Ich halte z.B. einfach meinen Yubico Security Key hinten ans iPhone, um mich auf der webauthn Demo Seite einzuloggen.
Mit dem freien Im- und Export verlieren die Passkeys aber wieder an Sicherheit, den so können diese entwendet werden…