Apple’s Killing the Password. Here’s Everything You Need to Know

Passwords have a significant number of problems, the largest one is password re-use, so if your LinkedIn password gets stolen, it might be tried on your e-mail or bank account. The second is that they are hard to generate and then remember or store. This results in short passwords, easy to remember and therefore non random passwords, or written down passwords. Passwords can often be guessed. Passwords are easily forgotten, requiring complex, vulnerable password reset flows or interactions with fallible customer service reps. There are often policies that require inconvenient password resets where the old one is no longer valid. Passwords do not have attached metadata, so you might enter in a password on a website that looks like paypal, but isn't paypal. It's much easier to phish a password. Passwords can also sit on your clipboard after ctrl+c, which might be vulnerable. Passwords less than 9 characters can be brute forced and even passwords less than 12 characters might be vulnerable to state actors, especially if they aren't completely random.

There is an additional nuance between signing something compared to copying something that results in where data that can compromise you exists in memory. Sending a string to a root owned process and getting a signed string back is a bit different than asking a root owned process for a privileged piece of information (a password) and having that copied into your processes memory.

Pass keys mainly attempt to remove a significant amount of the human factor above (remembering, re-use, reset flows, etc.) while increasing overall convenience without sacrificing security.

Rather than providing the current tuple(id, something only you know, something only you have), the idea is you provide (id, something only you are or something only you know, something only you have). Something you are is face or finger id, and the fallback is something you know, which is your pin. Because keys are more or less universally unique and they can be stored in apples secure enclave or in privileged memory they can also work as something you have. If you run something that turns a QR code into raw text, you will find that 2 factor codes are more or less a private key that is saved into an authentication app on a particular device (iirc).

My question was genuine. I have been trying to look into this before and not found anything on how keys are supposed to be synced across ecosystems. And your links don't explain that either; the Apple link explains how it syncs _within_ the iCloud ecosystem, not how it syncs between the different ecosystems. I didn't find your WebAuthN link before, but quickly skimming through it, I don't see anything about how keys are supposed to be synced between ecosystems. And when I have looked into this before, all I've been able to find is solutions to migrate between ecosystems, not syncing between them, which are wildly different use-cases.

If you have nothing productive to contribute, please don't.

Even if they _were_ to think twice, what are the feasible alternatives? A password manager where you generate passwords for each account? Sure, I do that, you probably do that, but good luck getting your grandma to do that.

This is all super-bad because once it becomes unavoidable, Apple controls _your_ access to everything digital. Apple. Let that sink in. This is the company that backed down on encryption when the FBI asked them to. The company that has stronger device lock-in than any you could imagine.

Am I freaking out unnecessarily? Is my reasoning flawed? Genuine question!