The ingredients required to make passwordless websites has been around for a long time.
CLIENT: I want to create a new account SERVER: Sure! Send me a public key. CLIENT: All right! Creating a new keypair CLIENT: Okay, here's the public key! SERVER: Thanks! Registration complete
CLIENT: I want to sign in. SERVER: Please sign this data so I really know it's you. CLIENT: Creating a signature with the private key. CLIENT: Okay, here's the signature SERVER: Verifiying the signature with the public key SERVER: Great! This checks out. You can sign in.
I don't understand why we aren't using them.
There's this cool thing called webauthn api, which relies on physical security keys to that contain the private key. I think keys are cool, but I also think the mechanism should work without needing physical keys
This stack exchange answer has all the information required to use client side public key cryptography as an authentication mechanism
Web Cryptography API Indexed DB
The big issues are:
lost certificate = lost access. Backing up a private key is a basic task, but then requires users to manage the storage of that key - it will inevitably become lost when it comes time to reload the key.
a user wants to use multiple devices - the nature of the private key means copying keys across devices is problematic and becomes a security risk.
Solution: Users can request an existing device to approve adding an additional public key to their user record. Each device has it's own keypair
Enabling users to nominate other users who can approve the original user to regenerate a key.