Re: [webauthn] Standardising support for software authenticators (#1175)

Hi Shane,

You are correct that I would recommend attestation and advocate only 
using certified authenticators; this is the due-diligence companies and 
government agencies must perform if they don't want to show up on sites 
and reports like these: and

I agree that PKI-issued digital certificates are better than 
human-generated passwords; but once again, the issue of protecting the 
private-key does come into the picture 

Nothing is infallible, I suppose - just a question of how much time and 
money we're willing to put up *before* a breach occurs.


On 2/10/20 8:36 AM, Shane B Weeden wrote:
> Then by the same argument you would require attestation and advocate 
> only the use of whitelisted, certified authenticators. I think I’ll 
> choose to disagree this time round. I personally think a PKI-based 
> authentication system offers much better basic protections against broad 
> scale attacks than one based on human-generated shared secrets, 
> regardless of how the private key is managed.
> Sent from my iPhone
>> On 11 Feb 2020, at 1:11 am, Arshad Noor <> wrote:
>> I would disagree, Shane.
>> When you have an ecosystem - like the FIDO Alliance - promoting how 
>> strong its protocols are, how it eliminates phishing, how it protects 
>> privacy, etc., people just assume that all implementations of FIDO are 
>> equally strong. I know a small percentage of us know better, but the 
>> vast majority of people will not be able to differentiate between 
>> secure implementations of FIDO vs. one that can potentially be 
>> compromised. If people think something is really secure and strong, 
>> they tend to let their guard down - and as a consequence, make 
>> themselves more vulnerable. When the implementation is not 
>> sufficiently secure, then the disappointment is magnified and trust in 
>> the technology is shattered.
>> I would argue that it would be better for consumers to be on their 
>> guard with stupid passwords and recognize that if they want truly 
>> reasonable security, they have pay a little for it.
>> Arshad
>> On 2/10/20 5:59 AM, Shane B Weeden wrote:
>>> Wouldn’t it still be valid from the point of view that the server 
>>> does NOT expose authentication subject to credential stuffing 
>>> attacks? The human element of the value of adding FIDO authentication 
>>> should not be overlooked. Not everyone has good password hygiene or 
>>> uses a password manager.
>>> Sent from my iPhone
>>> > On 10 Feb 2020, at 10:36 pm, Arshad Noor 
>>> <> wrote:
>>> >
>>> > I would argue that you may as well just stick with passwords for
>>> > authentication than use software authenticators, Ki-Eun Shin.
>>> >
>>> > Unless you use a hardware-based cryptographic module on the platform,
>>> > your security is reduced to the knowledge of a password with a
>>> > software-based authenticator. Wherever you store the cryptographic key
>>> > on the platform, the only protection you are likely to have is the
>>> > PBKDF2-derived key from the password that protects the key-pair
>>> > (assuming a password is used - if not, the security is further reduced
>>> > to the point where anyone with access to those keys may authenticate
>>> > with that key).
>>> >
>>> > This is the reason why the FIDO Alliance enabled transporting CTAP 
>>> over
>>> > protocols such as HID, BLE and NFC for "Security Keys"; it enables the
>>> > use of cryptographic hardware to protect the key-pairs on any platform
>>> > that supports those transport protocols. A small price to pay for more
>>> > than a reasonable level of security.
>>> >
>>> > Arshad Noor
>>> > StrongKey
>>> >
>>> >> On 2/9/20 7:22 PM, Ki-Eun Shin via GitHub wrote:
>>> >> CTAP does not define anything about the platform authenticators. 
>>> Where
>>> >> is the best place for discussing about platform authenticators? 
>>> Since we
>>> >> have cases where the platform authenticator might be unavailable 
>>> on some
>>> >> platforms or devices, it's better to leverage software based platform
>>> >> authenticator in this case rather than not supporting WebAuthn on 
>>> such
>>> >> environments.

Received on Monday, 10 February 2020 17:29:33 UTC