Apple Passkey
developer.apple.com
developer.apple.com
https://fidoalliance.org/apple-google-and-microsoft-commit-t...
I wrote a FIDO implementation that protects the signing key using the system's TPM specifically for linux: https://github.com/psanford/tpm-fido
There is no reason why you couldn't implement a similar syncing strategy in a tool like this if you wanted to.
I'm a tpm-fido user myself by the way, thank you psanford!
> TPM tricked in giving out its secrets
To be clear, the key can never leave the TPM (with how tpm-fido is implemented). The threat is an attacker can perform an online attack by getting the TPM to sign messages it shouldn't. But you couldn't steal the key from the TPM and use it somewhere else.
But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.
Yep sorry you're right you wouldn't get the actual keys to use elsewhere, you can just use them as if you had them on the "compromised" device only, my bad.
> But it doesn't really matter for the Webauthn threat model. An attacker with root access can steal your browser sessions directly.
If you're using WebAuthn to authorize the emission of session tokens you're absolutely right, just get root and steal them from the browser :) but WebAuthn is more versatile than that. You could e.g. require a WebAuthn assertion to authorize a payment. In that case root access still doesn't help you with a secure enclave, but is sufficient to trick your server in believing the user has authorized the operation with tpm-fido, right? Again I absolutely don't mean to detract from tpm-fido, just pointing out that, very sadly, I don't think a TPM+fingerprint reader+software can really replace integrated solutions like Apple's secure enclave, or a yubikey, etc. In general unless I'm mistaken, it's not a tpm-fido shortcoming specifically.
This is literally true, and covers what was important in context, but warrants a little extra explanation. Since these devices are specifically for humans to interface with (they typically have a button or contact sensor, though some have keypads or a fingerprint reader) they are logically Human Interface Device class USB devices, but they do not speak the HID Keyboard or Pointing Device sub-protocols like your mouse or keyboard (or the built-in "take a photo" button on your web cam). Instead they provide a FIDO-specific HID sub-protocol, which is publicly documented, instead of operations like "Caps Lock pressed" it's got stuff like "Begin enrolment" or "PIN xxxx entered by the user" which only makes sense for this specific problem.
However, FIDO mode does not speak the keyboard sub-protocol. This means on the one hand it's not useable out of the box with some random device that allows USB keyboard input like the custom Yubico OTP mode is, but on the other hand it's able to deliver a good UX while having excellent security properties that would not be practical using keyboard emulation.
iirc, this relies on the uhid module to mock a physical fido2 key, and I'm not sure if there's a way to present a mock fido2 key OS-wide without relying on a virtual USB device. This was a bit of an issue when I tried setting up a similar fido2 emulator in a container, as the Google container OS doesn't allow loading kernel modules. Do you know if that's still the case, or if there's a way to mock a fido2 key systemwide without uhid?
On Linux, Chrome and Firefox interface directly with the USB and Bluetooth interfaces. There is no OS level abstraction for FIDO devices on Linux.
But then apple has your keys....
https://www.howtogeek.com/710509/apples-imessage-is-secure.....
> [1]For Messages in iCloud, if you have iCloud Backup turned on, your backup includes a copy of the key protecting your messages. This ensures you can recover your messages if you lose access to your Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
> If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service. Your device passcodes, which only you know, are required to decrypt and access them. Only you can access this information, and only on devices where you're signed in to iCloud.
In particular, Apple has HSM servers outside their hosting environment for auditable release of encrypted backups. This could be done for a support request for a lost user password or as part of a legal demand (say, family of the deceased seeking access to photo history, or requested by law enforcement with a court order).
The passkeys system uses iCloud Keychain, which is a separate mechanism and is encrypted before being sent to Apple using user-device-private keys. You should need to both get iCloud access _and_ provision a device into the "ring" before you can access passwords or passkeys.
You can disable iCloud Backups and still use iCloud
What's sort of surprising to me is how much they overestimated public support for their cause.
https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
But I imagine the FBU wouldn't like an end-to-end encrypted iCloud Photos at all.
If I lost access to my passwords (E2E encrypted), it would be an inconvenience.
There are plenty of non-LE use cases, such as people who need to recover access after a lost password, as well as families who want access to a deceased family member's information after the fact.
Apple has been (slowly) adding support for other recovery systems and for legacy contacts as first-class features. The UX for this currently lists Apple as a fixed option among a list of other options (such as personal contacts).
I expect long-term that Apple will have access to backup recovery for a number of people as a system default, but not for everyone.
Introduction to Apple security assurance
As part of our commitment to security, Apple regularly engages with third-party organizations to certify and attest to the security of Apple’s hardware, software, and services. These internationally recognized organizations provide Apple with certifications that align with each major operating system release. …
I can't think of any entity I would trust with securing truly sensitive information. For important stuff, do it yourself. For simple things, including bank accounts and such, I see no issue with trusting Apple.
I don’t know I buy the “for truly sensitive stuff do it yourself” line. That’s like saying for the truly lethal substances handle them yourself. Most people aren’t more skilled than the apple security folks. You’re almost certainly going to screw up your encryption or leave some vulnerability unpatched or unknown. Frankly I consider my iOS devices to be some of the most secure systems I have access to, and reading through their security documentation has informed that opinion.
The cynical view, of course, is that Apple's incentive and the Third Party's incentive can become very much aligned for the right amount of money.
> E2EE
If you can lose all your existing devices, and can still restore your data, then that data isn't end to end encrypted.
I'm taking the "end" in e2ee to mean your devices. Nothing but your devices can decrypt your e2ee prospected data. If a new device can enter the circle of trust without an existing device's corporation then there is a backdoor.
I imagine icloud keychain supports synchronization rather than backup
Also, ideally, your syncing passkey solution (whether that be 1password or iCloud Keychain) would itself be a combination of multiple factors before you can get in - in the case of iCloud Keychain, 2fa is on by default on your Apple account, and the keychain is also protected by your password plus the passcode of one of your devices. In general this is already immensely more secure than passwords because the website is verifying a signature instead of the correctness of a shared secret. So, it'd still be possible to have 2fa with the first factor being passkey and the second factor perhaps being another physical security key or maybe verification of an email code, but that would likely be reserved to enterprises and high-security applications.
(I assume Apple themselves aren't going passwordless themselves anytime soon, especially with how that'd work on fresh devices).
This is more abstract than physical possession of a single device with a non-exfiltratable private key. There are synchronization processes (so its one of many physical devices, on a sync fabric which allows devices to be added).
The process for adding a device should require multiple factors as well, but I believe there ultimately is a typically a recovery mechanism like a printed recovery key which would make this considered single-factor.
However, most deployed 2FA is via SMS, email, or backed-up TOTP today. The goal is to build a much more secure system that is recoverable enough to get consumer adoption, not to try to achieve say NIST 800-63 AAL3.
One ongoing proposal is that you get an additional device-bound factor as well. Seeing a new device-bound factor would let you decide to do additional user verification checks if desired.
iMessage itself is pretty slick but if I want privacy, I use Signal. It also gives me a crossplatform messenger as I prefer Windows and iOS.
Same as with Microsoft Edge. It's my favorite browser now, but I do give up a bit of privacy for convenience. If I want the best privacy I use Tor Browser. Which I always keep installed with Signal.
This is always my issue with 2FA or passwordless auth. You're forced to have 2 devices and are kind of screwed if you don't hvae two on you.
I was on a trip and broke my iPhone. It had my plane tickets on it to get home. I was able to get a replacement from Apple, they just gave it to me and sent me on my way. When I turned it on it wanted me to authenticate with one of my other Apple devices. By dumb luck I happened to have my iPad with me. If I didn't have that, I'm not sure what I would have done.
A co-worker told me to move all my 2FA to Authy as a means to avoid locking 2FA to hardware, but I haven't sufficently looked into it yet.
While I don't like passwords and understand their very real security limitations. I'm also not a fan of my phone becoming my identity.
I hope they'll go away from this, or at least give the option. I won't use their password/key storage until they do. 2FA is only as good as the weakest link, and SMS is the weakest possibility.
In this case, it's just that one of the factors has a weak backup option.
They don't offer a standard like TOTP, so SMS is the only option.
The decryption keys for that data are only stored on your iDevices. It's E2EE after all. So while you can access your Apple account via the SMS 2FA backup, you won't be able access your actual iCloud Keychain data/passkeys without some sort of access to your iDevices. (it might be sufficient if they're online somewhere and you have their login credentials?)
A bit confusing, but if it really is E2EE, then you can see why SMS alone wouldn't be enough to recover your Passkeys.
https://support.apple.com/guide/security/secure-icloud-keych...
This all seems very messy when bad things happen.
I think you still need to know your password, but that’s pretty reasonable.
They also added a similar feature to allow you to get into a loved one’s account/phone after their death if they set it up.
That doesn't solve it for me. None of my trusted contacts has an up-to-date Apple device.
I agree the inability to remove SIM as backup 2FA method is troubling. I would sign in blood any liabilities to be able to remove SIM as a backup auth.
Tying 2FA to hardware is for most of the common use cases a bad idea. Instead always use TOTP and keep the seed in a secure storage with multiple backups.
If on top of that you like to keep it on your phone to generate the code that way, fine. But at that point you can destroy the phone and it doesn't matter, you'll still have access.
> While I don't like passwords and understand their very real security limitations.
When used correctly, password are a fairly great solution with fewer limitations than competing solutions. By properly I mean generate yourself 128 bits from /dev/random, never reuse and store securely.
TOTP can be phished or man-in-the-middle'd and isn't as secure.
OTP is way less convenient than fido keys, so it's both convenience and security. The only downside is the cost, and the effort required for registering multiple keys which is easily compensated for by the ease of use during authentication than OTP.
Sure, for devices that need to authenticate themselves it is a decent or maybe the best solution. For me as a user? I am not convinced. It cannot compete with passwords.
For me, I don't consider that to be true.
I have a Yubikey on my keyring, and a backup Yubikey in my safe.
Losing my keys is an extremely rare thing (I've never actually lost my keys, closest I've come in the last 30 years is temporarily misplacing them or locking them inside).
I'm happy enough to deal with losing my digital access (via 2FA) tea[orarily under the same sort of circumstances where I've lost my keys. I might need to call a locksmith to get inside my house/car if I've locked them inside, or possibly to get me inside so I can replace the locks (and get my backup Yubikey out of the safe).
When I travel for work, I at least try to make sure I can get into critical systems using TOTP (on my phone and backed up with cloud accessible seeds), to protect against losing th4e Yubikey while abroad. I don't usually bother doing too much of that when I'm on vacation travelling.
To me the critical difference would be that my house keys are single purpose and only serve at a single location. I lost/broke keys a few times in my life, and the only issue was to wait outside the house for a few hours.
I didn't need to authorize 3d secure transactions when paying for the hotel or a taxi, didn't need to authorize accessing my Gitlab account at work, nor validate that I'm really me in the flurry of 2FA services. Nowadays phones and computers are more akin to wallets, and I'm actually more in trouble when losing access to my phone than when losing my wallet.
The world really hasn't appropriately quantified our reliance on little black fondleslabs.
When dealing with hardware, hardware access tokens should be required. When dealing with software, software access tokens should be required.
That way, you never have hardware compromised by remote tokens, and you never lose access to your software because you lost some hardware.
E.g., hardware tokens to login to a laptop, but only a software token (password) to get on a flight.
Of course there are a lot of use-cases inbetween with varying needs (escrow boxes with digital locks, intelligence services who need to verify the identity of their agents when entering/exiting premises), but I posit those come with requirements outside of the "ordinary".
The issue is if you have a fire and both your keys are melted, you're f'ed.
If there were one more layer of abstraction where all N of my keys prove that I'm "me" (or proves that I'm some entity) and the "me"-ness is the principal that gains access, that would be nice, but that's directly at odds with not wanting to rely on some third party identity/authentication provider.
Authentication is hard.
For some reason, this use case was not considered for Webauthn.
What is the life of a yubikey? Do they degrade over time horizons?
The reason I ask is that if you have a backup that you never hope to use it's likely to be accessed only very rarely - which makes me kind of wonder what if your primary yubikey fails in 15 years due to natural wear/tear/degradation due to the passage of time and your backup has succumbed to the same problem due to being just as old?
I've carried one in my pocket for ~10 years without a problem, now I want to replace it because it's too old to support ed25519. That's likely a fraction of its useful hardware life.
Not that I could see over about 4 years. I've been using one YubiKey (USB-A) for over four years now and a second one (USB-C) for over two. Each has been carried with my keys for at least two years.
But the right approach anyway is to use this excellent tutorial: https://github.com/drduh/YubiKey-Guide and generate your keys yourself, storing a backup in a secure location. This is what I do — so even if my keys get completely destroyed, it will be possible to recreate them from backup.
I don't think it's an issue in practice, certainly not for someone using them as they were intended, even heavily, but in theory a JavaCard implementation (like most of the smart card ecosystem, Yubikeys are still JC devices as far as I know) could "wear out" from use because of the way they work internally[1].
I've never personally seen that happen, and all of my Yubikeys still work, even the ones I bought over 10 years ago which were used far more heavily (20-30 ssh/gpg/piv operations per hour, every day, for years) than most people would use a FIDO key.
I've only managed to break other manufacturers smart cards by severely misusing them (as a USB-connected Linux HWRNG, I doubt the RNG command was designed to be called every few seconds for years).
[1] The JavaCard standard requires certain (all? I can't remember, it's been a while) objects in applet code to be written to persistent storage (meaning flash/eeprom), which has endurance limits. In practice they're not expected to be treated as permanent storage devices, if a card fails it's supposed to be replaced with another, revoke the old key pairs, register the new ones, etc.
A public/private key alone would have a similar issue, but the browser for FIDO keys gives the domain it's actually talking to. The domain is authenticated with TLS or the browser on an uncompromised machine won't send that domain over. The device only signs the challenge with the private key generated for that specific domain.
Anyway, the user would likely still click the link in the email since they are trying to log in.
I see that many people are slowly moving this direction and just can't fathom why do they fall for this corporate trap.
Do you consider a U2F key a device?
And it's not exactly 2. It's n+1, where n is the number of 2FA physical factors you expect to lose/break. If you expect to lose/break 0, then you need 1. If you expect to lose/break 5, then you need 6.
I don't like to have my key chain in the cloud at all. Loss or lack of access is far more likely this way. I already hate that services profile my device or location.
When will this happen? How will it happen?
Websites/services just make this way too difficult. Banks will host official services (that require login) on domains like www2.citionline.com with no way to know whether it's legit or not.
Apple has a marketing site at offers.appletvapp.apple which leads to prompts to sign up - how is any normal person supposed to understand this is legit? That domain is virtually indistinguishable from some phishing site at apple-iphone-offers.online
Apple don’t know your unlock passcode, so they can’t do it for you, but this is designed to cover the “my house burnt down with all my devices inside” type of scenario, or your own “I no longer have access to a device”.
I've heard this approach of cloud-based second-factor auth keys called "1.5FA". It's probably enough for most people, most of the time.
That said, in the case of a broken phone and away from your computer, you'd still need either a second device that's already logged into your vault or a backup recovery code. That's a good thing for all of us to keep in mind the next time we're traveling.
As per the Apple FAQ[1]:
"you can get a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn't Get a Code on the sign-in screen and choose to send a code to your trusted phone number. "
I'm afraid I don't follow.
I don't know what you're talking about, but I thought I was talking about an the manner in which Apple provides an alternative to Apple hardware 2FA.
i.e. "normally / if available", Apple will do 2FA on your account by virtue of you being already logged in on another device. HOWEVER if that device does not exist (or you only own one Apple device), then as per my FAQ link, Apple DO provide an alternative mechanism that DOES NOT rely on the existence of a secondary Apple device.
This methodology is no different to any other 2FA alternative mechanism (e.g. "backup keys" or other websites/services that also use phone/SMS as backup, e.g. Microsoft Authenticator).
Thus I believe I was correctly answering the OP's question AND I don't see any problem with the way Apple does it because in practical terms its no different to anyone else in terms of "backup" for 2FA.
Thus I've no idea what you're claiming to be "fake", and I'm not sure if I want to be drawn into that discussion because it sure sounds like Apple bashing that is not factually supported.
Part of that is on the "security contractors", who are objectively snake-oil salesmen (when you make a living selling people publicly, freely available, publicly supported software, and charging 6 figures for it, that is the definition of a swindler), especially since they started propagating their whole "security regimen" as a set of tasteless, mostly useless "security awareness" trainings. They harped a lot on choosing good passwords, caused a lot of bad password security practices on almost every website (I still see this everywhere online - please use 10 characters with one symbol from (!$./ ... etc) and 1 number - no - use entropic password measurement and maybe don't assume your site is important enough to warrrant a high-entropy password).
So, once we were all left with an unsustainable bag of crappy passwords for every buytoothpaste.com website out there... well we all had to try to invent something else. There was SSO OAuth, that failed because it was overcomplex (or got rolled into a banal corporate policy system which was horridly complex to deploy and the security contractors got paid to audit the bad systems).
Then pile on the other heap of bad password strenghtening abstractions (2FA), etc., you get to today. We never had SSH for the browser, GPG/PGP remained meh, so the result is a constant stream of "new solutions" to a problem which could have been solved by a) Not caring as much about passwords, communicate risk to the users instead b) fixing ssl/ssh.
And why did nobody do a) or b)? Again, I blame "security contractors" for a) and b) people not being paid to do it.
Yeah, profit-seekers will always try to capitalize on chaos, that's hardly conspiracy, that's just business.
It is at an API level, rather than the transport level like SSH and TLS, because applications often often have more complex requirements than these provide. In particular, SSH and mutual TLS typically expect traffic to be authenticated at the transport level on use, and for the credential to exist and be evaluated at first interaction. Websites typically have registration and self-service management functions, as well as anonymous access.
There is also nothing especially new about the use of hardware secure elements, nor was anything new claimed.
I will say as someone who implemented website smartcard-based authentication a decade ago - the experience was typically very poor, because the software stack had not been built for that use case, and often relied on third-party components which were simply sub-par.
There's a lot to be said for reusing technology, but there's also a lot to be said for creating the best possible experience. The MTLS experience that has existed has not gotten any notable consumer adoption for very valid reasons.
WebAuthN is the standards for defining how this works on the web.
Fido is the alliance (+standards?) for multi-platform interoperability. How do I get my private keys from my iPhone into Chrome on my PC?
What if the only computer (or even the only Apple computer) a user has is an iphone, and someone swipes it?
Surely in that case you're now locked out of literally everything, no?
Please explain to me why this is stupid because I'm certain someone thought of this very early on.
If you still can log in to iCloud, you're fine.
If your Apple ID password has been changed, Apple provides a workflow to regain access to your Apple ID [1].
There's also a process for account recovery for situations where you can't access your Apple ID because of two-factor authentication [2].
[1] https://iforgot.apple.com [2] https://support.apple.com/en-us/HT204921
Its about time something like this really took off. Hopefully it will get rid of dumb hacks like text message verification that a lot of companies use. Plus database leaks will no longer be a big deal since they can't really do anything with just a public key.
The private key is stored in the device’s Secure Enclave. It’s the face and fingerprint recognition which authenticates to the Secure Enclave in order to retrieve the private key.
When purchasing an android phone, you do need to sync the private key to the new device. Hence Passkey, which uses iCloud as its secure and authenticated syncing scheme.
If you lose your only iPhone, you lose the keys. Using your face is different device does not get you access to your old keys.
But they're in your iCloud Keychain. You should just log in to iCloud and have them again.
How you do that after you use Apple Passkey and lose your phone? (and SIM)
https://support.apple.com/guide/security/secure-icloud-keych...
Can you explain how a person can login into their iCloud and recover their iCloud Keychain after they have lost their only Apple device (iPhone) if Apple Passkey needed to access iCloud?
https://support.apple.com/en-us/HT213305
>To recover a keychain, a user must authenticate with their iCloud account and password and respond to an SMS sent to their registered phone number.
In other words. If you lose your iPhone (containing your SIM) you can't get access to iCloud or iCloud keychain until you have a new SIM with the same phone number from your carrier.
If you travel in a foreign country and lose your iPhone you are locked out of "everything Apple".
You can choose which preregistered number to send a message to (or to be called with a recorded voice) in the event you need access to your account in an emergency.
This also implies you have no other Apple devices which are signed into your account, as they will receive a code by default.
SMS or voice fallback is "plan B".
None of the methods you mention are something that should be expected from normal users. Or they don't work when traveling. I travel a lot.
"There is a way you could set it up" does not mean Apple has a good solution. As I'm a person without family and only one iPhone I stay away. People who don't pay attention are fucked.
Only if you have no access to any device do you need to fall back to account recovery via SMS or phone call, to any pre-registered number.
What’s different about this?
WebAuthn continues to work great on iOS and Mac OS, so I'm not sure there's a good reason to add some other new standard. (Though I do have the controversial opinion of wanting Apple to share my credentials between all devices. I have my iPad, iPhone, Macbook, and portable security key all enrolled in SSO. I don't mind this but I feel like it probably hinders adoption over an easily-hackable pasword that you just remember.)
Everybody here is a Relying Party when they use HTTPS. The Web PKI promises that this is really news.ycombinator.com to you, the HN reader, so long as the math works (RSA, Elliptic Curve Cryptography and likely AES) and so long as your browser vendor did their job, and the Issuing CA (DigiCert) did their job.
Relying Parties should ideally know why their trust is well-founded. For example, in the Web PKI examining this cryptography is the job of the Internet Research Task Force (related to the IETF), the browser vendors are responsible to you directly, and the Root CAs are overseen by m.d.s.policy, run by Mozilla on behalf of their users and everybody else's users.
Whatever "based on webauthn" means...Let's hope it's not just a buggy implementation of WebAuthn as they did with OpenID Connect
They start with the standardized technology, do their little twist (which usually involves fixing some standardized bug that affects performance and people have been complaining about for years), and patent it.
I wrote another comment elsewhere but there are some other issues with using WebAuthn as a primary authentication mechanism right now, especially things like new device enrollment when using platform authenticators (not trivial but not what people are used to), so most people opt to design it as a 2FA mechanism since that normally fits into existing designs easier ("just another auth device" like TOTP or SMS.) So Passkeys will help smooth that a bit for Apple users.
Also we still need ways of exporting keys and software (like 1password) needs to synchronize them, manage them securely. There's still a long ways to go on that front, which probably won't be handled until stuff like this has settled.
If you can use WebAuthn today in the browser and handle new device enrollment and have designed with it in mind as a primary auth mechanism, you're way, way ahead of the curve. This is just Apple's attempt to help kick the can further down the road for their users; you may not need to use Passkeys at all. There's just more to do before we can actually use WebAuthn as the basis to replace passwords in more places.
That's the point of passkeys here: iCloud Keychain syncs them, and if you want to use your keys on a non-apple device you'll be able to scan a QR code, which initiates a new BLE connection so that your phone can sign the login request remotely.
Like 1Password
https://blog.1password.com/1password-is-joining-the-fido-all...
So, if you have macOS or iOS software for Mailpace, this is a way to have the same workflow for that as you get with WebAuthn for the web site.
Android likewise has an API for apps to get this, as well as the Chrome browser on Android having WebAuthn, and if you have apps on both platforms it might make sense to do that there too.
Technology wise the key difference is that for WebAuthn the Relying Party ID - the thing that distinguishes GitHub from Facebook (for example) is based on a DNS name, and that's verified by your web browser, while for these app APIs the RPID is based on some platform identifier and is verified by the host OS.
So, GitHub won't get your Facebook credentials because github.com and facebook.com are different DNS names. Likewise "The 100% Legit Mailpace App" on iOS can't get the credentials for "Albert's Real Mailpace App" because they have some different internal iOS ID.
At the backend, validation is pretty similar except the RPID is different, and you'll need to read the documentation carefully to figure out what the RPID is for these app APIs, if you have a pile of magic numbers for "your" app it's probably one of those. You don't get to specify, because the whole point is that nobody can impersonate your app (well, obviously on an iPhone Apple could impersonate it, and on Android Google could)
The native APIs on Android, Apple and Microsoft platforms leverage relying party IDs which are web origins (e.g. https://github.com) whether doing native or web apps. The same native API is typically used by say Github Desktop as say the Chrome Browser.
A native app needs an entitlement and a file on the web server to enable functionality for particular domains. A browser gets an entitlement to request credentials for all domains.
Technically, a Passkey is 'just' a key pair and other authentication information, associated with a web origin. It's meant to be a broad consumer facing term that resonates similarly with 'passwords' to convey its similar usage.
Apple platforms, along with Android and Windows, are implementing a system that synchronizes passkeys within their respective ecosystems. They are adding ways you can entitle an application to work on behalf of a web domain, and thus get native access to register and authenticate with passkeys as well.
A Yubikey or other FIDO device has been doing hardware-bound passkeys for ages. They just didn't use that term, instead calling them FIDO credentials.
The above platforms are also working on processes to allow usage across ecosystems - for instance, using your iPhone to sign into a Windows desktop.
https://developer.apple.com/documentation/authenticationserv...
I am already using Passkeys on some websites.
It’s available at https://passwordless.dev
Note: We also maintain the open source fido2-net-lib, the API just lowers the friction for devs.
If the user is not running a model OS they could still be supported by using what is known as a security key (yubico) etc.
The Passwordless API can also help with out of band authentication (using a iOS device to sign in on unsupported old laptop)
I'm imagining a world where all PCs/Macs/Smartphones have FIDO/WebAuthn and there's no other way to log in. Can I setup up multiple IDs on my iPhone and decide which services get to be associated with which id? I get that supposedly iPhone (etc) will (may?) give out a different number to each service but they'll still be associated with a single account at Apple's level. Further, it's likely these services will ask for more info and Apple will give it to them.
As it is I have a different id for almost every service. I'd like to keep it that way.
FIDO2 resident keys do support multiple identities for a single relying party (site).
You won't have to imagine that for long, because that's the world we are sprinting towards.
Once practically everyone has accepted and adopted this system, governments (having already banned E2EE messaging apps by this point) will complain that Big Tech are allowing cyber-terrorists to maintain anonymous identities online and not doing enough to protect the children.
The offices of Apple, Google, and Microsoft would then receive calls from the national tax/anti-trust authorities saying the government was thinking of launching an audit/investigation into those companies and wouldn't it be a shame if something happened to their profit margin that year.
Within a few months we'd see these companies all "voluntarily" release software updates which add a "Citizen ID" field to every FIDO interaction, with those IDs being issued by a government API and verified using a bank card and facial recognition.
It's an interesting issue, and wildly varies depending on who manages her devices. For instance if she has an iPhone with a windows computer, a third party manager brings uniformity to how she deals with login on any device she happens to use. Same if she happens to use a Chromebook.
Or even if she uses an older Apple device, I'm assuming passkeys won't come to previous OSes, and upgrading a 2018 MBP just to get passkeys would come with a lot of trade-offs.
Perhaps I'm seeing it as, it's already a complex mess already, and Apple didn't come with a silver buller to solve all that complexity in one swoop.
PS: password managers are fairly straightforward to explain: it's a digital equivalent of the password notebook they keep in the side drawer
If you won't dig into even an iPhone's settings to learn what's available, what it can do, good luck to you. That curiosity and willingness to play around, accompanied with Google searches when they don't know what something does, is critical in making it in the world today. Or if you remain a rube, and they will, you'll get scammed someday because you're not on the top of your game mentally. Just lazying it up.
I've come to two solutions. Either Bitwarden or KeePass with only a mobile client to begin with. If they are managing that, then I graduate them to clients on multiple systems and the integration advantages that brings.
I'm a KeePass Windows and Strongbox Pro user on iOS myself. Prefer to keep that database where I want it. Bitwarden is probably the ticket for most people though. If you start them on mobile only, it helps a lot.
Nana and Papa are not locksmiths.
Nana and Papa still deserve to have a front door to their house that can't be lockpicked.
Normal people, who have other interests in life than configuring technology, should have secure devices and data from criminals. And they shouldn't have to configure 5 different obscure password managers to do so.
Society shouldn't allow criminals to take advantage of Nana and Papa.
This is one of the most embarrassing comments I've read on Hackernews.
To avoid being lockpicked you only need two-factor. It's that simple. You need some form of password manager, even if it's paper and pencil, until a megacorp handles it all for you. That'll require a universal standard to be adopted, which won't be here soon.
The rest of your assertions are assuming a premise that I never stated. Feigning offense on the internet has really gone over the top. Of course people should have secure devices.
Nana and Papa are not technologically literate enough to perform the kinds of configurations you suggest. In depth custom password manager configuration isn't for them.
They are not at fault for that.
We simply cannot expect all of humanity to be that technologically literate. There are many, many roles in life that don't involve electronic devices that are immensely valuable.
I think that's what I'm deeply offended by. It's not feigned.
But I apologize I don't mean to imply you are talking in bad faith. That's out of line.
My view is.
Engineers cannot expect untrained, ordinary, people in the real world to operate and install complex software.
We have a responsibility to provide them with secure devices they can use.
Privacy and security from bad actors is a moral right.
I don't worry too much because most of the most important entities, such as say Social Security in the US forces 2FA on users. I just signed up on that site the other day, and they simply force you to do everything securely, or you don't get in. I found the process lengthy, but appropriate and well-done. That's a great example of how to secure something important without waiting on industry to solve everything.
I agree password management is one of the most difficult parts of the average person's digital experience. Until it's solved through a universal pact by Google/Microsoft/Apple, the built-in password manager on iOS is pretty decent for those types of users. Passkey is a good step in popularizing a solution.
One project I've worked on, something like 5-10 out of every 200 people successfully misspelt their own name in text forms.
Non-professionals create human error. The more details the non-professional has to configure, the higher the percentage of human errors across your userbase.
The issue is, in device security, human error is not acceptable.
Eg., I was telling a middle aged person (50 years) about password managers and were unable to grasp the idea of it. 'Why would you store passwords in cloud based password manager from a company I have never heard of, just type a password and write it down on your diary (OS notes app) or just store it in chrome. I trust google (chrome) to keep my passwords safe rather than with some sketchy company I have never heard of (the sketchy company if one of the most reputable cloud based password management company).
This is more than a little ageist, don’t you think?
> Why would you store passwords in cloud based password manager from a company I have never heard of?
This is actually a very valid question; hope you didn’t just dismiss it due to “the oldie doesn’t understand.”
It was not meant in that way, same thing could be said about 20 year old, who have no idea (or unable to grasp) about password manager but more importantly about Authenticator Apps (Micorosft Authenticator, Authy, Aegis).
>This is actually a very valid question; hope you didn’t just dismiss it due to “the oldie doesn’t understand.”
You are reading my comment from a wrong angle.
[0]: https://support.mozilla.org/en-US/kb/end-of-support-firefox-...
I used Apple keychain for a while, and it wasn't good at recognizing which site needed which password, not even including account switching when you want to use a different one. If it hasn't significantly improved, it will be a pretty frustrating experience for user heavily relying on it (and not just using the same 5 sites the same way everyday)
Did we use Gmail, Twitter, Signin with Apple, Github, Linkedin, or do I actually have something stored in my password manager associated with an email and if so, did I store it in the browser's password manager, the OS's password manager, or my third party password manager?
Safari on iOS suggests a password even if I'm trying to paste on in from my password manager
OSX can be the same way
They all sync
and I never bothered to disable them because I never thought about it, but sometimes I'm in a rush with a service I think I'll never use again and use the suggested solution in one of the browsers
I think you should resist sooner rather than later and switch to something cross-browser and third-party.
But it's up to you, of course.
Work vs home is one driver.
And for some cases, "Login with Google" or similar is nice because it integrates Google pay, removes sign-up friction, etc. I'm aware it has downsides, but it remains useful in some niche areas.
I figure privacy is fine as long as the implementations allow you to select which account to login with. Is this currently a thing? From everything I read it seems like the current implementations are only meant to support one identity?
EDIT: These are great responses, also curious if anyone is aware if Apple's current implementation supports multiple identities?
But you can't simulate an attestation that you're using a device from one of the "approved" manufacturers in the cartel. This is basically DRM for human identity.
This means you can (and should as a designer) have multiple sets of credentials for one "user", multiple distinct credentials that you (the user) can register to multiple separate "user"s in the application, etc.
I believe all FIDO2 authenticators (like hardware keys) should generate a new hardware / key ID for each request for pairing a new credential. I know that my key does that, when I was working on implementing WebAuthn for $DAYJOB.
https://developers.yubico.com/WebAuthn/ is a good jumping off point.
There is also no way for a site to know if two sets of credentials belong to the same physical hardware device or not. Sites can request the attestation certificate, but that is not unique per device (the spec says the attestation cert should be shared by at least 100,000 devices). If you want to see the attestation cert for a fido(2) device, I made a little tool that will show it to you: https://what-the-fido.sanford.io/
iCloud passwords works with Chrome and Edge on Windows but generally yeah you need to be all-in on Safari :V
I'm sure as the popularity of WebAuthn grows there'll be more and more demand for cross-platform compatibility until eventually the big players are forced to implement it, but it's going to be kind of rough in the short term until then.
I can already hear them making the “we can’t because it will impact users security” argument in my head.
You can also export everything from iCloud Keychain to use with another password manager.
They could always use Passkeys as an opportunity to lock things down but it would be in direct contrast to what they have been doing with password management recently.
I can't export anything. This menu item is always disabled for some reason.
It's possible I'm unaware that there is a simple protocol for this. Am I incorrect here?
And if you do move away from Apple's Passkey to your second key, you'll want to buy and set up a new backup key. So have to do the tedious mass-enrollment anyway.
The hundreds of other sites will probably take years to support Passkeys (they don’t support U2F either). I can convert them when they support it and I happen to do something else account-wise.
I don’t think it’s a huge issue.
That being said, it's not a problem in the real-world because FIDO is so sparsely supported. Hopefully PassKey speeds things along.
How much would you be willing to pay for such a service? ;)
Unfortunately, security and usability are always in balance.
Let's say that I have two laptops, a MacBook Air and a Lenovo ThinkPad. I create an account with an Apple Passkey on a website. I can now log into my account on the MacBook Air, but not on the Lenovo ThinkPad.
How do I register my ThinkPad? I need to log into my existing account to add a new authenticator (Windows Hello in this case). Does the website offer an email link I can use to log into the account? Do I have a backup code that I need to use? Do I need to set a password and log in the normal way (thus removing the advertised phishing and database leak benefits)?
Most importantly, hopefully web sites will implement support for multiple authenticators, so you can actually use this safely without relying on a cloud-synced solution.
I hope this pushes out other, less secure and more tedious 2FA methods. However, once it becomes popular, sign in with WebAuthN only will likely not be enough, as attackers learn to attack it (e.g. stealing software-based tokens, adding a cloud-synced device, hijacking already-authenticated sessions from compromised machines)
They must have considered this because that's would be a huge hassle.
There are definitely some benefits though, such as immunity from phishing. Surely we as the industry can bring them about in a way that doesn't involve cryptographic vendor lockin.
What would it look like to do #2 safely, without enabling the phishing that we see today with #1?
If Apple has decided that the risk of getting your passkeys phished out of your Apple iCloud Account is outweighed by the benefit of users being able to restore/sync login details immediately when they buy a new iOS device and log into it, then I think it's reasonable for users to expect the same treatment and the same experience when they're moving away from iOS.
If Apple wasn't backing up any of the logins, and they had committed to when you trade in your phone and upgrade to the latest iPhone forcing you to manually re-create all of those keys one-by-one using your recovery option, then I'd accept not having an export option for Android/Linux/Windows. Otherwise, it will just seem really suspiciously convenient to me if they ultimately decide that exporting keys is acceptable risk unless it's to a competitor's device.
As far as I can tell, there hasn't been any official confirmation that users won't be able to export them to non-iOS devices, so maybe it's all worry over nothing. But I don't think security is a justification to apply restrictions specifically only on devices outside of Apple's ecosystem.
If you offer users a way to export, then you offer phishers a way to social engineer users. So either you prevent social engineering (lock-in: yes), or you allow exports (lock-in: no).
Which choice has a higher precedence when serving the market of "non-technical mobile phone users"?
Gullible people will cheerfully complete any attacker-described PC syncing process, ignoring every security warning presented to them, in order to give away the keys to their accounts. They’ll use a friend’s PC, or a library PC, or anything under the sun, if the phished promises to give them something for nothing.
We are having a debate about an Apple policy that doesn't exist. Apple is not following the "keys never leave your device" model, so that security model has nothing to do with whether or not Apple will engage in vendor lock-in.
We're not making the choice to leave users vulnerable to phishing attacks, Apple made that choice, and we're arguing that because they made that choice they have no excuse to also engage in vendor lock-in.
This is how vendor lock-in allows protections against phishing that a naive data export would bypass. No one has yet suggested how this level of protection can be offered to end users without lock-in, across many such posts and threads, for many years now. I remain hopeful that there’s another way, but I’m not going to demand Apple do insecure exports at the expense of users in the meantime.
It's not my intention to necro an old thread, but I've been away for a while and haven't seen this. For the record, I have never seen a convincing argument for why these standards couldn't be applied to other platforms, particularly now that hardware attestation is a thing. It is very convenient to Apple that the line between what hardware they trust and what hardware they don't begins and ends with their own devices, even though there are plenty of devices on the market that could be verified using similar hardware checks.
Additionally, I don't really see how access to iPhone hardware is a deterrent against phishing. It makes it harder, maybe, a little bit, but it doesn't eliminate the problem. There's nothing in this scheme that I can see that Apple has published that says that it won't allow backups to be restored to used iPhones. Maybe I've missed something in the docs I've read, but I don't see why you would need multiple iPhones for this at all. Reuse the same one multiple times.
A password and pin is not a defense against fishing, and saying that criminals won't have access to a mass-market consumer device to me seems really naive. People do get phished out of their iCloud accounts, they're not magic. Getting users to turn over their iCloud passwords is how existing iCloud phishing attacks happen today.
What we see with the above scheme is Apple deciding that completely eliminating phishing attacks isn't as important as allowing iPhone users to back up their keys. Where they arbitrarily draw the line about how much phishing risk they're willing to target, and whether the location where they draw that line seems specifically designed to create the most vendor lock-in possible -- I think that's something that's worth criticizing. And I think characterizing the place where they've drawn the line as if it's a fact of nature rather than a conscious decision to decrease security and allow phishing attacks but only when it benefits Apple to do so -- I think that's an excuse.
The reality is that Apple's current implementation is vulnerable to phishing, and Apple has decided that leaving that vulnerability open is worthwhile for users. If I have access to your iCloud credentials (which are vulnerable to phishing attacks) I can restore your login keys to an iPhone I'm holding and then use those keys to access your other accounts.
> No one has yet suggested how this level of protection can be offered to end users without lock-in
To be clear, I'm not certain I would have any objection to Apple offering a secure level of protection that guarded against phishing, even if it resulted in some lock-in. But they don't. Hardware restrictions for mass-market devices are not a defense against phishing.
I am not demanding that Apple make its products less secure, I am demanding that Apple not pretend that security is the reason it's restricting its devices at the same time that Apple exposes its users to the same phishing risks within its ecosystem.
There is no reason why Apple could not (using the same access system they've already decided is good enough for iPhone restoration) also allow users who move ecosystems to access iCloud the same way and restore to certified Android devices. There wouldn't be any loss of security there beyond what Apple has already decided it's comfortable with.
I consider the binary you describe to be a justifiable reason for Apple to offer no way to export from a phone, but that's not what they're doing. And I do not consider it a justifiable reason for Apple to allow only exporting between iPhones.
Apple is syncing passkeys to iCloud, presumably so they can be synced between devices and restored if a device is lost/destroyed. That's an export option, and iCloud syncing/restoration between phones is vulnerable to phishing attacks, but Apple has decided that the user experience without iCloud backup would be so bad that they're excusing the extra risk that users have their iCloud account phished and their keys synced to an attacker's phone.
> Which choice has a higher precedence when serving the market of "non-technical mobile phone users"?
In Apple's case, they have decided that allowing users to recover accounts easily is more important for non-technical users than protecting them from export phishing attacks. They've very explicitly said here that they think that allowing export is more important than preventing phishing.
We can debate whether Apple made a good choice with that, but having made that choice, there is now no reason for them to say that Android transfers would be a unique security threat.
Since it's all just FIDO2/webauthn under the hood it's hardly lockin. It's a bit of Apple UI tinsel to make life simple and their excellent icloud keychain sync.
On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.
[1] https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
https://support.apple.com/en-us/HT202303
> If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service.
> Instead of protecting all of iCloud with end-to-end encryption, Apple has shifted to focus on protecting some of the most sensitive user information, such as saved passwords and health data.
> But backed-up contact information and texts from iMessage, WhatsApp and other encrypted services remain available to Apple employees and authorities.
It does mean that the data is not sitting in clear-text form on the provider's disks. But the exact details of that encryption may vary from provider to provider.
So your analogy makes absolutely no sense.
Semantics aside, holding private keys hostage with no recourse is Orwellian. A for-profit company has no business being a centralized identity authority.
But there was a picture of them using it with a Windows machine. So they’ve thought of it.
And what is new is that it looks to become a widely supported FIDO standard i.e. Google/Microsoft are onboard whereas before it was an iOS/macOS only technology.
I'm sort of expecting Google to follow suit with the next Android release, and perhaps Microsoft after that when the next iteration of Windows 11 drops (or at the same time, as Microsoft doesn't have a mobile market and relies on Android and iOS integrations).
But at todays WWDC presentation they announced it as an official complete feature for the next releases of their OSes.
(That’s why there is so much Apple stuff, presentation just eneed about 15m ago)
I would speculate Apple is not going to support this, and Apple will retain control of the private keys, and do the request signing like an old-school USB FIDO device, but I don't know for sure.
Any way to use this standard if you're not Apple/Google/Microsoft? I'd prefer an option that Apple/Google/Microsoft can call a service (that I control and authorize). I want to be able to self host such a service or have an open marketplace that can compete to serve this service.
When setting up a credential the secure enclave in your apple device generates a public/private keypair. The public key is sent to the web service for storage and the private key is stored securely and synced between apple devices using end to end encryption. When you want to login the website sends a message to be signed, the apple device prompts for finger or face id to unlock the private key and the message is signed and returned to the website. The website uses the public key to verify only you could have signed the message. If an attacker dumps the website database all they get is a public key which is useless without the private key.
It's unphishable since the browser checks the origin hostname before the faceid prompt. Spell-alikes like g00gle.com will prompt for their own unique key that you don't have since it was never created. Apple's security doesn't matter since they never had the private key; it is sent between Apple devices using end to end encryption.
https://news.ycombinator.com/item?id=31272867#31274677
> FIDO security keys that explicitly support backing up and restoring their master secrets?
I am hoping that if Passkey becomes mainstream they can finally stop pestering me when they hit an edge case.
I doubted Apple's touchID and FaceID but honestly, without it my parents would be a lot more vulnerable. My hope is that this gets them to strong auth everywhere instead of really weak passwords.
Apple is almost there with mail, addressbook, and calendar but perhaps surprisingly they aren't as seamless as it is with passwords.
* For example this allowed me to plug 1password into my parents' phones and computers and use the shared vaults to make sure I could help them get unstuck from various web sites. Plus when they pass on I'll still be able to help the surviving parent to get access to things they need from the other parent's device. The apple one is disabled so they can't even accidentally get something confusingly stored in it.
This is basically the biggest problem with WebAuthn today: the credentials are tied to the browser -- or really whatever application is using WebAuthn, browser or not, name aside -- which means that if you register for a service with Firefox, you have to re-register with Chrome. If the service is designed for it, it might associate multiple public keys to a single "user." So Passkeys are just a pretty natural combination of two things to fix that: "WebAuthn keys, but inside iCloud Keychain." Presumably any apps that integrate with iCloud Keychain can then use them as expected.
Of course you can just export the key material, which in a sense is "all" Passkeys are doing: they're a formalization of how to export and manage those keys in keychain.
But there are still some major issues:
- Enrolling new devices from old ones. This is especially tricky for platform authenticators. For example I register for a website using FaceID on my iPhone, which uses the "platform" authenticator rather than the "cross-platform" authenticator, and now I need to now enroll my Macbook and Windows desktop. They both need new keypairs, because the original account is using a platform authenticator. And the new keypairs might be either platform or cross-platform authenticators. This is especially prevalent on browsers (apps can work around it with a more specific scheme; see below.)
- Similarly: cross-platform software for sharing or syncing credentials. Something like 1password but with WebAuthn support for handling those cross-platform webauthn keys.
Both of those require a lot of software and decision making to get it all working correctly, both on the side of operators and clients. For example, in your own application (not a browser), you could simply use a platform authenticator like FaceID to read a cross-platform WebAuthn credential from iCloud Keychain, which would avert part of problem 1. But in a browser, mac or iphone users would probably like to use FaceID/TouchID, which are only available as a platform authenticator, so you'd have to handle that case of new enrollment.
There are also a million other issues, for example Windows Hello has like a million weird edge cases for how it works in and outside of the browser. macOS seems to be the furthest ahead here with the introduction of Passkeys, and the strong system-wide support for TouchID/FaceID/etc. I do not know what the state of Linux is; presumably you could integrate this with something like gnome-keyring but there's no synchronization service either.
So we're still a ways away from actually eliminating passwords. WebAuthn works today but does need a lot of extra oil to make it smooth, and it's still not a primary authentication mechanism unless you're very careful about your userbase. But Passkeys are a good start and will mean you'll need passwords in less apps, and you'll be able to log in securely more quickly. It's a small but needed step.
That's definitely not true. My Feitian ePass for example (very cheap USB dongle that lives with my house keys) works just fine to sign me into GitHub on this desktop PC w/ Firefox on Linux, it works fine via a USB-C to USB-A adaptor to sign in on my Android phone w/ Chrome, and likewise on the Windows laptop I use for work when I needed to access my personal site briefly at Christmas and that was the only laptop I'd brought with me.
If you have credentials tied up in some proprietary system then, yeah, they're trapped in there, and in Apple's case they've decided to make it possible to move the credentials to another Apple device via iCloud.
https://blog.1password.com/1password-is-joining-the-fido-all...
But since this experience has been so confoundingly annoying, Calm.com won't get a penny from me. (Not even sure I want to blame them... but rather how it's impossible for my wife to just "share" that credential with me even if she wanted to)
Not being able to share a certain type of login (for this kind of family sharing scenario) has really soured me on the more personal use cases for these technologies, even though they are really solid from the tech side.
Like people often say, most products are competing with Word, Excel, and email, authentication is competing with me just being able to tell a human my username and password.
Again, there are many instances where being able to share these credentials seamlessly between non-power users is totally legit. When I sit with my dad to help her log in to his patient portal to get some medical info. Or when my mom wants help to review her Verizon cell phone bill. Or when I get my wife's credentials to cancel a hotel reservation.
How are they going to solve the totally legitimate sharing use cases? Using PKI actually gives you a wonderful set of tools to do this (underlying implementation could be that we generate a temp cert that expires in 24 hours, signed by her original credential certificate saying it's a shared credential, etc)
I really hope these are the use cases that get more fleshed out before these technologies reach mainstream.
Apple says you can "download content" bought by other family members[0], but I guess this doesn't work for subscriptions?
That's a real missed opportunity. I would expect them to at least allow the app developer to opt in to sharing. Selling two licenses into a household has to be pretty rare, whereas having happy-family customers is great word of mouth. "My wife uses FooApp and now I use it too!"
Family Sharing is set up in such a way that you're punished for creating child Apple accounts as Apple recommends, because you'll need to repurchase MOST IAPs several times over.
Apple's subscriptions are the exception rather than the rule, but they like to promote it in such a way as you'd think all Subscriptions/IAPs are shared when they're not.
According to their Terms, there are no legitimate sharing use cases. "You agree that you won’t disclose your Account password to anyone". That said, Calm has a family plan (6 users) for only $30/year more.
Anecdotally, in the instance you described they net the same $60/yr regardless of wether you use your wife's login, so they're getting more stringent access controls (though you could always use the device in question, too) in line with their terms of service.
(Would also note that my response does not cover your latter points on helping users manage their accounts with their presence, but without their device presence, which I agree is a valid concern)
To meet bare minimum requirements sites like Calm.com often only show the "Sign In with Apple" button for iOS and iPadOS user agents. You can sometimes fake an iOS/iPadOS user agent and get the buttons to show up and then switch the User Agent back to get the boring in-browser OIDC flow.
As an iOS/iPadOS but Windows PC user I find it frustrating how many websites intentionally hide that button in other browsers, just when dealing with my own accounts.
I feel like Apple could maybe do a better job of education here: "please don't hide the button on non-iOS/iPadOS user agents". I hope Apple has strong developer education plans for Passkey.
The competition, password managers like 1password and bitwarden, do not have any sort of vendor lockin. You can freely export your passwords from one manager and into another.
We really should be working to allow better, standardized integration with password managers (communicating password length and alphabet requirements, well-known URIs to do zero-touch credential rotation, etc.) rather than trying to do "Log in with BIGCORP" in another way.
I believe some password managers also look at the regex attribute to understand required or disallowed characters.
For resetting passwords there‘s at least a way to deep link to the right page: https://web.dev/change-password-url/
But the lock-in point seems like a founded critique. Does anyone disagree with this claim?
Anyone implementing FIDO should allow you to enrol multiple devices. As long as the auth consumers allow multiple keys, there's no lock-in. You just need to setup your new device before ditching apple.
Also, I imagine that many people do not have the luxury of multiple devices. So if you lose your phone, you'll need to buy or at least borrow another iOS device to recover it from iCloud before you could switch to Android.
How are these handled in Chrome/FF/Windows/etc.
Services that properly support MFA should simply support accounts having multiple bound authenticator devices, each with their own private key/seed. In such setups, the proper way to rotate out an authenticator device is to add a new device first, and then remove the old device; and the proper way to protect against a lost device, is to keep an extra bound device in safe cold storage somewhere (e.g. a safe deposit box.)
Basically, look at how the crypto people handle the "hardware wallets" (really, smart cards) they use for multisig transactions. 2-of-3 confirmations, two hot smart cards held independently by company officers, one cold smart card held by e.g. the company's law firm.
Your "proper way" is absurd and nonsensical for the vast majority of users. The first time they get burned by this is the last time they'd rely on anything but the one memorized password they reuse everywhere.
The point of setting up MFA is to secure things that really need to be secure, where the person with the data is aware of real attacker threat-profiles that have real interest in their data. It's a thing that companies that hire CISOs care about.
Any implementation of MFA you see in the wild is either part of a product that has an enterprise tier that has customers like that, where the product devs decided to "trickle down" the feature [in a less-secure, but possibly optionally secure, form] to lower plan tiers; or it's a cargo-cult reimplementation where a company "saw other companies doing it and it seemed like a good idea" — but they exchanged actual security for convenience.
(You can usually distinguish one from the other, because the companies "actually doing MFA" will almost always support smart-card authenticators — and have for decades, back since doing so required a Java applet. Because "issuing each employee a smart card" is what companies that actually care about cybersecurity — e.g. defense contractors, investment banks, etc. — do as a matter of course.)
The goal of all this is to make auth tokens be single-factor, not one factor in MFA. If you read the Ars article linked elsewhere in the thread the people behind it are pretty clear about their desire to get rid of passwords.
And, once again, companies doing MFA properly, enforce MDM policies on such devices, such that they either don't allow you to use the convenience biometric unlock features, or they limit them to ~1 minute before you must unlock with a something-you-know factor again.
(I worked for IBM for a year-or-so a while back; they required this even for phones not serving as MFA authenticators, because they had a threat model that included attackers cloning your fingerprint just to snoop company secrets out of the emails on your phone.)
In a world where people used password managers correctly and all the time, this might be redundant, but we don’t live in that world.
Isn't this already mostly covered by browsers (like Safari!) doing strong non-memorable password autogeneration + password sync, such that the password in the password field is already essentially acting like a token for these people?
Yes I've heard that there may be some Apple manifestation going on or something but to have every little Apple tidbit hoisted directly to the front page (at least 7 articles and counting) is a bit much imho.
Downvote me if you must, but I think it is important to have my opinion heard, and I don't think I am the only one.
Companies release new products all the time, I'm not sure that HN is the proper place to discuss them unless they are truly innovative or newsworthy.