Re: [webauthn] Consider allowing RPs to indicate that they want platform authenticators to be synced across devices

I'm not incredibly familiar with the details of the webauthn specification, but am fairly familiar with the general flow given we support U2F today. I just wanted to leave a short comment from an outsider's perspective, given a few of us chatting with @leshi on Twitter resulted in this issue being opened: https://twitter.com/aczeskis/status/1011302905872297984. 

>From an implementors perspective (i.e. if/when we add support for webauthn), we would have no interest in mandating a hardware backed token. Let's look at where we are starting (just to summarize the obvious):

* Username/password - Passwords are reused, not well chosen, accidentally logged by some backend server, insecurely hashed, ... (we all know the issue with passwords).
* SMS TOTP 2FA - This has by far the best UX experience for users. But, sadly, we have seen this approach devolves into carrier based security 😬.  
* App TOTP 2FA - People install the secret on a singular device and eventually either lose the device, wipe an old device without realizing the TOTP secret is not backed up, etc. Moreover, it requires the RP to store the TOTP secret server-side for validation. 
* Backup codes - We all know this was a punt, as we had nothing better to offer folks. Lots of folks lose these as they sit in a downloads folder and are eventually deleted. 

In short, all of the above have lots of issues that eventually lead to users getting compromised and/or locked out of their accounts. Many sites are in a tough spot trying to strike the right balance between account security and usability (i.e. hoping a legitimate user doesn't get locked out of their own account). I don't deny there is value in a HSM style authenticator for some people and/or specific use cases. But, for the vast majority of users and sites, an API driven exportable webauthn key pair that can be synced using their platform of choice (iCloud Keychain, Google account (ala password syncing today), etc) would be a huge ^ :100: step forward. 

Some folks have suggested existing synced password manager based systems are sufficient for this use case. Sure, it is "sufficient". But, once we have a programatic API between a browser and RP, why would anyone want to use passwords anymore? Key pairs are meaningfully better across all axes for this kind of thing. Even if a password is randomly generated and unique per-site, it still is far more probable to leak sensitive information in various logs, be stored insecurely, etc. 

> I would recommend pairing such a flag (if we should end up supporting it) with the ability of an authenticator to express support for non-exportable/non-migratable keys in the attestation statement 

I'm not super clear on the implementation details, but some notion of attestation sounds ideal. If a RP actually wants to require per-device tokens they can. I can imagine some sites might even have a use case for this based on administrative settings (ex. a google apps account admin that can choose whether their organization wants to require per-device tokens or not).

As an aside, what would happen today if a browser implemented a "soft token"? In other words, if Apple released a version of Safari tomorrow that implemented this full flow purely in software and stored the key pair in iCloud keychain, would that violate something in terms of compliance, certification, ....? 

-- 
GitHub Notification of comment by ptoomey3
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/969#issuecomment-401063092 using your GitHub account

Received on Thursday, 28 June 2018 14:54:12 UTC