Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebAuthn available to Workers? aka "silent authentication" #199

Open
equalsJeffH opened this Issue Sep 14, 2016 · 15 comments

Comments

Projects
None yet
8 participants
@equalsJeffH
Copy link
Contributor

equalsJeffH commented Sep 14, 2016

As I recall, we've verbally discussed the question of whether the WebAuthn API ought to be available to {service, web}workers (aka "Workers") but we do not have an issue tracking it as yet AFAICT, so here it is.

The default argument, as I recall, against worker use of WebAuthn is a UX one: authenticators, upon receiving a makeCredential() or getAssertion() call will signal to the user in some fashion, and since workers are asynchronous tasks, this may seem to the user like coming out of the blue and be confusing.

Though, there are a couple of authenticator-behavior notions that do not always involve annunciation to the user (see also [1]):

  1. for an already-registered authenticator, and an already-authenticated session, the RP may wish to periodically/asynchronously make a getAssertion() request in order to ascertain the continued presence of the same device+authenticator+privateKey as was present at the beginning of the session, and to do so, using subsequent getAssertion() requests without user interaction (because that can become tiresome and distracting to the user). There may be a timeout associated with the session which upon expiry causes appropriate user interaction upon a subsequent getAssertion() request. Let's term this "silent authentication".
  2. for a not-yet-registered so-called "silent authenticator" (the authnr has no provision for user interaction itself), and a session already authenticated (either via webauthn or legacy means), the RP can send a makeCredential (aka register) request, the user is prompted (by the RP or platform) for consent and informed of that the nature of this authnr is to not (itself) prompt the user for registration or authentication events. If the user gives consent, the authnr is registered, and subsequently responds to getAssertion() requests from the RP without user annunciation.

So, if there are use cases where an RP's webapp wishes to employ workers, say, to do some sort of background processing, and that RP wishes to employ [periodic|asynchronous] getAssertion() requests without user interaction (during some allowed time interval perhaps) to aid assurance of overall session context continuity, being able to employ (1) above may be useful.

[1] See also the "silent authenticator" notion:
from https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-asm-api-v1.0-ps-20141208.html#security-and-privacy-guidelines:

  • ASMs SHOULD ensure that applications cannot use silent authenticators for tracking purposes. ASMs implementing support for a silent authenticator MUST show, during every registration, a user interface which explains what a silent authenticator is, asking for the users consent for the registration. Also, it is RECOMMENDED that ASMs designed to support roaming silent authenticators either
    • Run with a special permission/privilege on the system, or
    • Have a built-in binding with the authenticator which ensures that other applications cannot directly communicate with the authenticator by bypassing this ASM.

from https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-authnr-cmds-v1.0-ps-20141208.html#command-description-1:

For silent authenticators, the key handle MUST never be stored on a FIDO Server, otherwise this would enable tracking of users without providing the ability for users to clear key handles from the local device.

@equalsJeffH equalsJeffH added this to the CR milestone Sep 14, 2016

@vijaybh

This comment has been minimized.

Copy link
Contributor

vijaybh commented Sep 14, 2016

I suggest moving this out to a v2 of the spec. For v1 I would focus on the core use case of an interactive user in an active browsing context.

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented Sep 16, 2016

ok, though note that anticipating a v2 augers for us to go ahead and declare the present spec as "level 1".

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented Feb 24, 2017

note that some folks are equating "silent authn" to "touchless authn"

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented May 17, 2017

see also #22 "Silent/touchless Authn? clarification of bit 0 in AuthenticatorData"

@mikewest

This comment has been minimized.

Copy link
Member

mikewest commented May 17, 2017

If y'all have use cases for exposing your authenticators to workers, we can pretty trivially expose the API there. I don't think we'd want to expose the existing credential types to workers, but it's a reasonable thing to debate.

Mind filing a bug against the credential management spec?

/cc @battre

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented May 25, 2017

wrt #199 (comment), see also #475

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented May 25, 2017

@mikewest requested:

Mind filing a bug against the credential management spec?

done. See w3c/webappsec-credential-management#87

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented Oct 13, 2017

some silent authenticator (aka touchless) discussion is also over in webauthn issue #629.

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented Nov 2, 2017

some silent authenticator (aka touchless) discussion is also over in webauthn issue #644

@equalsJeffH

This comment has been minimized.

Copy link
Contributor Author

equalsJeffH commented Nov 2, 2017

fyi/fwiw, UAF supports so-called "silent/touchless authenticators" and has from the beginning. It did not run afoul of the Privacy Principles due to how it is specified. Here's extracts from the relevant UAF specs:

UAF specs wrt "silent/touchless authenticators" -- in the order of "starting at the top and going 'down the stack'" :

fido-uaf-protocol.html (roughly equivalent to the webauthn spec)

https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-protocol-v1.1-id-20170202.html#silent-authenticators

[...]
4.1.6 Silent Authenticators
FIDO UAF supports authenticators not requiring any types of user verification or user presence check. Such authenticators are called Silent Authenticators.

