- From: Arshad Noor <arshad.noor@strongkey.com>
- Date: Mon, 10 Feb 2020 09:29:27 -0800
- To: Shane B Weeden <sweeden@au1.ibm.com>
- Cc: public-webauthn@w3.org
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: https://privacyrights.org and https://www.dlapiper.com/en/ireland/insights/publications/2020/01/gdpr-data-breach-survey-2020/. 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 (https://www.helpnetsecurity.com/2011/03/30/two-more-comodo-ras-compromised/). Nothing is infallible, I suppose - just a question of how much time and money we're willing to put up *before* a breach occurs. Arshad 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 <arshad.noor@strongkey.com> 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 >>> <arshad.noor@strongkey.com> 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