Re: [webauthn] The risk of attacker may can identify whether if the account support FIDO or not (#1475)

The easiest way to address this problem is to do what our open-source 
FIDO Certified server does: to ALWAYS return a challenge and a public 
key - except in the case of non-existent users or users who have not yet 
transitioned to FIDO2 - our server returns public-keys whose private key 
was destroyed as part of the installation/configuration process. As a 
result, the attacker can never distinguish between accounts that are 
truly FIDO2 enabled and those that are not - only a legitimate user with 
an authenticator can respond to the challenge.

We even have a FIDO2 Simulator software module with our FIDO2 server 
that enables RPs to generate as many "fake" key-pairs as necessary to 
seed these NRK accounts within their deployment.  Check it out: 
https://github.com/strongkey/fido2.

Arshad Noor
StrongKey

On 8/27/20 8:39 PM, Keiko Itakura via GitHub wrote:
> keikoit has just created a new issue for https://github.com/w3c/webauthn:
> 
> ==  The risk of attacker may can identify whether if the account support 
> FIDO or not ==
> Hi this is Keiko Itakura from Rakuten which is member of both W3C and 
> FIDO Alliance Japan.
> 
> I'm now discussing the following security risk in WebAuthn at FIDO Japan 
> working group.
> May I ask the thought of W3C and schedule if you have plan to mention 
> about this in the WebAuthn specification?
> 
> - The risk of attacker may can identify whether if the account support 
> FIDO or not
> 
> There is a possibility the CredentialID/Username pair is exposed in the 
> case of NRK(Non resident key) .  For example, if an attacker sends 
> Usernames that can guess e-mail addresses, etc. to the RP, seeing the 
> replies from the RP servers for each, and if a CredentialID-like thing 
> is returned, it can be determined that the account is FIDO supported. 
> The reply is different from the case where FIDO is not supported. If 
> attacker use this point, they can distinguish the FIDO account and the 
> unsupported account. If they use this, they can see that unsupported 
> ones have weak security and are easy to attack. How do you think and how 
> to address for this problem?
> 
> Please view or discuss this issue at 
> https://github.com/w3c/webauthn/issues/1475 using your GitHub account

Received on Friday, 28 August 2020 12:21:45 UTC