Zugangsschlüssel
Einige Monate nach Apple hat auch 1Password die Unterstützung für Passkeys in seinen Produkten auf (fast) allen Plattformen als stabiles Feature deklariert. Obwohl sich die versprochene Portabilität im Moment auf die Synchronisation innerhalb des jeweiligen Passwort-Managers bzw. Cloud-Dienstes beschränkt, ist das ein passender Anlass für einen Testlauf.
Die Erstellung eines Passkeys auf GitHub (Settings → Password and authentication → Add a passkey) ist simpel, und die 1Password-Browsererweiterung in Safari verdrängt erfolgreich den macOS-Dialog. Um einen Passkey trotzdem in der iCloud Keychain zu speichern, muss man auf ein kleines YubiKey-Symbol in 1Password klicken, und im dann erscheinenden macOS-Dialog lassen sich unter Other Options
scheinbar YubiKeys hinzufügen. In diesem Sinne bewirbt GitHub Passkeys auch prominent als Upgrade für vorhandene Schlüssel. Upgrade
ist allerdings nur im übertragenen Sinne zu verstehen, denn ein YubiKey lässt sich nicht als Passkey registrieren (This cannot be used as a passkey
).
Das widerspricht der Dokumentation von GitHub, die den Unterschied zwischen hardware- und cloudbasierten Schlüsseln auf den Aspekt der Synchronisation reduziert:
Many passkeys support syncing, where your passkey is backed up by the provider's account system (iCloud, Google account, password manager, etc.). If you ever lose your device, you can recover your synced passkeys by signing in to your passkey provider.
In some cases, your passkey may be
device-bound, which means the passkey cannot be synced and is not backed up to the cloud. For example, you can register FIDO2 hardware security keys (such as a YubiKey) as a passkey, but that passkey will not be synced. If your passkey is device-bound, and you lose or wipe the device, the passkey cannot be recovered. If you are only using device-bound passkeys, it is a best practice to register passkeys on at least two different devices, in case you lose access to one.You can see which of your passkeys are synced, and which are device-bound, under
Passkeysin your account security settings. Synced passkeys will include a blue Synced label next to their name.
Weil YubiKeys auch laut Yubico ursprünglich als Passkeys akzeptiert wurden (YubiKeys can also be used as passwordless passkeys in their public beta on GitHub.com.
), könnte die Beschränkung auf cloudbasierte Schlüssel mit einer Limitierung der aktuellen YubiKey-Generation zusammenhängen:
[Passkeys and YubiKeys are] the same because YubiKeys have had the ability to create these passwordless enabled FIDO2 credentials (passkeys) since the YubiKey 5 Series became available in mid-2018. Currently, YubiKeys can store a maximum of 25 passkeys. We are evaluating increasing this in the future because of the likely increase in fully passwordless experiences across the web that require them.
Jedenfalls wird in der Weboberfläche von GitHub konsequent zwischen Passkeys und Security Keys unterschieden. Google gelingt es dagegen, eine maximal verwirrende user experience zu erzeugen. Während GitHub die Authentifizierungsoptionen in die Bereiche Password, Passkeys und Two-factor authentication gliedert, stellt Google im entsprechenden Einstellungsbereich (Security → How you sign in to Google) nicht nur alle Optionen in einer langen Liste dar (mit separaten Einträgen für Passkeys und Security Keys), sondern verbirgt hinter dem Eintrag Passkeys auch 2-step verification only security keys
. Darüber hinaus lässt sich ein YubiKey zunächst als Passkey hinzufügen – um dann als 2-step verification only security keys
zu erscheinen und bei der Zählung der vorhandenen Passkeys nicht berücksichtigt zu werden. Weil YubiKeys (und andere physische Schlüsselmedien) im privaten Bereich auch in Zukunft eine Nischenanwendung bleiben werden, werden die meisten Nutzerinnen allerdings nicht über diese Inkonsistenz stolpern.
Ursprünglich wurde public-key cryptography damit beworben, dass der private Schlüssel das eigene Gerät nie verlässt – was aber vornehmlich für Menschen gut funktioniert, die YubiKeys kaufen oder mit einer kompromisslosen Handhabung von PGP-Schlüsseln sozialisiert wurden. Für Passkeys gilt:
Unlike a traditional password, the private key is never shared with the site you want to sign in to, or stored on their servers.
Das weiterhin nötige Vertrauen in Microsoft, Apple, Google, 1Password und andere Passkey-Provider wird wahrscheinlich keine Hürde für die angestrebte mass adoption sein, anders als der endgültige Abschied von memorierbaren Passwörtern und Zetteln auf Monitorrändern.
Ebenfalls weitgehend obsolet soll die seit wenigen Jahren (und mit großem Aufwand) propagierte Nutzung von Multi- bzw. Zweifaktorauthentifizierung (2FA) werden. Derzeit werden – auch von den Passkey-Unterstützern – Telefonnummern (SMS), TOTP, Sicherheitsschlüssel und trusted devices als zweite Faktoren für die plattformeigenen Accounts eingesetzt, und obwohl 1Password die FIDO-Position vertritt (When you authorize the use of a passkey with your biometric information or device passcode, you prove you own and can unlock the device that holds the passkey.), wird zugleich das eigene Produkt als niche scenario deklariert, für das auch in Zukunft traditionelle Passwörter und physische Sicherheitsschlüssel als zweiter Faktor benötigt würden: Imagine, for example, you store your passkeys in 1Password so they’re quickly and easily accessible across your devices. But you need to sign in to 1Password to use your passkeys. Beyond the account password and Secret Key combination (that’s exceptionally robust on its own), you might further protect your 1Password information by turning on 2FA and registering a hardware security key as your second factor.
Hohe Sicherheit lässt sich eben nicht kopieren.