Apple to Expand Support for Passwordless Sign-Ins Across Websites and Apps

[MacRumors]

Apple, Google, and Microsoft today announced plans to expand support for a passwordless sign-in standard created by the FIDO Alliance and the World Wide Web Consortium (W3C), promising a faster, easier, and more secure sign‑in process.

The expanded standards-based capabilities will give websites and apps the ability to offer an end-to-end passwordless sign-in option, according to the announcement. Instead of entering a password, users will sign in through the same action that they take multiple times each day to unlock their devices, such as Face ID on the iPhone.

The new approach is described as "radically more secure" compared to passwords and legacy multi-factor technologies, such as one-time passcodes sent over SMS.

Apple, Google, and Microsoft already support FIDO Alliance standards across their platforms, but expanded support will give users two new capabilities for more seamless and secure passwordless sign-ins, as outlined in the announcement:

1. Allow users to automatically access their FIDO sign-in credentials (referred to by some as a "passkey") on many of their devices, even new ones, without having to reenroll every account.
2. Enable users to use FIDO authentication on their mobile device to sign in to an app or website on a nearby device, regardless of the OS platform or browser they are running.

These new capabilities are expected to become available across Apple, Google, and Microsoft platforms over the coming year, the announcement said.

"Working with the industry to establish new, more secure sign-in methods that offer better protection and eliminate the vulnerabilities of passwords is central to our commitment to building products that offer maximum security and a transparent user experience — all with the goal of keeping users' personal information safe," said Kurt Knight, Apple's Senior Director of Platform Product Marketing, in a press release.

Article Link: Apple to Expand Support for Passwordless Sign-Ins Across Websites and Apps

 

[kiranmk2]

Hope this works - even using a password manager is more hassle than it needs to be. The use of biometrics will hopefully also remove the need for 2FA codes.

 

[LeadingHeat]

Can someone explain the security of this? Obviously I doubt that my facial data would be shared with the website, but how does it remain secure?

Would website devs need to drastically change how they code websites or would the phone handle the translation between the website asking for a password and the user just being able to scan their face?

 

[mrbobdobolina]

I have relatives who are very vocal about how much they hate [remembering] passwords. I think this would be a welcome convenience for many people if it works as advertised.

 

[Shin-Ra]

For more on Apple’s implementation of passwordless sign-in search: “Passkeys in iCloud Keychain”

WWDC21 video: Move beyond passwords
Supporting Passkeys

 

[ArtOfWarfare]

As a developer, what do I need to do to support this? How does this actually work?

Based on reading Apple's full press release, it sounds to me like this is just:
1 - Your device automatically generates a password when an account is created, the same as Safari can already do.
2 - Your device automatically fills in the password when it's requested, the same as all browsers can already do.
3 - Your devices will automatically sync these passwords with each other, possibly with more interoperability between brands, so, ie, Windows and Linux and Mac and iOS and Android will all implement the same standards so everything will be more seamless when mixing different types of devices together.
4 - The automatic password stuff is all handled in the background, without any UI needing to be involved, so the end user won't ever see a text field that gets populated automatically for them. So from the perspective of a web developer, not much will change. IDK - will this just make it so that input fields of type password and type hidden are rendered the exact same (which is to say, not at all?)

 

[ArtOfWarfare]

For more on Apple’s implementation of passwordless sign-in search: “Passkeys in iCloud Keychain”

WWDC21 video: Move beyond passwords
Supporting Passkeys

This is all about native apps - how will it work for websites?

 

[zorinlynx]

My main concern with "passwordless" logins is authentication from "first principles".

If you don't have any of your own devices, and want to log into your accounts from a brand new, unknown device, what do you do? I have a couple of critical passwords memorized so that I can get into my stuff if I lose all my devices. These companies seem intent on eliminating all passwords, but at some point you have to have a way to log in if you're starting from scratch.

Conversely, if they do have a mechanism for logging in from scratch, how do they secure it so a bad actor can't pretend to be you logging in from scratch?

 

[bierdybard]

Can someone explain the security of this? Obviously I doubt that my facial data would be shared with the website, but how does it remain secure?

Would website devs need to drastically change how they code websites or would the phone handle the translation between the website asking for a password and the user just being able to scan their face?

Sure! This happens to be an area of interest for me.

The root of this technology is public-key cryptography. With PKC, there are always two related keys: A private key, and a public key. The public key is easily derived from the private key, but the private key cannot be derived from the public key. The public key can decrypt anything encrypted by the private key and vice-versa, but they cannot decrypt things they themselves encrypt without the other key.

When you are signing up, your local device generates the keys, sends the public key to the service you are accessing (this is effectively your "password", but much more secure), and stores the private key in secure storage (so on an iPhone, the Secure Enclave).

