Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
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.

Backups is my main concern with FIDO. Currently I have paper backups of my password in a bank vault and multiple encrypted backups of my data, including passwords, on disks at my home and in other locations.

Having a FIDO key in a bank vault would be very inconvenient, as I would have to fetch the key from the bank to register it with a new account. With my paper backups from time to time I just print a new page and take it to the bank.

And yes, you can also make encrypted paper backups, which I do for my most important passwords.
 
For those asking how this works, here's a simplified explanation based on my understanding from reading and watching the online resources about it.

To register on a new site, say widget.com
  1. You go widget.com and navigate to its new-account creation page
  2. Type in what you want your username to be and then click "create account"
  3. Your phone will bring up a system sheet confirming you want to create a credential for widget.com. After you confirm, the phone will create a site-specific credential token (called "passkey" in FIDO parlance), the security of which is based on public-key encryption.
  4. The phone will store the token and private-key portion of the token on your iCloud Keychain. It will share the public-key portion of the token with widget.com so it can save it on their server.
Whenever you visit widget.com in the future, Safari will know you have a saved credential for the site and will confirm you'd like to login, similar to how it works today for traditional passwords saved in your keychain, including you proving you have rightful access to your keychain (Face ID, passkey, etc...). But instead of a password, Safari will present the passkey (token) to the site (which it already has stored on their server to compare), then verify you're the rightful owner of the token by proving to the site that your phone has the private key associated with the token (challenge/response).
 
Last edited:
How does this factor in someone accessing the accounts of someone who passes away? I have a binder of all my acconts and passwords for my wife in the event that I die. What will she do if this service becomes dominant?
 
  • Like
Reactions: NMBob and Tagbert
safe deposit box at the bank?
I wouldn't rely on that. Read the indemnity clauses that banks make you agree to when getting a safe deposit box. There are no guarantees that anything you put in there is safe. YMMV, you'll have to decide for yourself if this is more or less secure than storing in your own home/workplace/family member's house.
 
I wouldn't rely on that. Read the indemnity clauses that banks make you agree to when getting a safe deposit box. There are no guarantees that anything you put in there is safe. YMMV, you'll have to decide for yourself if this is more or less secure than storing in your own home/workplace/family member's house.

Also mailboxes at shops too. There is a famous case where the FBI had a search warrant for a PO box at one of those shops that do printing and shipping.

Turns out they took ALL the boxes. the other people were screwed the contents were taken as well.
took a LOT of work to get it back.
 
How does this factor in someone accessing the accounts of someone who passes away? I have a binder of all my acconts and passwords for my wife in the event that I die. What will she do if this service becomes dominant?

I think you can assign up to 5 legacy contacts, that will be able to access your iCloud information after you're gone.
 
  • Like
Reactions: macsplusmacs
I honestly prefer it this way because it offers more protection and security.
Not sure how you could interpret my post as being against mandatory 2FA. I didn’t mean that.

I’m against Apple requiring the insecure method of SMS codes, with no way of removing my phone number and no option of using TOTP codes, backup codes or physical security keys for 2FA.
 
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?
I suppose the objective is not to replace all passwords/log-in services, but those which rely on passwrods stored in password managers.

With all services an average user subscribes to it would be net-to-impossible to keep track of them in your mind (unless you use the same password, WHICH IS BAD).

After all with 2FA enabled on your iCloud account, Find My is still accessible traditionally.
 
What happens if you lose the device used to authenticate your face or such, your mobile phone? How do you recover then?

is this like the app "ping id" and "hyper"?
 
  • Disagree
Reactions: EmotionalSnow
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.
I learned a lot from this. Great response! Thanks for typing this out.
 
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?
It would be handled the same way as your organizational SSO and/or Yubikey. A token is sent and that token is used to mathematically validate your identity.
Did a quick search and this seems to provide a decent "101" on passwordless auth: https://www.onelogin.com/learn/passwordless-authentication
 
Centralizing security will expose that centralized protection to targeted, centralized attacks. 2FA is an independent path security protocol that was established to overtly split up encryption keys across one or more independent paths. I am very skeptical that eliminating distributed protection protocols will be as effective, even if it is more convenient, especially as there will be no evidence that is visible to the user to know that a protection protocol is even being used.
 
Last edited:
  • Like
Reactions: snek
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.
Except it is a hash generated from a mathematic representation of your data. Fun fact, though: (I am not a lawyer) it seems that biometrics and other passwordless systems have less legal protections than a password/passcode: https://www.biometricupdate.com/201...etrics-protected-by-fifth-amendment-get-murky
 
  • Sad
Reactions: dysamoria
Except it is a hash generated from a mathematic representation of your data. Fun fact, though: (I am not a lawyer) it seems that biometrics and other passwordless systems have less legal protections than a password/passcode: https://www.biometricupdate.com/201...etrics-protected-by-fifth-amendment-get-murky




A cop, (in the USA) if he pulls one over, can ask for your thumb or face unlock but not your 123 type code password I think?

I think that is the latest about that. anyone?


A good practice is to turn off your phone if you get pulled over. Then if they demand to see it, the phone, turn it on and will ask for the code and you can tell the cop to get a warrant.
 
What happens if you lose the device used to authenticate your face or such, your mobile phone? How do you recover then?

is this like the app "ping id" and "hyper"?
It stores the passkeys on your keychain, which is backed up to iCloud, so the existing methods for restoring from iCloud into a new phone would apply.
 
  • Like
Reactions: monster620ie
Also mailboxes at shops too. There is a famous case where the FBI had a search warrant for a PO box at one of those shops that do printing and shipping.

Turns out they took ALL the boxes. the other people were screwed the contents were taken as well.
took a LOT of work to get it back.
A bit pedantic, but those are NOT PO boxes, they are PMBs (private mail boxes) and considered completely different from a legal standpoint. I do not know about the specific case you mentioned, but it sounds like maybe the warrant did not specify the PMB whose contents were to be collected. Otherwise, they messed up and overstepped the bounds of the warrant, but I am not a lawyer, so...
 
Maybe my principal bank will FINALLY provide some sort of FIDO security. Myself and other members of the bank (in forums) have been pushing for this for a long time. Have no real idea why they refuse to provide it as an option instead insisting that sending a code to one's phone is secure enough. The bank pretty much refuses to provide a reason why it wont provide the option. So fingers crossed that customers can have the option of FIDO-based protection for their bank account if this effort increases FIDO awareness and use.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.