This is based on the open standards WebAuthn and FIDO2, where the credentials (“passkeys”) are synced via iCloud Keychain. Currently you need remember to register at least 2 security keys, in case one is lost/misplaced. The syncing of passkeys in iCloud solves this backup problem.
>Currently you need remember to register at least 2 security keys, in case one is lost/misplaced.
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.
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.
> Tying 2FA to hardware is for most of the common use cases a bad idea.
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.
> I'm happy enough to deal with losing my digital access (via 2FA) temporarily under the same sort of circumstances where I've lost my keys.
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.
Absolutely this. I can lose my wallet - I know how much that's realistically going to cost me and I'm protected against fraud and theft regardless, save for the headache of making a few phone calls.
The world really hasn't appropriately quantified our reliance on little black fondleslabs.
To echo the sibling commenter, perhaps this rule applies:
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".
But the entire issue is that needing to enroll all your keys every time you gain access to a new service is directly at odds with keeping one copy/key in a second, safe location.
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.
That's an issue of the implementation, not of the concept of hardware 2fA. With SSH keys, you don't need them around to enroll them, as they use public key cryptography. I can point someone else to github.com/est31.keys and they can give me ssh access. The actual ssh keys can reside on hardware.
For some reason, this use case was not considered for Webauthn.
Question for you about this as I've often considered it.
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?
> What is the life of a yubikey? Do they degrade over time horizons?
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.
It's solid state electronics, if not subject to any external factor (which should not be common to both) it will just keep working on any timescale that matters here.
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.
> What is the life of a yubikey? Do they degrade over time horizons?
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.
Any OTP can be phished. There is no automatic authentication that the OTP is being given to the correct party.
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.
While you're technically correct any authentication system worth it's salt would ideally see the same user trying to authenticate from two different locations, and prompt the second user for another factor of authentication (Email, etc.) And since TOTP expires it's not like they could sit on the token and use it later.
TOTP is prone to phishing. Not to mention that you still need a password so it's both insecure and hard to use. You could ague that "When used correctly, password are a fairly great solution " but as passwords are flawed they are exploited and even the "experts" happen to fall victims to "improper" use of passwords.
Only if by "never reuse" you mean "never ever log in after the initial login". The problem that WebAuthn/FIDO solves is that even if you read my encrypted communication, you won't be able to use it to gain access to my identity.
A software implementation of WebAuthn requires a TPM module and to be honest I think privacy and user identification are more of a security problem on the web than being phished for passwords. The problem I see with Fido2 is that they consider a far too narrow corridor of threats.
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.
If you've managed to insert your malicious code in a place where you can bypass TLS, secrecy of the password isn't my main concern anymore, as all is lost. It's not a threat model I worry about in most circumstances (sure there's always exceptions).
Fair, but I am a nobody that is unlikely to be specifically targeted. I am willing to swing the balance towards convenience/backup safety vs utmost security.
A common misconception. After credential stuffing (which 2nf factor protects you from), your biggest threat (for people with 2nd factor) is phishing and keystoke logger, which does not require any targeted attack.
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.
But then I'm not aware of a FIDO key that works with random apps on an iPhone. That's where I, personally, have by far the most logins and spend money. Pretty much all of them support some sort of authenticator app nowadays though.
Apple’s implementation uses SMS as a backup. Thinking is probably that if you only have one device, it’s usually your phone; so you would have been able get your 2FA code via text. It’s not easily discoverable though, so easy for you to miss it.
You can use SMS as a backup 2FA to login to your online Apple ID account, but that's not enough to access the iCloud keychain.
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.
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.
So if I have a single device, a phone, and it gets stolen... what is the path to get my data back? And in the interum, if the theif swaps my SIM into another phone they now have my 2FA via SMS?
They solved this with a feature called “Recovery Contacts” in iOS 15(?). You can set them up and they’re people who cannot access your account but can help you regain access if necessary (such as your one device case).
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.
I think the answer to the "stolen SIM" from Apple may just be "use e-SIM".
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.
A password can very well be as secure as the ownership of a device. Compared to most 2FA schemes I love them because they are simple. I think if people are trained adequately it isn't an insurmountable barrier. But the industry never did develop good practices and bad ones are still around.
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.
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
Password managers like Bitwarden can do TOTP with syncing. Doesn’t help with Apple though which uses non-standard 2FA. I actually have some accounts using SMS still, because I can fairly easily get a replacement sim if the device is lost.
You don’t need to have your second device to get past 2FA in a disaster scenario. You can phone up Apple Support and as long as you know the code you use to unlock your old phone (which is a reasonable ask), you can regain access to your iCloud account, and hence to your iCloud Keychain/devices.
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”.
> 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.
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. "
Oh wow. I thought those keys were the foundation for real end-to-end encryption, i.e. Apple doesn't have access to them. Does this mean their "E2EE" is basically fake?
> Oh wow. I thought those keys were the foundation for real end-to-end encryption, i.e. Apple doesn't have access to them. Does this mean their "E2EE" is basically fake?
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.
> 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.
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.
Your options are here btw. Another apple device, text to phone number or account recovery which is automated but takes a few days:
https://support.apple.com/en-us/HT204915
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.
It's strange and rather unfortunate to see this constant reinvention of authentication methods. Asymmetric encryption as used in things like SSH keys and TLS client authentication have been around for decades, are very much standard, and the only changes to those have been stronger algorithms and longer keys. Smartcards as hardware secure elements have also been around for a long time. I'm not sure how much of a conspiracy theory it is to say that things like this are merely attempts by Big Tech to stronghandle everyone into their own idea of "standards" and run away from all the smaller players in the industry, but I'm sure that we had everything necessary for "passwordless authentication" two decades ago, or at least methods in which it's not necessary to send a password to the authenticating server nor store them there.
Its absolutely not a conspiracy theory, but it is a bit more complex than that there is was a coordinated push - there was a big push a while back from the likes of Microsoft to e.g. eradicate ssh credentials - in favor of stuff like AD (ugh, why?), specifically wrt to git clients. I know, GitHub still takes ssh (they'd break too many people otherwise), but places started moving towards AD, or "password manager integration" clients.
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.
Perhaps not reinvention but rather repackaging. Web Authentication (on which this is based) is (just) asymmetric encryption in an authentication challenge/response protocol.
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.
Well, there's encryption algorithms, and then there's authentication methods... Don't confuse the two. There's actually been a lot of interesting developments in authentication methods... not the least of which have been the FIDO 2.0/WebAuthn standards. While you might perceive them as plays by Big Tech, smaller companies like Yubikey are kind of at the core of it, and without WebAuthn in particular, it was rather hard to have confidence in browser based authentication. Yes, there were certificates, but the general public has struggled to understand and adopt device certificates in a way that doesn't lead to them being stolen.
There was already a passwordless authentication mechanism in browsers called SSL client certificates. Approximately nothing uses it because it’s hard to use.
iMessage backups are encrypted, they are just not encrypted as much as some people would like.
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.
iCloud Keychain is end-to-end encrypted, Messages isn't because Apple took the tradeoff of allowing people to keep their imessage history even upon a support-initiated account reset, which otherwise will wipe your entire iCloud Keychain.
Messages is end-to-end encrypted. The key is stored in iCloud backups if they’re enabled (and if I recall correctly the messages on your device are backed up as part of an iCloud backup as well), but you can turn those backups off.
> [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.
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
The password stored in your backup via iCloud Keychain use the passcode of your devices as a secondary encryption/lock method, which doesn’t have a password recovery mechanism like the Apple ID used to secure your iCloud backup. Not sure that meets the definition of E2EE but it’s not like the passwords are recoverable by another party (or even you, if you forget the passcode) just because they’re in your iCloud backup.
So maybe I don't get it, but I always understood that 2FA means something you know and something physical you have. Now if I can get they keychain using something I know, does that not somewhat defeat the purpose of 2FA?
In general it's "who you are" (biometrics) as well as "what you have", with the OS being the one ensuring that the phone itself was unlocked and having an extra biometric check when signing in with passkeys; this is how iOS currently works, it pops up face ID before it signs any Webauthn challenges.
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).
Typically MFA is something you have (physical possession), along with something you know (secret) or something you are (biometric).
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.
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.
…
Are such third parties listed? Can you inspect their reports? What testing methodologies are involved in order to issue such certifications? And can we see such certifications at all?
If you don't trust Apple, why would you trust a third party auditor?
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.
Because you’re trusting both apple and the third party jointly, each of whom have different incentives.
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.
You also have to consider the market value of their reputations jointly as well. It would have to be a huge incentive to risk their reputation, both apples with their security conscious customers and customers with high regulatory burden, and the auditor whose only asset of value is their reputation. Auditors typically poof out of existence (Anderson anyone?)
Trust requires transparency and a published security audit report created by a reputable independent author would definitely increase my trust in Apple because they show that they don't have anything to hide.
Yup. Probably because law enforcement would be livid if Apple did that. In the San Bernardino terrorist case, Apple basically said triggering an iCloud backup is the best way to get the contents of a locked iPhone. Apple routinely supplies law enforcement with contents of iCloud backup.
It remains one of the clearest examples of law enforcement wanting a friction-free solution for getting data out of iOS without Apple. They could have easily attained the information and have been doing so for years. They were explicitly trying to generate sympathy towards a backdoor solution.
What's sort of surprising to me is how much they overestimated public support for their cause.
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.
E2EE would have made it significantly harder for Apple to build the web based apps at iCloud.com. Not to say that shouldn’t have though, but I can understand whey they didn’t.
I think the main thing is Find My access, but Apple seems to claim it's E2EE despite being available at icloud.com/find so perhaps it wasn't too complicated; I imagine it stores the plaintext password in memory to access the data.
Same as the don't have access to your iMessage messages ... unless you happen to use iCloud which they purposefully make really inconvenient to not use.
Yes Apple is willingly staying quiet about your iMessage backup being accessible by them. But it does not change the fact that iCloud Keychain is end-to-end encrypted with Apple incapable of accessing your keychain.
When I first learned about the iMessage backups being accessible I was a bit let letdown by Apple. But I never believed they were best in class for privacy. The iPhone's true strengths lie in the OS support and FaceID.
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.
I would expect passkeys to be a massive liability for Apple in case they get breached. Why would they even want access to them? Do you think they want access to your accounts?
I think they want to provide the "I forgot my password and lost all my devices" convenience. People hate loosing their data and loosing access to a lot of passwordless services would be a nightmare. In general I'm super weary of anybody who promises to have no access to my account and then offers any reset password functionality.
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.
They do, and an earlier version of my post mentioned that but I edited it down.
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.
Oh dang, thanks for writing tpm-fido! It works really well for my use case -- avoiding mandatory and incredibly annoying Duo Mobile 2fa on my school's website -- although I tore the presence verification out of the code for my purposes :)
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?
Isn't this approach significantly less secure than Apple's though? As far as I understand the secure enclave coprocessor in Apple devices stores key material and implements user verification (TouchID etc.), right? Instead software like tpm-fido bridges (in software) a user verification mechanism (maybe even a fingerprint reader) and the system's TPM. But such a system can be interposed with mere root access, and the TPM tricked in giving out its secrets, no? Please correct me if I'm getting it wrong, but Apple's approach is instead resistant even to full kernel compromise, precisely because the communication between TouchID/FaceID and the secure enclave cannot be interposed.
I'm a tpm-fido user myself by the way, thank you psanford!
Yes, having the verification done by the secure enclave itself is more secure. The TPM spec does allow for direct integration with biometric devices, but I'm not aware of any general purpose computers that ship in this configuration.
> 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.
> To be clear, the key can never leave the TPM (with how tpm-fido is implemented).
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.
A compromised main UI device could also show the wrong account recipient, even if hardware key is used. The text could be changed on the screen when the user meant to send a small payment to someone else. Yubikey will be pressed like usual. Apple's standard prompt on the phone may not have the recipient shown.
I agree that the secure enclave with integrated touch id is more secure. However, if your threat model is an attacker has root on your system, the secure enclave isn't going to protect you from much.
>As the authenticator, your Apple device generates a unique public-private key pair for every account it creates on a service. The authenticator retains the private key and shares its public key with the server, known as the relying party.
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.
This was around for a long time in the form of SSL client certs, but that never took off for all sorts of reasons. Presumably Apple nailed the UX problems but the general issue of how to back up your keys, get back access if you lose them, the confusion created by not having passwords etc were real isses.
Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore.
Yes, this! Without a export/backup function for these data, you could easily lose access to nearly everything and the lock-in effect would also be something currently unseen.
There's nothing to backup/import. If you have an iPhone, you use your fingerprint or Face ID. If you sell your iPhone and buy an Android, you use your fingerprint or face recognition on that device.
That doesn’t sound correct. It’s not the finger print which identifies you to the website, it’s the public private keypair.
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.
I haven't dug into the docs yet, but I don't quite follow this. How does it know that the ex-iPhone owner and current Android owner are the same person (and should have access to the same account)?
If you did switch ecosystems, you'd probably need to do the whole re-enroll dance on every website that had your previous key. I don't see any sort of passkey backup/import functionality coming anytime soon simply because people don't change ecosystems that often, and those that do can simply keep both their iCloud and Android-based passkeys on services.
Passkey works on non-Apple devices by showing a QR code on that device, having the iPhone scan it, then a BLE connection being established to allow the phone to remotely sign webauthn requests. I only mention ‘switching ecosystems’ in the sense of moving between Apple and Android mobile devices.
I know it does not. It's in the Cloud. I was referring to SIM and phone number when I was thinking potential way to recover.
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?
>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 register VoIP and landline numbers as well, and nothing says the number must be yours; you can also add the number of a trusted family member or friend.
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 works with password access as 2FA it's part of plan A in recovery.
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.
Does anyone know if this is different to Webauthn? You can already login with touchid/faceid, with the private key stored in apples keychain. Lots of sites support it, I just added it as 2FA to Mailpace (https://blog.mailpace.com/blog/why-we-use-webauthn-for-2fa/), making it passwordless login instead of 2FA is trivial and fully supported by webauthn.
Passkeys are available for general use in any application through the system frameworks, not just the browser; they simply use WebAuthn under the hood, but it's meant to expand support outside of the browser for more apps in more use cases.
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.
> 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.
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.
Yes, obviously, but I was mostly referring to being able to share outside iCloud keychain, and in general 3rd party software support for this -- but, I wasn't aware of the BLE option, which is very interesting! I'm already very invested in 1Password (which I would like to integrate somehow, ideally) but that's good to know
As far as I can see this is Apple's (thus macOS / iOS) platform for FIDO, whereas WebAuthn does FIDO for the Web.
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)
> 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.
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.
Reading the linked page, it certainly looks very similar. I've also implemented WebAuthn from scratch and the term "relying party" is burned into my brain, and this document also uses that term. It's a reasonable term to use in any authentication context, though, so not a smoking gun I guess.
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.)
Relying Party is the jargon for the entity that gets to rely on the fancy cryptographic technology to determine something that would otherwise be difficult / expensive / unreliable. They're relying on the maths working, and on certain other parties doing their jobs correctly.
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.
WebAuthn is a Web-facing Javascript API for accessing passkeys, which it calls Public Key Credentials.
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.
>> Apple has described Passkey as a new kind of credential in the iCloud keychain. The technology is based on the Web Authentication API (WebAuthn), a rapidly emerging standard that uses public key cryptography instead of passwords for authenticating users to websites and applications.
Whatever "based on webauthn" means...Let's hope it's not just a buggy implementation of WebAuthn as they did with OpenID Connect
Same as what they did with Bluetooth and AirTags, AirPods, etc.
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 think you are confusing this with U2F support using the secure element, which has been added much earlier (I have also been using it for years already). The difference between that and Passkey is that Passkey syncs private keys between Apple devices through iCloud Keychain. The older U2F support is per-device.
It is, but annoyingly you need to enable it via Xcode, so if you only own idevices you can't turn it on. (Unless you mean just normally adding an iPhone as a security key & using Face ID to authenticate it, which is just how Apple implemented FIDO2 and isn't synced like Passkeys)
I think it's supposed to work on websites that support Webauthn/FIDO2. For example, I have been using experimental Passkey support in Safari as a second factor for GitHub.
This is wonderful news! If anyone is interested in experimenting we built an API that makes it very simple to add WebAuthn (passkeys) to your existing web app.
You might at least want to put a warning there for people who access the page with unsupported browsers? There's nothing on the left of "⬅ Go ahead... click it." for me.
This is really cool! And well-timed - I have a project coming up this would be perfect for. The only thing I wonder is, if a user didn’t have biometrics on their device, how would they authenticate? Would I have to maintain a backup system for these users?
In general they just need _something_. If Windows Hello has even a pin number, Chrome and FF webauthn prompts will use Windows Hello as a TPM provider (assuming the website is using actual Webauthn and not the older U2F-compatible standard, which some sites still use for compatibility, eg google). If they don't have anything, then they will definitely need at least a usb hardware key.
How does this bode for anonymity and multiple identities?
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.
> I'm imagining a world where all PCs/Macs/Smartphones have FIDO/WebAuthn and there's no other way to log in.
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.
FIDO logins are not shared across relying parties (sites), each site gets its own (that's what makes FIDO phishing proof). If you want a single identity that multiple sites know about you'd, login using a third party identity provider where you'd use your passkey.
FIDO2 resident keys do support multiple identities for a single relying party (site).
I don't get what it's all about this passwordless. I make my browser (Firefox) generate strong password and store them in its password manager, this is synchronized with end to end encryption to all my devices, I have only to remember a master password. It's kind of the same but it works with every website. It is not complicated, doesn't require certificates that you may loose, and that sort of things.
Try explaining a password manager to your nana, and having her use it. Then explain to her how she can install it on her phone and have it synchronised across all her devices. Password managers are awesome, but way too technical to become mainstream. You shouldn't have to install 3rd party software for something so fundamental. The password system really needs an overhaul and hopefully this will go along way towards fixing it.
Apple already has a password manager as part of iOS/MacOS. Your passwords sync seamlessly on other Apple devices via iCloud. There is nothing to install. My octogenarian mother uses it daily on her iPad and iMac.
Password managers are already pretty easy to use from a nana's perspective.
The main problem is that nana does not know that password managers exit itself. Most of them just input password as 'nana1234' and store it in their browser password manager (usually chrome password manager) and use chrome's autofill.
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?
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.”
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
Sometimes I wonder how bright nana or papa really is as a result.
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 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.
Expecting people to give the minimum of a damn is embarrassing to point out? It's true either way. Sometimes a certain level of complexity can't be abstracted over. This is no longer a fun toy in life. You may have your bank account credentials stolen if you don't wake up and pay attention to what you're looking at.
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.
I expect people to do their best, within their capabilities.
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.
My view is best stated that I think people are more capable than they think they are. And I'm unsure people even attempt a try at most things. Maybe that's a negative view but I feel that's what I've observed.
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.
My issue is that I've seen people attempt to do these things. And fail miserably.
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.
The point is to make it harder to export your credentials to another platform. An iOS refugee with a keychain full of passkeys will have to do a password reset for every account, instead of a relatively simple export/import into a third-party password manager.
It’s not the same because you have to actually tell the websites your password, while with this, like with certificates, you only have to prove that you have access to the private key. So, if the server is hacked they don’t get a dump of encrypted passwords and if the hack persists they can’t sniff your password. Because the server never gets your password.
Not entirely. If I MITM your connection to a website that uses a password, I have access until the breach is detected. If I MITM a public/private key log in, I only have access to the session (which can be made arbitrarily short if logging in is painless/automatic).
No, because if the server gets hacked and the attacker can intercept your password, your password manager is managing a password that is, unbeknownst to it, known to an attacker. Who can now use that password to just login to the service.
Flip side of the coin: this system now manages what domain you can log to, and when it gets it wrong you're probably toast or go through a backup option (is there any if yhey maximize for security ?)
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)
I think we need a browser level or OS level notification about which passwordless service we used last time.
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?
Such a great point. I forget all the time. Next auth service I write will remember this for you and prompt you based on the service you used last time. Take my upvote!
One trick to this is to put an entry in your password manager for the site that's just a note that says "log in w/ X". So you always check the PM first- it'll either have credentials or a pointer to how to log in.
Why do you use more than one password manager? I have disabled all password managers in every app that I use except for the one I store things in. I have multiple folders with their own passwords too but they're all stored via the same solution.
Because Google Chrome on iOS pops up asking to remember a password
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
Unfortunately, and I hate to "victim blame" (though you say you are not yet a victim), I think you have to take some responsibility and use a password manager with deliberation. IMHO the browsers all make this worse by giving you something that seems to work and your first notice that it doesn't anymore is when it stops, which is a terrible way for a security feature to work, but obviously they have incentives to lock you in, and boy oh boy is this one of the biggest ways that a browser can lock you in.
I think you should resist sooner rather than later and switch to something cross-browser and third-party.
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.
Most password managers allow you to separate work from home, though. You don't need to store them in different platforms to have them in different places.
The browser and the OS credentials managers essentially obsolete the third party password manger so that part is sort of 'solved'. Integration between the browser and OS one (with sync) is quite a bit trickier but the real blocker is that Apple and Google aren't much interested in solving it. The terawatts of brain power that went into the anonymized COVID tracker phone thing which turned out to be largely pointless could be applied to this, it just doesn't feel very likely.
Does anyone know how this/FIDO/Webauthn affect privacy? How well supported are alt accounts? Are they easy to tell they're from the same signer?
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?
FIDO2/WebAuthn don't have anything to do with user management from an application architecture perspective. They leave all the work of combining the attestation credentials and your application's concept of a "user" to the application.
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.
FIDO2 resident keys (the thing people are now calling passkeys) allow for multiple credentials for a single site. If you have a device that supports resident keys you can try this for yourself on https://webauthn.io.
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/
FIDO/WebauthN are generally "the good guys" when it comes to privacy bc "bring your own secure hardware key" is always an option. I'm kinda torn over the "use your cellphone as a key" approaches as not privacy friendly but we can't actually prevent them (you can always simulate a key).
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.
Maybe only tangentially related, but does anyone user Apple Keychain as their primary password manager? Is that even a viable option if you're completely within the Apple ecosystem?
I mainly use Bitwarden for my passwords, but for things I usually open in Safari (for example food ordering sites which accept Apple Pay) I also save the password in Keychain so it's easier / faster to log in (in case Bitwarden is locked and I would have to unlock it (Face ID) with the app instead of the extension).
Yes I started using Keychain exclusively after the LastPass app got progressively shittier. No issues so far, and really no differences. Even tells you when something gets compromised.
Any tips on transferring data from e.g. LastPass to Keychain? Also, are you now tied in to Safari on all devices or is it interoperable with other browsers at all?
I'm not sure if there is an actual transfer available. I just gradually accreted passwords into Keychain by having LastPass on normally, and then accepting the prompt when Safari asked me to save the password.
iCloud passwords works with Chrome and Edge on Windows but generally yeah you need to be all-in on Safari :V
I didn't know that was available (I don't think it was last time I checked). Thanks, worked quite well with the exception of a bunch of conflicts it wouldn't import.
I used it for a few years, then switched to a paid password manager. Keychain just doesn't (didn't?) have features that I need: cross-device functionality, family sharing, groups for different credentials (work/private), browser integration, etc etc. Also, its UI sucks.
It's definitely a viable option, and probably the simplest/easiest password manager to use if you're only using Apple devices (of course, that is by design).
How do I leave the Apple ecosystem if I go all in on this? Sounds like major vendor lock in under a deceptive title of “open standards” but I’m hoping I’m wrong here. Does anybody happen to know yet?
Just add more authenticators to every RP (site you auth into). From the point of view of an RP, "your account in the Apple ecosystem" here is the exact same thing as "one of your Yubikeys", basically.
That seems like an enormous pain if you have dozens or hundreds of services. It could take hours to do this one at a time. (I'm assuming one minute per service, though that depends on how hard it is to find the "add another authenticator" page for each service.)
It's possible I'm unaware that there is a simple protocol for this. Am I incorrect here?
You should always add at least two keys for every service in case you lose the first anyway. That was the case even before Apple passkey so just keep doing the same.
This isn't a great solution, as in order to enrol in new services you have to either retrieve your backup key from its safe storage location, or keep the backup key with you at all times (which defeats its purpose).
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.
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)?
You are 100% correct that you need to add it to each service. This is a consequence of an intentional decision (keys cannot be duplicated). Streamlining it would definitely be an improvement.
That being said, it's not a problem in the real-world because FIDO is so sparsely supported. Hopefully PassKey speeds things along.
The relevant WebAuthn standard actually supports keys regardless of whether they can be duplicated. Even "virtual", software-only keys are supported. It's up to each individual service whether they allow the user to enroll such keys.
I should have been more specific. Test how many clicks it takes to add a key to one of your "mainstream" accounts. We would hope that services which support FIDO eventually gravitate to a single UX language, that also reduces the time taken to register new keys.
The goal of the recent initiatives is to create widespread passwordless authentication, so it seems likely that the number of services that support WebAuthn will grow dramatically over the next few years.
I also have hundreds of accounts. But there are ~10 services that are far more important to me and where I care a lot about security beyond passwords (Fastmail, Dropbox, GitHub, Google Apps, Bank, government websites, etc.). I use most of them already with an U2F key and I’ll use them with Passkey.
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.
Yeah, that's going to be the next big ecosystem challenge for WebAuthn in my opinion. Ideally platforms would support 3rd party password managers, so you could manage your keys without having to tie your credential database to any one specific platform.
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.
For normal passwords they currently seem to support third party password managers just fine, including direct integration in Safari and the iOS keyboard.
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.
That would be nice. I used Hanko for one service I built that uses WebAuthn+email, so new devices get a one-time code in their email and existing just use WebAuthn. It would be kind of nice not to have to rely on email, but it's better than making people remember passwords.
I always was curious about this stuff. I don't want all my eggs in a basket and have to depend completely on others for "logging in". Apple and Google and other Big Corps(tm) have shown they are just fine with terminating your accounts without any recourse and/or warning with no practical way to appeal it. Passwords managers aren't subject to that limitation and all faang companies can do is kill your accounts for their particular services.
Hopefully this will be compatible with WebAuthN in practice and encourage web sites to implement it (in a compatible manner). It often does take Apple's heft to force a change across the web.
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)
I can be onboard with this if Apple opens up an iCloud API for syncing, so I can sync a non-Apple device through iCloud, and if I leave Apple and iCloud behind, my non-Apple devices keep working, even if I never sync through iCloud again.
I'm going to sound like an Apple apologize, but what's wrong with Apple Music on the web? I just launched it (for the second time in a while), and after signing in, was presented with a familiar looking UI and all my playlists, and was playing searched-for music in under a minute. I know Apple prioritizes their platforms first, but this doesn't seem like an example of Apple failing a competing platform.
Apple Music on Android is actually really good, I use it daily. On some level it was a priority for them for market share, to compete with Spotify. I don't see the "competitor" in this space (cloud) though that would drive that necessity.
I think Apple encrypts the pass keys locally on your device, then stores encrypted copies in iCloud, which you can download and decrypt on a new device.
On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.
This is false; some data is end-to-end encrypted, including Health and Keychain data. Photos, contacts, and Drive are "encrypted on server" which means Apple can read them.
> 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.
Data in iCloud is going to be encrypted by the host provider in-transit and at rest. That is not the same as being encrypted at the source by Apple. It means that Google, Amazon, Azure (and whatever other platforms Apple uses for iCloud storage) will be doing that encryption with keys that they have for Apple. All the major vendors have storage encryption both in-transit and at rest. I suspect that it would be a requirement from Apple for any future vendor, too.
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.
Photos need to be encrypted on server so they can be scanned for CSAM. Apple tried to move that bit to the phone so they could encrypt photos on server too, but we all know how that went.
> 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.
Same thing that happens if your FIDO/U2F key breaks. If you have a backup key (or in the case of this implementation, icloud backup), then it shouldn't matter. Otherwise you're at the mercy of the site that's requesting the credentials. They might allow you to authenticate via another method (security questions?), or lock you out permanently.
Ideally, if you can’t identity proof in person, recovery flow should be Stripe Identity or another proofing system that will consume government ID and output pass or fail. It’s the next best thing to showing up in person and having a human proof you, and saying “oops keys all gone” isn’t going to fly for the masses at scale.
It's tied to a key stored in your iCloud. So basically as long as you have a device tied to your iCloud you can get in. Presumably, if you lose access to iCloud you will have problems.
My understanding is the QR code is used to establish a quick BLE connection. The phone then pretends to to be a simple FIDO2 key. After that things proceed like any other FIDO2 workflow.
interesting, but it still needs an iPhone> -- I was kind of burned hard when trying to migrate my iCloud keychain passwords to something else so I'm curious how smooth it actually is
Semantics aside, holding private keys hostage with no recourse is Orwellian. A for-profit company has no business being a centralized identity authority.
They said in the event that everything is synced on iCloud so all your devices can use the keys, which makes me think no, it's just a password manager, without the password bit. Maybe they create a separate key for each device, but then why mention iCloud syncing at all.
It's a password manager with cryptographic vendor lockin.
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.
There is no password so it can't be a password manager. Without a password it avoids all the downsides of passwords like having to store them securely on both ends, rainbow tables, credential reuse, weak password choice, and having to remember them. It's a cryptographic keypair manager. Key management is always the barrier to really good real world cryptography, so I'm heartily in favour. Anything that makes it possible for regular people to use strong cryptography is a huge win.
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.
The industry doesn’t seem to have a working software solution for mobile phone authentication secrets that both is 1) immune to persuading a user to export their data (to get phished), and 2) allows a user to export their data at any time (to prevent lock-in).
What would it look like to do #2 safely, without enabling the phishing that we see today with #1?
I get where you're coming from and you're not wrong, but at the same time, I don't buy this as an excuse for vendor lock-in here, because it seems like Apple is already backing up passkeys to iCloud.
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.
I don't consider this solution an excuse for vendor lock-in. I consider this a problem that has no known solutions without vendor lock-in.
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"?
I think you're misunderstanding what I'm saying. Apple IS allowing users a way to export right now, we just don't know whether non-iOS devices will be supported.
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.
Your choice is to allow people to be phished for credentials, then.
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.
Apple is already remotely backing up passkeys off-device.
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.
As far as I know, Apple requires iCloud password and PIN entry on an Apple hardware device being paired to iCloud to access Keychain data, and tends to block Apple devices by hardware ID when they’re associated with bulk login attacks. The attacker surface for phishers is exorbitantly expensive, since they’d need to have a shipping container full of iPhones to even begin harvesting credentials, assuming that they could convince users to turn over their iCloud password (which half of my friends don’t even know).
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.
> As far as I know, Apple requires iCloud password and PIN entry on an Apple hardware device being paired to iCloud to access Keychain data, and tends to block Apple devices by hardware ID when they’re associated with bulk login attacks. The attacker surface for phishers is exorbitantly expensive, since they’d need to have a shipping container full of iPhones to even begin harvesting credentials, assuming that they could convince users to turn over their iCloud password (which half of my friends don’t even know).
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.
It sounds like your private keys are stored in iCloud, so they should be accessible on a new device as long as you remember your Apple ID, password, the device-specific PIN/passcode from your old phone.
Ah, okay. I'm not interested in Apple's periodic product ads so I didn't really understand why this was linked again, especially since it's been available for a while now.
It is linked because it was covered in the keynote.
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).
For those in the know, will I be able to export my private keys and data from Passkey somehow, so that if I wanted to, I could switch to another FIDO device or system?
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.
> available to the masses in the form of a standard adopted by Apple, Google, and Microsoft that allows for cross-platform and cross-service passkeys.
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.
Apple Passkey is an implementation of WebAuthn. It's a feature which their devices support (and will soon be able to synchronize through iCloud), not a service -- there's nothing that needs to be "hosted".
What I want is to use the device password instead of biometrics. So the device itself and its TPM are the FIDO authenticator, the thing I have in 2FA terms, and the device password is the thing I know. Personally, I feel I can better protect a password than my fingerprint. But I still want the benefits of 2FA and public key crypto where the app/website doesn’t receive any sensitive information. I’d be okay with pressing a button to prove user presence. I’d avoid syncing the keypairs between devices, instead enrolling a new keypair for each device. I guess that last part could be annoying but it’s pretty much how I use SSH today and it’s not that bad.
I don’t understand how passkeys aren’t stored on external servers and can’t be phished, and yet they sync via iCloud Keychain (which is a nice thing to have). How does that work? Or do you have to trust Apple not to get hacked?
It is webauthn under the hood if you want to do further googling.
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.
I hope 1password gets annihilated by this move. I really liked what they built but over the past few years they have been very user hostile to ensure their extensions fail the Chrome binary signature. When you build a product that people start relying on it's very much of a dick move to go out of your way and make them not work anymore in hopes that they start dishing out a monthly subscription fee. Imagine if Gmail started charging money to read your email.
I have used 1p for several years now and it works great for e.g. me and my wife, but fails repeatedly for my parents who are just not savvy enough to deal with all the little sharp edges that a password manager can't handle (e.g. over stringent or under stringent password rules, the ability to save in all situations like password reset/update interstitials, etc).
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.
Excellent. I actually like Apple's practice in this regard: they have a barebones/baseline functionality but allow third parties to provide a value added replacement that can be a first class replacement.*
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.
While we're talking about authentication: Once the user is logged in, how practical is it for native apps on Apple platforms to use something more secure than bearer tokens to authenticate with the service on each request? I'm reminded of https://mjg59.dreamwidth.org/59704.html
Probably. Google and GitHub already support WebAuthn for 2FA so it's relatively trivial for them to ditch passwords altogether and use WebAuthn as the single credential.
If this is about "[hardware devices] for generating and authenticating accounts" like WebAuthn FIDO et al what happens when I upgrade my Macbook. Do I revert back to password in order to associate the new private key (or hardware generate password) with my existing account?
Could Passkeys ever be used for SSH? I purchased a Yubikey to use as an ed25519-sk key but found the implementation to be too drastic of a change to my workflow to be comfortable with. TouchID / FaceID for SSH would be a totally palatable solution however.
Interesting question. Though, if you don't specifically need syncing, there are already apps for storing SSH keys in the Secure Enclave, such as Secretive:
How do I deal with this when I move from an Apple to a non-Apple device (Android, Chromebook, Linux, Windows, whatever)?
With passwords it's straightforward. I just log in.
Yes, it uses WebAuthn under the hood. Passkeys have technically been available to developers for a while I think but very experimental still. I guess they've begun hitting new milestones.
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.
> This is basically the biggest problem with WebAuthn today: the credentials are tied to the browser
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.
Yeah, since Apple's (and Google's) soft WebAuthn implementation is designed for syncing across devices, it should also work with many browsers on the same machine.
1Password is also part of FIDO. I assume if you want to use 1Password on Apple devices to store passkeys that should work fine, just like it does for passwords today.
Phishing is an artifact of stealing and reusing passwords. Even if you need to enter a PIN, there is nothing reusable that you provide to the site you are logging into.
My wife signed up for calm.com using Sign in with Apple. Thanks to this, I am not able to occasionally use her login to listen to the wonderful music. There's just no way in hell I'm paying the $60 a year or whatever they're asking to listen to a couple songs every now and then. In a normal setting, she'd add her login to her 1password and I'd be able to use Calm.com, and who knows, I would've grown to love it, and gotten myself a second subscription.
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.
> How are they going to solve the totally legitimate sharing use cases?
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.
"Sign in with Apple" does have a very bare-bones OIDC flow in the browser on non-Apple devices/browsers. That flow takes you through a typical Apple Cloud login flow with Apple ID email and password and usual 2FA if it's the first time on that browser/device.
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.
For a business, implementing FIDO in this case seems like a win. They get more lockout of password sharing, and have to explicitly work to enable shared logins (if that's something they want). Of course it's nice for an end user to be able to share credentials, but I think long term outlook will be towards businesses and applications pushing to improve their user management tooling.
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)
You also ignored the point that perhaps they'd have gotten to like the service enough to get a subscription for themselves, but refusing out of spite now.
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!"
Most IAPs and non-Apple subscriptions don't work with Family Sharing, and the few that do there's no way to tell before you buy.
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.
Importantly, if you switch platforms you lose all your auth tokens and have to reauth everywhere. It ultimately is yet another way to do vendor lockin, except it has the FIDO alliance's blessing this time.
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.
Plus, password managers have fantastic backwards compatibility even on old, crufty sites that will never be updated.
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.
If you can extract tokens from a device, then they're basically passwords, not tokens — i.e. anyone who can hack your device can get them. Tokens only add multi-factor security insofar as they have distinct exfiltration requirements from passwords.
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 first paragraph, restated, is that passwords are superior to tokens.
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.
MFA itself is absurd and nonsensical for the vast majority of users. It's security theatre unless you do it right, and if you're doing it right, it's — as you've said — too hard for most people to bother. Properly implemented, MFA is an Enterprise feature, not a personal feature. Like SAML SSO, or having audit-log APIs.
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.
The security of these tokens is still MFA as an end-to-end security model, insofar as you need a something-you-know [password, passcode] to unlock the device that serves as your something-you-have. So someone who just steals the device, can't use it to authenticate as you. (See also: smart cards having PINs.)
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.)
As far as I understand, the story is: casual users don’t choose unique passwords. MFA, even in its weakest forms like SMS, defends against credential stuffing. Indiscriminate credential stuffing attacks based on database dumps, etc. are common enough that this is worthwhile. FIDO/WebAuthn add protection against phishing (because the token is bound to the domain name). Phishing is also a common indiscriminate attack against casual users.
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?
As a long-time Safari user who uses keychain heavily in lieu of 1Password or other managers, I probably will migrate to using Passkey because it sounds pretty seamless.
But the lock-in point seems like a founded critique. Does anyone disagree with this claim?
I'm not sure this is any more locked in then the parent post is locked into 1password. Moving auth tools is a pain.
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.
Looking at how various places do 2FA, it's likely that at least some websites will not support multiple keys even if they ought to.
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 common would it be for someone who has just lost their phone to want to immediately switch platforms? Isn't it much more likely that they'd want a new device on the same platform as the one they just lost?
If they were already planning to switch platforms, the loss or destruction of their old device provides a natural moment to make the switch, where buying a new device feels like it's locking yourself in for another couple of years.
I think they must know they need to have some sort of migration/export strategy. Maybe its just to early for that to be implemented yet. I mean I'm not even aware of any websites that support Passkeys as the sole auth method.
Sorry for the somewhat but not quite off topic post, but can we please prevent HN from becoming yet another Apple billboard? There are more than enough of those already. Thank you.
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.
This post is related to a large number of developers and startups (read: HN users), many of which have at least an iOS app or support safari. I don't see what the problem is.
My reply was not directed at this post in particular, but at the worryingly large number of Apple related posts making it to the front page lately. It makes me worry that HN is becoming biased towards favouring news about Apple's activities above other interesting subjects.
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.
That's just how Apple does their announcements: in big piles at few dates. The alternative would be to dribble them out slowly. As someone who is not particularly interested in Apple news either, I actually prefer this. Better get it out of the way in one fell swoop than have one announcement every other week that dominates the discussion all the time. Things being as they are, there are 3-4 Apple events per year, and so there are 48-49 weeks without big Apple news.
https://fidoalliance.org/apple-google-and-microsoft-commit-t...