W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2022

Re: [webauthn] Syncing Platform Keys, Recoverability and Security levels (#1640)

From: Shane Weeden via GitHub <sysbot+gh@w3.org>
Date: Wed, 05 Jan 2022 00:52:21 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-1005289471-1641343940-sysbot+gh@w3.org>
> 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.

You never indicated if in this model the seed phrase is bound to the client or not (i.e. can it be used from any machine/browser or only the one from which the original keypair was generated). 

If it *is* bound to the device, then what advantage does this offer over the current platform authenticator approach, and how does account recovery work on loss of device?

If it *is not* bound to the client, then you have the same phishing and remote attack vector issues as with any shared secret approach.

If you would like to understand why WebAuthn is considered phishing resistant today, I've written an article about it [here](https://community.ibm.com/community/user/security/blogs/shane-weeden1/2021/12/08/what-makes-fido-and-webauthn-phishing-resistent). 

Either way I'm not convinced yet that this approach brings something new to the problem space, but happy to be proven wrong!

-- 
GitHub Notification of comment by sbweeden
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1640#issuecomment-1005289471 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:52:22 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:44 UTC