I'd go more than that and say browsers need to have builtin standards compliant credential managememt. They already manage form login passwords and support stuf

I'd go more than that and say browsers need to have builtin standards compliant credential managememt. They already manage form login passwords and support stuff like webauthn. What needs to happen is for digital signatures need to replace session cookies which can be stolen and are the last frontier in web authentication insecurity. Both passwords and long term private signing keys would be backed by an encrypted backup for moving identity between devices but for runtime usage TPM or FIDOx would store them, far from the reaches of malware. There would be no "login" but rather "identity selection" where you have to type in a password to access the private key (1st factor of auth) after which periodically updated challenge tokens by the site are signed by the TPM or FIDOx device for every request. "Registration" would mean enrolling your public key, that's it. What settings you pick like an account name would be out of scope for the standard. A browser prompt would ask if you want to enroll with a site and have you store the password and related private keys under a named identifier for having multiple accounts. Account recovery is also handled by browsers. They can backup the backup file in their own or someone else's service along optionally with an alternate key for it. That recovery service would let you manage how to do recovery: just email, some other messaging account, offline keys, a different account,etc... users can also opt-out and backup their keys on a separate FIDOx device theu manually sync. Now, what I just suggested means cookies for auth will not be needed. Email will not be needed for security/recovery (or hopefully anything else) and mostly eliminate credential theft/phishing including MFA bypass by way of cookie/token theft. Existing authentication threat models also have you out of scope and unprotected in the event you have operating system malware. This would offer significant risk reduction there. There is a technique now where you "vnc" stream a remote desktop and webusb for usb devices and authenticate to the real site with even a yubikey and the attacker still gets your session cookie and runs off with it to do what they want. This would force them to have you maintain an active session with them with new signed challenges to maintain access. If the challenge is renewed every minute then at most they have access to your account for one minute after you get phished and close the tab. But more than that, the usual auth prompt is by your browser outside of any tab so even ina full screen tab they would need to make the remote vnc in the tab look like your browser UI which can have a security picture associated with it to prevent just this type of phishing. What I am against is drastically changing auth workflows without re-thinking auth workflow/UX. With my idea you kill many birds with one stone. Even the most unaware user can't get phished or easily lose access to their account or have to figure out the right auth UX on a site. And site/app owners just have to get their code to issue new challenge tokens and verify them with their own signing key. No more having to manage and securely store user secrets or support registration/login UI. Better security and risk burdens for everyone!