@jpsachse : or when your account gets pwned and the attacker does a better job proving that they are you than you - after all, *they* have access to your account - while you do not.

ANDROID PASSKEY BLACK HOLE
*Or* when you press a button "Clear data" (at the bottom of https://chrome.google.com/sync) which is accompanied by the text:

« This will clear your Chrome data that has been saved in your Google Account. This might clear some data from your devices. »

For you to subsequently find out that ALL OF YOUR PASSKEYS on (all of) your Android device(s) are IRRETRIEVABLE GONE (I reported this to Google in June 2023 and published it 6 months later in
https://seclists.org/fulldisclosure/2024/Feb/15). It's still unfixed.

WHY NO EXPORT AND NO BACKUP
W.r.t. being able to export and/or backup all private keys belonging to all of your passkeys: that's a big dilemma (depending on your POV).

The main (advertised, not taking into account a possibly desired vendor lock-in) reason is simple: if *you* have direct access to such private keys, *malware* running on your device does too.

The compromise is that they are automatically synced to your cloud account, and from there to other devices (of the same brand, provided they run an OS version that's not too old), including a new device if you brick or lose your old device.

However, if there's serious malware on your device, then, even if the malware authors cannot steal all of your passkeys (that is, their private keys), then you're toast anyway; a RAT such as AnyDesk may fool you into believing that you're logging in to website A while in fact it's B and they steal it's session cookie - and pwn the webaccount.

SYNCING PRIVATE KEYS
BTW it's hardly being discussed, but being able to synchronize secrets between secure hardware enclaves in such a way that *you* are denied access, is quite an achievement (considering that, if you buy a new phone, the only available secrets to the transport system are your definitely weak passcode, and your, potentially weak, cloud password that may be used to encrypt the private keys in transit).

I *know* that it's complicated because I accidentally found out around June 2023 that Android can get confused: passkeys *seem* to sync just fine, but passkeys created on phone 1 do not work on phone 2 and vice versa. Somehow the phones had started using *different* encryption keys used to securily synchronize them (I also mentioned that issue in my reports to Google in the summer of 2023, and I mention it in the FD (seclists.org) message).

I don't know how Apple syncs secrets in iCloud keychain, and neither whether a situation may exist where passkey's private keys sync but are unusable (like may happen when using Android).

APPLE'S OWN PASSKEY MISERY
However, Apple has got their own bunch of problems with passkeys being usable *without* requiring biometrics or a passcode to unlock them from iCloud Keychain, see https://infosec.exchange/@ErikvanStraten/113050312014160350 and follow-up (it gets worse every time I look at it) https://infosec.exchange/@ErikvanStraten/113053761440539290 (more details in earlier toots in that thread).

In short: if you don't use biometrics to unlock your iPhone or iPad (OR you do, but you have -unlikely- disabled a specific configuration setting), then anyone with access to your iDevice in an unlocked condition (*), can sign in to:
https://appleid.apple.com
and/or
https://icloud.com
WITHOUT entering your passcode (or using biometrics).

(*) your child, spouse, someone you don't know (well) who borrows your phone to make a call (because their's battery is dead), NOTABLY including a thief who stole it while you were using it (or saw you type your passcode and can unlock it by themselves: https://youtu.be/QUYODQB_2wQ).

I'm not sure yet, but this may even render Apple's anti-theft system totally moot.

@rmondello @johnbrayton
@agl

@webhat : Passwordless actually exists on iPhone or iPad under realistic circumstances - that is, not taking into account unlocking the screen (using a PIN, a password or biometrics).

Consider the situation when some stranger borrows your iPhone to make a phone call, or you let your child play a game on your iPad: in such cases they may be able to log in as you onto various websites. That is, without knowing your screen unlock code (or somehow being able to simulate your biometrics).

On specific websites this even also works when using passkeys (no PIN, password or biometrics is required to use the passkey).

It obviously is a vulnerability. But after I filed a bug report in June 2023, Apple denied that it is. And they've not fixed it either.

BTW this works (on iPhone or iPad) in Safari, Firefox, Edge and Chrome (except that in Chrome, "passkey without local auth", only works if, in condition below, only iCloud Keychain is enabled and no other 'optional' password manager - such as KeePassium).

The conditions are:

The password or passkey is stored in iCloud KeyChain;

EITHER: you've NOT configured any biometrics to unlock the screen (meaning that you must use a pincode or a password to unlock the screen - a use case quite common because some people don't like to use, or don't trust, biometrics),

OR: (not common, I found it during testing) 'Settings' > 'Touch ID and Passcode': 'Password Autofill' is OFF;

In 'Settings' > 'Passwords' > 'Password Options' (all quite common):
• 'Autofill Passwords and Passkeys' is ON;
• ' iCloud Keychain' is ON;
• Optionally another password manager is enabled (in my iPhone 'KeePassium' is ON).

Passkeys only: (this is irrelevant for passwords, and applies only to iOS and iPadOS versions that support passkeys): the website you (or the borrower of your iDevice) want to sign in to (using your account) must support "WebAuthn Conditional UI" [1] AND it must specify:
    'User Verification': 'Preferred'
(the latter value, stupidly, is the WebAuthn default; the other options are 'Discouraged' and 'Required').

[1] https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-Conditional-UI

In short, "WebAuthn Conditional UI" means that the website ALSO accepts a passkey in case you activate (tap in and see a blinking cursor) the user-ID input field (instead of tapping a button labeled e.g. "Sign in using passkey"). Doing that will invoke iCloud KeyChain and lets you select the right passkey.

Two examples (there are more) of such websites (for free testing purposes) are:
• https://passkeys-demo.appspot.com
• https://webauthn.io

AND, NOTABLY, Apple's production SSO site: https:⧸⧸idmsa.apple.com

Note that your browser is redirected to the idmsa site (in order to SSO to Apple) when you open the bugreport that I filed in June 2023:
• https://security.apple.com/signin?path=reports/OE19476493072

Here's the recipe for passwords:

Ensure that conditions , and mentioned above are met;

Open a website where you have an account with it's credentials saved in iCkoud Keychain. Invoke the log in screen and tap into the user-ID field;

Tap the proposed account name. Now iCloud Keychain autofills your user-ID and passwords into the right fields.

And the recipe for passkeys:

Ensure that conditions , , and mentioned above are met;

Open https://security.apple.com/signin?path=reports/OE19476493072

A box pops up from the bottom of the screen. Tap the X at the top-right to close it.

Tap in the input field "Email or Phone Number", then tap your iCloud ID at the bottom of your screen. Now you will be logged in to Apple without using local auth.

Note that you'll probably see a "403 access denied" error, because (although you HAVE logged in) you are not *authorized* to view te bug report.

This is passwordless 1FA because the possession of the (unlocked) device suffices.