Re: Signal to end-user when using webauthn

Vijay,

Every zero-day attack was something that wasn't anticipated by the 
original developers of the software; because something isn't possible 
based on what we know today doesn't imply that someone will not figure 
out a way to make it possible.

That the experiment with the TLS lock icon didn't work so well in your 
opinion, implies that the industry did not do enough to educate 
consumers.  Otherwise why would there be an industry initiative 
<https://letsencrypt.org/> to get every site to HTTPS across the 
internet currently?

Arshad

On 07/11/2016 04:31 PM, Vijay Bharadwaj wrote:
>
> I’m claiming that there isn’t such a thing – there is no way in JS 
> today for a website to access biometric auth through a browser. There 
> are different ways to use platform-specific biometrics for client 
> apps, but that’s it AFAIK.
>
> If the above is true, it would seem this is not a problem that we need 
> to solve for the web browser platform. In any case, experience with 
> the TLS lock icon indicates that expecting users to see the lack of 
> something as bad typically doesn’t work out so well…
>
> *From:*Arshad Noor [mailto:arshad.noor@strongauth.com]
> *Sent:* Monday, July 11, 2016 3:46 PM
> *To:* public-webauthn@w3.org
> *Subject:* Re: Signal to end-user when using webauthn
>
> To be candid, I don't know.  I don't use biometric technology to 
> authenticate to websites, so I would not know.
>
> However, what I /do/ know is, if webauthn did not provide affirmation 
> when the protocol is in use, biometric devices using webauthn are 
> going to be tarred with the same brush (as non-webauthn devices) when 
> some poorly or maliciously implemented biometric device leaks private 
> data to the RP.
>
> Arshad
>
> P.S.  I'm confident readers on this list need no reminders 
> <https://en.wikipedia.org/wiki/Stuxnet> whether someone will build a 
> malicious device that are innocuous enough on the surface.
>
> On 07/11/2016 02:35 PM, Vijay Bharadwaj wrote:
>
>     The question still stands though – what is an example of an
>     existing non-FIDO mechanism through which an RP on the web
>     platform can interact with a biometric device or see biometric data?
>
>     *From:*Arshad Noor [mailto:arshad.noor@strongauth.com]
>     *Sent:* Monday, July 11, 2016 11:23 AM
>     *To:* public-webauthn@w3.org <mailto:public-webauthn@w3.org>
>     *Subject:* Re: Signal to end-user when using webauthn
>
>     What you are asking for is the impossible, Vijay (teaching users
>     to recognize browser extensions are bad).  In an age when CEO's of
>     tech companies
>     <http://www.siliconvalley.com/michelle-quinn/ci_30101453/quinn-twitterceohack-claims-whos-who-tech-victims>
>     use passwords like "dadada", there is little hope of teaching the
>     average user intricacies of browser extensions.
>
>     Biometric data _does_ matter because users are concerned.  Users
>     have given up hope that passwords can be protected; what the
>     ecosystem needs is an assurance that the next-generation
>     authentication technology will not do the same for biometric data.
>
>     To achieve that, what users need is a signal from platform vendors
>     that their biometric device is using the built-in webauthn
>     protocol and not something else; heck, even a professional like
>     myself would like to see affirmation that platform-integrated
>     webauthn is being used in conjunction with whatever gesture is
>     used to authenticate the user to the device.  Given that this WG
>     is focused on standardizing a strong-authentication protocol for
>     the web-platform, it seems appropriate that the WG should consider
>     adding a platform-controlled mechanism to affirm to the user when
>     webauthn is in use.
>
>     Arshad
>
>     On 07/07/2016 11:29 PM, Vijay Bharadwaj wrote:
>
>         I see, so the concern is not about biometric data at all, but
>         that these vanilla devices enable passwords and all the
>         badness associated with them. So in the popular imagination a
>         few breaks of these systems will promote a feeling that these
>         biometric gadgets are no better than passwords and may be worse.
>
>         How do RPs currently interact with such plain vanilla
>         biometric devices? I thought that these were primarily
>         accessed through browser extensions that are doing form-fill
>         of passwords, so the RP doesn’t even know that they are in
>         use. Is that accurate? Why not just teach users to recognize
>         those browser extensions as potentially bad?
>
>         *From:*Arshad Noor [mailto:arshad.noor@strongauth.com]
>         *Sent:* Thursday, July 07, 2016 7:21 PM
>         *To:* public-webauthn@w3.org <mailto:public-webauthn@w3.org>
>         *Subject:* Re: Signal to end-user when using webauthn
>
>         The concern is not that attackers might collect biometric data
>         from a webauthn-capable device, but from non-webauthn-capable
>         (plain vanilla) biometric devices.
>
>         The vast majority of biometric authenticators today do not
>         use/support FIDO/webuthn protocols (yet).  I surmise these
>         devices manage {origin, userid, password} tuples much like
>         password-managers, authenticating users to a site after
>         authenticating them with a biometric-gesture.  However, in the
>         absence of a /webauthn-signal, /these "plain vanilla" devices
>         will _appear_ to function like webauthn-capable biometric
>         devices from a UX pov,
>
>         Such "plain vanilla" devices are unlikely to disappear even if
>         the webauthn spec is finalized and platforms support it
>         immediately; RPs are unlikely to migrate to webauthn
>         immediately for lots of non-technical reasons. However, by
>         having a /webauthn-signal/ show up before the
>         biometric-gesture, end-users can be educated to recognize
>         privacy-protecting devices/sites from potentially dubious ones.
>
>         In a world where every biometric device and site is
>         webauthn-capable - _and_ enabled - this signal would be
>         unnecessary.  But just as the "SSL lock" helps differentiate
>         data-protecting sites from unprotected ones, a webauthn-signal
>         can help differentiate privacy-protecting sites from
>         questionable ones.
>
>         Arshad
>
>         P.S.  The phishing attacks, if successful, will work only on
>         "plain vanilla" devices; but sans a webauthn-signal, the PR
>         fallout will affect all devices - whether webauthn-capable or
>         not - and potentially deter consumers from using any device.
>
>
>         On 07/05/2016 08:59 PM, Vijay Bharadwaj wrote:
>
>
>
>             Arshad,
>
>               
>
>             Would you please elaborate on the phishing concern here? Is it that a website may somehow find a different way to show UI and gather the user's biometrics (and if so, how would it do that)?
>
>               
>
>             Similarly, what's the privacy issue? When would a biometric gesture be prompted by the browser without a WebAuthn call, and what would the website be hoping to gain?
>
>               
>
>             There are of course ways for a website to compromise privacy by overusing WebAuthn - for instance a site may call getAssertion for no good reason, just to check whether a particular user is present (figuring that if they are like most users they will provide a biometric, just to make the prompt go away). But isn't that more about what is in the heart of the caller, and unlikely to be affected by the type of signal you propose?
>
>               
>
>             -----Original Message-----
>
>             From: Arshad Noor [mailto:arshad.noor@strongauth.com]
>
>             Sent: Tuesday, July 05, 2016 5:55 PM
>
>             To:public-webauthn@w3.org <mailto:public-webauthn@w3.org>
>
>             Subject: Re: Signal to end-user when using webauthn
>
>               
>
>             No, its not.  This is necessary not only for key-registration (where attestation comes into the picture) but for every authentication.
>
>               
>
>             Users are going to be prompted for the biometric gesture each time a biometric Webauthn Authenticator is activated for use: registration, authentication and transaction confirmation.  If they do not see a standard signal when Webauthn is in use, not only do they NOT know if there is a privacy-leak, but they also become vulnerable to phishing attacks (since the platform is not giving off any signals to the contrary).
>
>               
>
>             Arshad Noor
>
>             StrongAuth, Inc.
>
>               
>
>             On 07/05/2016 04:18 PM, Anthony Nadalin wrote:
>
>                 Isn't this already implied by the attestations that may be part of the registration (which is out of scope of the W3C WebAuthn WG).
>
>                   
>
>                 -----Original Message-----
>
>                 From: Arshad Noor [mailto:arshad.noor@strongauth.com]
>
>                 Sent: Sunday, July 3, 2016 6:41 PM
>
>                 To:public-webauthn@w3.org <mailto:public-webauthn@w3.org>
>
>                 Subject: Signal to end-user when using webauthn
>
>                   
>
>                 I'm not sure if this is part of this WG's purview, but as the WG focuses on standardizing Webauthn, I would like to suggest adding one more element to its scope: a signal to the end-user when the platform is using the Webauthn standard to strongly-authenticate the user.
>
>                   
>
>                 An informal case for this is documented in this brief blog entry:
>
>                 *Not all biometric authentication is equal* -https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2falesa.website&data=01%7c01%7ctonynad%40microsoft.com%7cc713a71937b848c356c608d3a3ac794a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7WkozRldsTeHy6HRLVcQ27tpPOI0VryBKbrWtCTuXWM%3d.
>
>                   
>
>                 Thank you.
>
>                   
>
>                 Arshad Noor
>
>                 StrongAuth, Inc.
>
>                   
>

Received on Tuesday, 12 July 2016 00:05:24 UTC