Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple to Expand Support for Passwordless Sign-Ins Across Websites and Apps
- Thread starter MacRumors
- Start date
- Sort by reaction score
I expect tech to still be in its perpetual infancy by the time I shuffle off the mortal coil.
Good old laissez-faire capitalism. Selling us a service, and then disclaiming any and all guarantee and responsibility for the same service, in the terms and conditions they hope you don’t read (or are bullied into accepting because there’s no company not doing the same that you’ll run to for a better service).
Because they don’t want to spend money on making their services better for their clients.
But it won’t be the same data across different browsers, right? As it stands now, Firefox doesn’t seem to use my keychain in Mac OS.
As a developer who’s had to deal with authentication in the context of web apps before (which is a right pain, if you’re not using some CMS that gives it to you for free), I wonder what the process of actually implementing this is. I suspect it’s painful in some way, web authentication isn’t easy (since HTTP is stateless, you have to deal with authentication in each request, unlike making remote calls to a database).
I also wonder about the device interoperability of this. Can I use the same login token/key on iOS and Windows? If I change phones, how readily can I move this over? If something happens and I lose all of my devices logged into that account, is there any way of recovering my account? If there is, is it resistant to social engineering attacks? Is there some open standard that’ll run just about anywhere (including most versions of Linux)? Are you going to be limited to Safari, Chrome, Firefox if you want to take advantage of this as a user? How is the interchange between browsers going to work (ie, if you use Safari on an iPhone and Chrome on a desktop and maybe Firefox somewhere else entirely)? Are the keys strictly owned by the user, in some space specifically owned by the user? If so, what’s preventing malware from accessing the keys? But, if not, then what control does the user have over those keys? How readily can you extend it to multiauth (what the user knows, what the user has, what the user is, where the user is)? It seems like a weird combination of what the user has (the phone) and what the user is (FaceID and the like), but, as a developer, you’re left trusting the activity to the computer delivering up the key. You don’t know if it’s a malware affected Windows machine that’s stolen the login token to send out spam, you don’t know if any biometric data has been stolen, or even if biometrics are what secured the login token. It’s arguably less secure, since it’s only single factor authentication from the perspective of the implementing application.
In general, I’d suggest that any system that trusts users to maintain local device security is just as flawed as any system that expects users to remember passwords/codes/phrases, to avoid duplication, and so on. Users are lazy, and any system that depends on users not being lazy is an issue. (There’s also the dancing pigs problem. There’s any number of reasons why trusting users with security should be avoided when possible.)
I also wonder about the device interoperability of this. Can I use the same login token/key on iOS and Windows? If I change phones, how readily can I move this over? If something happens and I lose all of my devices logged into that account, is there any way of recovering my account? If there is, is it resistant to social engineering attacks? Is there some open standard that’ll run just about anywhere (including most versions of Linux)? Are you going to be limited to Safari, Chrome, Firefox if you want to take advantage of this as a user? How is the interchange between browsers going to work (ie, if you use Safari on an iPhone and Chrome on a desktop and maybe Firefox somewhere else entirely)? Are the keys strictly owned by the user, in some space specifically owned by the user? If so, what’s preventing malware from accessing the keys? But, if not, then what control does the user have over those keys? How readily can you extend it to multiauth (what the user knows, what the user has, what the user is, where the user is)? It seems like a weird combination of what the user has (the phone) and what the user is (FaceID and the like), but, as a developer, you’re left trusting the activity to the computer delivering up the key. You don’t know if it’s a malware affected Windows machine that’s stolen the login token to send out spam, you don’t know if any biometric data has been stolen, or even if biometrics are what secured the login token. It’s arguably less secure, since it’s only single factor authentication from the perspective of the implementing application.
In general, I’d suggest that any system that trusts users to maintain local device security is just as flawed as any system that expects users to remember passwords/codes/phrases, to avoid duplication, and so on. Users are lazy, and any system that depends on users not being lazy is an issue. (There’s also the dancing pigs problem. There’s any number of reasons why trusting users with security should be avoided when possible.)
Last edited:
Same problem you have with ANY MFA solution. What happens when your phone with Google Authenticator is lost/stolen?
the FIDO2/WebAuthn spec accounts for backup authenticators. I personally use YubiKeys for FIDO2/WebAuthn on any and all sites that support them. I have 3 Keys that I register. That way, if I lose one, I have two others to use as backups.
Since Passkeys are just WebAuthn, you can register your primary credential on your device. Then register a hardware key as a backup.
Finally. I've been happy how Apple has started to implement jailbreak tweaks over the years, but this one is long overdue. This feature was rolled out to the jailbreak community shortly after faceID was released, and has been one of the major reasons I still rock jailbreaks on certain devices. Keep these tweaks/upgrades coming Apple.
I’m not familiar with hardware keys. Are we talking about USB devices? Do they require third-party drivers? How does one use this on a mobile device that has no USB or third-party driver installation?
Yes, USB devices. No drivers required, that's the beauty of FIDO. Yubico makes security keys with USB A, USB C, Lightning, and NFC. FIDO will work across all those interfaces.
The Private Key is generated and stored on the security key, and it cannot be extracted. That's the security value proposition. When you login in, the website sends a signed challenge to the security key that is validated with the private key stored on the security key. If that challenge is properly validated, you can sign in.
Bottom line is, you cannot login with out the security key. If someone gets your username and password for a site, they'd still need the security key that is in your pocket to log in. The ultimate goal is to get rid of the username and password and use the "passwordless" authentication mode with FIDO security keys. Your unique identifier (user ID) is store on the key and the login is protected by that private key and a PIN that you enter during the login process.
Passkeys are a software implementation of FIDO. My biggest concern is that the private keys are sync'd across physical devices. They are potentially exposed of Apple or Microsoft are hacked. For my tastes, I prefer the FIDO credentials on a secure hardware key. But, Hey, it's nice to have choices.
Thank you so much!! This helps out tremendously.
There are also similar hardware keys that generate a TFA token and display the passcode in some way (such as a monochrome LCD display) in a completely offline manner. I’m pretty sure the USB keys, in terms of USB HID support, emulate a USB keyboard. (I know YubiKeys can feed the TFA passcode to a terminal or other application via keystrokes.)
Please remember, if you have to enter a displayed code in any way, that is NOT FIDO. That is an older, phishable MFA solution. These older solutions utilize symmetric cryptography with the same shared secret on the token and the backend validation service. Much higher chance that your MFA is compromised.
FIDO uses asymmetric cryptography with a private key on the token and a public key on the Relying party side. You need both the public key and the private key to complete an authentication event. This is MUCH more secure.
Fair enough, but FIDO also assumes a passwordless infrastructure. For instance, for a business to use it, it has to be single sign on for every tool. Developers who need to have access to some sort of privilege escalation tool on Linux servers (such as sudo), likely need separate credentials for those systems to enable the rest of the enterprise to be passwordless.
(And it’s always vulnerable to man-in-the-middle attacks on insufficiently secured networks, of course, or to Trojan attacks against the user’s endpoint. For remote users, that means network security and device security are still end user concerns, and the goal of non-phishable passwordless systems should be to remove the end user from security completely. Compromise either of the endpoints or the connection, and you can compromise the whole transaction.)
For FIDO systems, do you know the answer to the original user’s USB HID question? I have to admit that I’m curious myself as to what HID profile they use, if the YubiKeys you’re talking about aren’t the TFA passcode ones. I’d imagine that the user is mistaken in his or her assumption and that that mobile devices likely don’t need hardware keys to function as MFA devices for passwordless systems (or rather, the iPhone’s Secure Enclave [and the Qualcomm et al equivalents] functions as an equivalent to a hardware key), but I would be interested in learning how the passwordless YubiKeys communicate to the computer.
A whole bunch to unpack here...
Yes, there needs to be some infrastructure. Many SSO solutions (Duo, Okta, AzureAD, for example) already support the FIDO protocol. If an enterprise is already using one of those tools, they are good to go. With respect to privilege escalation, that is Authorization (what are you allowed to do). FIDO is focused around Authentication (are you who you claim to be). FIDO is relatively new, so some of the back end systems are still catching up with this technology. I know that OpenSSH now supports FIDO credentials for SSH'ing to systems.
Some history. FIDO was originally built for the consumer side. Authenticating to Gmail, Facebook, Twitter, etc. That worked great as each system supports FIDO and the end user registered their FIDO tokens with each service. That model poses some issues for Enterprises. They want a single source of identity. That's what SSO is for. Once you authenticate to the SSO solution, they you can be authorized to other systems. We are almost at the tipping point with the ability to properly implement a FIDO solution in the Enterprise. Most of the big SSO/Authentication/Identity solutions support it now.
Yubico's FIDO implementation uses the Generic HID interface. YubiKeys support multiple MFA "protocols" on the same key. OATH OTP, Smart Card, FIDO (and a Yubico specific OTP solution). Most folks don't understand the underlying technology of each protocol and do not understand the different security concerns.
FIDO can absolutely be implemented in software. In simple terms, that's what Passkeys are. (Prior to the Apple M1 Chips, I could register my computer with TouchID as a FIDO "Token". This was called a Platform Authenticator in the FIDO parlance. External Security Key are called roaming authenticators)
You need to be able to store a private key on something, whether that is a Security Key, a TPM, or a Secure Encalve, it does not matter. (I think of a Security Key as TPM on a USB stick). When a website or system wants to authenticate by FIDO, it sends a signed challenge down to the browser/system, which sends that challenge to a device to process. That device can be an external security key, or a FIDO solution on a phone/computer. Look at the CTAP protocol. FIDO Alliance has a good overview here: FIDO Alliance Specifications Overview - FIDO Alliance. CTAP is how the system/browser talked to the authenticator. WebAuthn is how the system talks to the browser. Yubico has a good overview of WebAuthn here: WebAuthn (yubico.com)
Hopefully that helps?
Yes, it helps a lot. Granted, the pre-M1 MacBook Pros with TouchID do actually have a Secure Enclave, it’s on the T2 chip that controls the Touch Bar, but I’ll take your word that it can be implemented in software. Other than hardware generally being more secure than software for encryption (since airgap and access restriction techniques are easier to implement with hardware encryption than software) and hardware solutions being faster, there’s nothing preventing encryption from being done in software.
Agree 100%. That's why I prefer Security Keys over PassKeys. I am concerned about the multi-device syncing of the private keys. I much prefer my private key material to be store on a single external hardware device. The FIDO spec allows for multiple credentials to be registered with an IDP, so I can register 2 or more keys with a service as backup.
My personal opinion, Passkeys are great for the non-tech savvy person. My elderly mother, for example. They provide better security than phishable MFA, but not as secure as a hardware key. Anything to bring Passwordless MFA to the masses! The industry REALLY needs to get rid of insecure MFA technologies.
Certainly we agree that we should put rest to pretending that sending TFA passcodes via SMS is secure!