In order to meet user's expectations, such Silent Authenticators need specific properties:

  • It must be possible for a user to effectively remove a Uauth key maintained by a Silent Authenticator (in order to avoid being tracked) at the user's discretion (see [UAFAuthnrCommands]). This is not compatible with statelesss implementations storing the Uauth private key wrapped inside a KeyHandle on the FIDO Server.
  • TransactionConfirmation is not supported (as it would require user input which is not intended), see [UAFAuthnrCommands].
  • They might not operate in first factor mode (see [UAFAuthnrCommands]) as this might violate the privacy principles.

The MetadataStatement has to truthfully reflect the Silent Authenticator, i.e. field userVerification needs to be set to USER_VERIFY_NONE.
[...]

fido-uaf-asm-api.html (roughly equivalent to a CTAP API)

https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-asm-api-v1.1-id-20170202.html#security-and-privacy-guidelines

[...]

  • ASMs SHOULD ensure that applications cannot use silent authenticators for tracking purposes. ASMs implementing support for a silent authenticator MUST show, during every registration, a user interface which explains what a silent authenticator is, asking for the users consent for the registration. Also, it is RECOMMENDED that ASMs designed to support roaming silent authenticators either
    • Run with a special permission/privilege on the system, or
    • Have a built-in binding with the authenticator which ensures that other applications cannot directly communicate with the authenticator by bypassing this ASM.
      [...]

fido-uaf-authnr-cmds.html (roughly equivalent to an authnr driver API underneath CTAP)

https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-authnr-cmds-v1.1-id-20170202.html#register-command

6.2 Register Command

[...]
NORMATIVE
[...]
For silent authenticators, the key handle MUST never be stored on a FIDO Server, otherwise this would enable tracking of users without providing the ability for users to clear key handles from the local device.

[...]

6.3 Sign Command

[...]
6.3.4 Command Description
[...]

8. If number of remaining RawKeyHandles is 1
   [...]
   3.  If TransactionContent is not empty
    * If this is a **silent authenticator**, then return UAF_CMD_STATUS_ACCESS_DENIED
   [...]
   4.  If TransactionContent is not set, but TransactionContentHash is not empty
     * If this is a **silent authenticator**, then return UAF_CMD_STATUS_ACCESS_DENIED
   [...]

NORMATIVE
[...]
Silent Authenticators MUST NOT operate in first-factor mode in order to follow the assumptions made in [FIDOSecRef].

[end extracts]

@akshayku

This comment has been minimized.

Copy link
Contributor

akshayku commented Nov 3, 2017

I may not have understood all the requirements, but from the looks of it, there are some scenarios where user need to authenticate first but can do silent authentication there after for a certain period of time or regularly.

Possibly there can be another scenarios where RP do not have a problem having silent signatures all together and they do not need that first user verified/presence required assertion.

Another set of scenario can be where RP need the guarantee that every signature requires user presence and/or user verification. This is the current default in terms of user presence requirement and provides assurance to the RP that no malware can get silent signatures from the web. This is the requirement for high value keys.

Solution needs to comprehensive for all above requirements although I do not understand scenarios and use cases for it. This is complex and only way I can think of is specifying this behavior for the key at the time of authenticatorMakeCredential and the ability to query this information for the platfrom from the authenticator.

Will all that said, silent signatures from web is a super-cookie for us and is very very dangerous and it brings more harm than good for the whole ecosystem where many RP's will try to think it as a feature without understanding the security guarantees of the choices they are making for their keys. Some RP's maybe willingly try to track user on the web with economic and/or other not good intentions. Being able to get silent signatures basically means that user has its device plugged in to the system or is near by. Cross scripting attacks are also very real from browser pages.

In my view, its not worth it.

@emlun

This comment has been minimized.

Copy link
Contributor

emlun commented Nov 3, 2017

I also think silent assertions would open up more and worse issues than it solves. I can see a case for a "keep-alive session" kind of mode where a user confirmed assertion can authorize silent assertions for a specific RP for some amount of time thereafter, but I'm opposed to "super cookie" silent assertions as @akshayku puts it.

@rlin1

This comment has been minimized.

Copy link
Contributor

rlin1 commented Oct 22, 2018

Decision: Keep open, but no immediate action.
Privacy aspect seems difficult to address appropriately. Use case don't seem that relevant for WebAuthnat this time.

@ve7jtb

This comment has been minimized.

Copy link

ve7jtb commented Feb 20, 2019

To a large extent, this overlaps with token binding. If you do a authentication with the token binding extension you can then token bind a cookie, or otherwise record the token binding ID and check the header on subsequent requests. I understand that token binding is not available on all platforms at the moment. However, I think that is a better way to go than creating a new method of doing super cookies.

@nadalin

This comment has been minimized.

Copy link
Contributor

nadalin commented Mar 7, 2019

There does not seem to be a clear proposed way to solve the security issues. Need a clear scenario(s) and a PR that we can undestand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.