- From: Meydan Ozeri via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Jan 2022 00:07:35 +0000
- To: public-webauthn@w3.org
I have some idea that I'm playing with in my head to try and create a secure recovery flow in case of total loss of all authenticators, basically it relies upon asymmetric encryption signatures. Upon registration the clients browser creates a public private key pair, it shows the user the private key in the form of a seed phrase (same as crypto wallets) and tells the user to store it safely, after the user is confirming that he stored it, the public key is saved by the RP for a future recovery scenario, and the private key is deleted. When the user triggers the recovery flow, the RP will send a randomly generated message to the client, the client will be prompted to provide his seed phrase (private key) and the clients browser will use it to sign the message provided by the RP, then it will send the signed message to the RP where it will be verified by the public key associated with the account, if the signature is valid we can be certain that the correct and only private key was used. After that the user will get the ability to perform a new attestation and create a new credential, when he is done all the old credentials will be deleted, and he will be shown a new recovery seed phrase for future recovery scenarios. (making it a one time use recovery phrase) I find that this approach is a safe option since it is resistant to RP database breaches as acquiring the public key will not help the attacker, the private key is generated on the client side and doesn't leave it, so it is resistant to man in the middle attacks. Brute forcing/guessing attacks are irrelevant since there are to many different possibilities for a private key when using a secure asymmetric algorithm such as ECDSA/RSA. The only security issues I can come up with this approach is that it is not resistant to phishing attacks/social engineering attacks + the user will need to store it safely otherwise it is open to theft attacks. I'm still trying to find a way to invalidate phishing/social engineering attacks with this approach. so far I didn't find a way. Looking forward for your feedbacks on this idea. -- GitHub Notification of comment by MeydanOzeri Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1640#issuecomment-1005267072 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 January 2022 00:07:37 UTC