In the future, when you log in, the website sends a challenge, which is just a random string of bytes. You unlock the private key on your local device (for iPhone, using biometrics), and sign the challenge locally. A digital signature is a cryptographic hash of the contents of the message being signed (in this case, the server challenge), which is then encrypted with your private key. When you send the signed challenge back to the server, it uses the public key to decrypt the signature (thus verifying it was you that signed the challenge) and then verifies that the hash of the challenge is correct (thus verifying you signed what the server sent and not some other string of bytes). Since the signature both verifies that 1) your private key is the one that created the signature and 2) the challenge the server sent is the one that was signed, you are securely authenticated without needing to send your secret to the server.

Pretty cool, huh?

Edit: answering the other question: Yes, there are some changes that need to be made to websites to handle this. They need to be able to store the public keys, and they need to be able to handle the challenge and response. The WebAuthn standard handles this for websites, and there are a lot of drop-in libraries for just about any web application stack now.

 

[8CoreWhore]

Bring it on... I'm so sick of passwords.

 

[Lemon Mac]

So once you’re dead and gone; how will access to these sites be gratnted if you were to leave details to loved ones?

 

[cambric]

It is the year 2022 and Apple still requires users to have SMS as a fallback two-factor method

 

[8CoreWhore]

Can someone explain the security of this? Obviously I doubt that my facial data would be shared with the website, but how does it remain secure?

Would website devs need to drastically change how they code websites or would the phone handle the translation between the website asking for a password and the user just being able to scan their face?

Move beyond passwords - WWDC21 - Videos - Apple Developer

Despite their prevalence, passwords inherently come with challenges that make them poorly suited to securing someone's online accounts...

developer.apple.com

 

[Jsfrederick]

This is all about native apps - how will it work for websites?

Websites implement the WebAuthn API to consume FIDO2 credentials. Here is a good overview by Yubico: WebAuthn (yubico.com)

 

[bierdybard]

As a developer, what do I need to do to support this? How does this actually work?

Based on reading Apple's full press release, it sounds to me like this is just:
1 - Your device automatically generates a password when an account is created, the same as Safari can already do.
2 - Your device automatically fills in the password when it's requested, the same as all browsers can already do.
3 - Your devices will automatically sync these passwords with each other, possibly with more interoperability between brands, so, ie, Windows and Linux and Mac and iOS and Android will all implement the same standards so everything will be more seamless when mixing different types of devices together.
4 - The automatic password stuff is all handled in the background, without any UI needing to be involved, so the end user won't ever see a text field that gets populated automatically for them. So from the perspective of a web developer, not much will change. IDK - will this just make it so that input fields of type password and type hidden are rendered the exact same (which is to say, not at all?)

Except it's not passwords, it's public-key cryptography.

If you're running a service, you need to set up the service to handle WebAuthn, or whatever this extended standard will be called.

If you're building a client, you'll need to implement whatever APIs are necessary to do the client-side portion of the authentication. This is what the FIDO standard covers, but again, not sure what the APIs will look like outside of the web browser (again, WebAuthn).

So no, it's not zero-effort, but it is infinitely more secure than either passwords or TOTP (numeric one-time passwords) because the secret never leaves the device. In this scheme, the server only needs the public key, which is not the secret.

 

[guzhogi]

Instead of entering a password, users will sign in through the same action that they take multiple times each day to unlock their devices, such as Face ID on the iPhone.

Couldn't one argue that a password is still needed, it just changes from a text password to a biometric one like FaceID?

Same thing with those "keyless entry" doors that require an RFID badge or something rather than an old school key.

Sorry, just like thinking of the logic of this stuff.

 

[Jsfrederick]

My main concern with "passwordless" logins is authentication from "first principles".

If you don't have any of your own devices, and want to log into your accounts from a brand new, unknown device, what do you do? I have a couple of critical passwords memorized so that I can get into my stuff if I lose all my devices. These companies seem intent on eliminating all passwords, but at some point you have to have a way to log in if you're starting from scratch.

Conversely, if they do have a mechanism for logging in from scratch, how do they secure it so a bad actor can't pretend to be you logging in from scratch?

The FIDO2/WebAuthn spec allows for multiple credentials to be registered. I would strongly recommend getting a hardware security Key as a backup and keep in in a secure place (safe deposit box at the bank?). That way, if you loose your phone, you can retrieve your backup key and log into accounts. I have a 3 YubiKeys that I register with every FIDO capable site.

 

[vipergts2207]

This is pretty cool. Nice to see tech work together for a change to make the user experience better.

 

[bierdybard]

My main concern with "passwordless" logins is authentication from "first principles".

