- From: Arshad Noor <arshad.noor@strongauth.com>
- Date: Tue, 12 Jul 2016 20:44:00 -0700
- To: "public-webauthn@w3.org" <public-webauthn@w3.org>
- Message-ID: <5785B900.9080206@strongauth.com>
I am beginning to think we are definitely discussing very different issues.
My concern is not so much that RPs will attack
webauthn-enabled-biometric-devices (WEBD), but that if WEBDs did _not_
affirm that webauthn is being used, _non-WEBDs_ will take advantage of
the lack of affirmation (from WEBDs) and attack unsuspecting consumers
to potentially leak private information (from non-WEBDs).
How will they attack them? I honestly cannot predict that; if I could,
I'd be in a different business.
Consequently, IMO, even before webauthn is finalized, it makes sense to
define an affirmation signal that webauthn is being used. Then, 250+
members of FIDO Alliance, W3C and others can educate the marketplace
about only using Authenticators that affirm the webauthn signal. Given
the despise consumers have for passwords, this message is likely to have
a far more lasting effect than the TLS lock symbol.
I believe I've hashed this thread enough and said all I wanted to say on
the subject. Its now up to the WG to decide what's in the best interest
of the ecosystem; if platform vendors put out a webauthn signal, the
ecosystem can/will leverage that in their message; if there's none, one
can only hope the industry's professionals haven't failed consumers once
again.
Arshad
On 07/11/2016 11:44 PM, Vijay Bharadwaj wrote:
>
> But these things are not analogous - we’re comparing apples to solar
> flares.
>
> I’m asserting:
>
> -Today, there is really only one way for JS to interact with
> biometrics, and that is WebAuthn.
>
> -Mandating browser UI is a tricky subject, not least because it leads
> to surprising unintended consequences.
>
> -The experience with the TLS lock icon shows that users simply aren’t
> capable of making an informed security decision in most cases. The
> whole push for HTTPS everywhere stems partly from this – it’s hard to
> tell when insecure use is okay, so just remove it altogether.
>
> -Therefore we’re much better off striving to keep non-strong
> biometrics off the web altogether, rather than introducing more
> confusing UI elements that will only serve to confuse users.
>
> Which part of that thesis are you taking issue with?
>
> Stated in a different way, if I were a nefarious entity trying to use
> a non-strong biometric device over the web, how would I even do it? If
> the only way to do this is by exploiting the browser in some way, then
> couldn’t I also use the same exploit to spoof whatever UI signal the
> browser might use to show secure biometrics were in use?
>
> To be clear, I agree that it’s important to assure users about their
> security. I’m arguing that in this case, browsers can trivially do
> this by not adding code (that does not exist today) for supporting
> insecure biometrics. Since the secure way also happens to be the
> cheaper and easier way, it seems likely that it is the path that
> implementers will choose.
>
> *From:*Arshad Noor [mailto:arshad.noor@strongauth.com]
> *Sent:* Monday, July 11, 2016 5:05 PM
> *To:* public-webauthn@w3.org
> *Subject:* 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 <mailto: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 Wednesday, 13 July 2016 03:44:38 UTC