If you don't have any of your own devices, and want to log into your accounts from a brand new, unknown device, what do you do? I have a couple of critical passwords memorized so that I can get into my stuff if I lose all my devices. These companies seem intent on eliminating all passwords, but at some point you have to have a way to log in if you're starting from scratch.

Conversely, if they do have a mechanism for logging in from scratch, how do they secure it so a bad actor can't pretend to be you logging in from scratch?

This is where Apple will sacrifice a bit of security in order to provide some convenience.

The basis of this scheme is public-key cryptography. Ideally, the private keys would never leave the device (even more ideally, never leave the Secure Enclave). But what Apple does here is encrypt them the same way your other iCloud data is encrypted and stores them in iCloud, so as long as you can log into iCloud on a device, you have access to your keys.

So yeah, there's still a potentially less-secure gateway there, but bastions still have a lot of value in the security sense.

 

[zorinlynx]

The FIDO2/WebAuthn spec allows for multiple credentials to be registered. I would strongly recommend getting a hardware security Key as a backup and keep in in a secure place (safe deposit box at the bank?). That way, if you loose your phone, you can retrieve your backup key and log into accounts. I have a 3 YubiKeys that I register with every FIDO capable site.

In my case, some sort of "recovery key" would be ideal. If I can keep that on my personal linux server, PGP-encrypted, backed up to multiple locations, I'd feel okay about it. The worst that can happen is a delay getting back in if I can't log into my server for whatever reason.

In the end, though? It's effectively a password.

 

[bierdybard]

The FIDO2/WebAuthn spec allows for multiple credentials to be registered. I would strongly recommend getting a hardware security Key as a backup and keep in in a secure place (safe deposit box at the bank?). That way, if you loose your phone, you can retrieve your backup key and log into accounts. I have a 3 YubiKeys that I register with every FIDO capable site.

That wouldn't be necessary for the Apple case, unless you were protecting your iCloud account itself.

Apple makes a security/convenience tradeoff by storing the private keys in iCloud so they can be accessed by any device which you can log into iCloud with. Yes, ideally the keys wouldn't leave the secure storage of the device, but that's where I would say Yubikeys would come into play, for those things that are so sensitive that the key must never leave secure storage.

 

[Jsfrederick]

Couldn't one argue that a password is still needed, it just changes from a text password to a biometric one like FaceID?

Same thing with those "keyless entry" doors that require an RFID badge or something rather than an old school key.

Sorry, just like thinking of the logic of this stuff.

Yes and no. There are two login flows with WebAuthn. One is 2nd factor. Username, password and then seconf factor. In this case, your Passkey/Security Key using the FIDO standard.

The second flow is the "passwordless" flow. You go to the login page and the website/system sends a challenge back to your device. The devices sees the challenge and begin the login process. You unlock your credential (with FaceID on a iPhone, or a PIN for a hardware security Key) to access the identity informant and begin the public private key verification process. Google uses the former, Microsoft/AzureAD uses the latter.

 

[bierdybard]

This is really, really exciting.

Not only is passwordless a better user experience, it's far more secure.

I've made a couple replies that dive a bit deeper on the technical side of it, but TLDR; with passwordless schemes, your secret never leaves your control. Period, end of story. It can never be compromised because a service had a security leak, never stolen in a man-in-the-middle attack. Even TOTP (the numeric one-time passwords) use a shared secret.

 

[ian87w]

Hopefully this will get implemented by EVERYONE, including government sites worldwide. I have too many relatives and friends who have very simple passwords simply because they cannot remember complex ones and they are not tech literate enough to use password managers nor aware the concept of security. And it’s worse today when every single merchant/institution have their own apps and require you to create an account with a password.

And password managers can only work on properly coded apps and sites. But there are too many of them who are not, rendering the auto login features useless.

 

[Jsfrederick]

In my case, some sort of "recovery key" would be ideal. If I can keep that on my personal linux server, PGP-encrypted, backed up to multiple locations, I'd feel okay about it. The worst that can happen is a delay getting back in if I can't log into my server for whatever reason.

In the end, though? It's effectively a password.

No it is NOT a password. Think Smart Card/PIV/CAC.

A private key is stored securely on a device (iPhone with a Secure Enclave chip, TPM on a motherboard, YubiKey) and ONLY on that device. The corresponding public key is store up in the service your are logging into. The service uses the public key to sign a challenge that is set down to the device and compared using the Private key. Without the device, you cannot login in as there is nothing to compare the public key to.

A password is stored in the service you login to. If that service is compromised, then all bets are off. If the public key at the service is compromised, the attacker still cannot login as they don't have your device.

AND, when you register a FIDO credential with a service, that public/private key pair is ONLY for that service. Each time you register with a service, a new key pair is generated specifically for that service.