Provide an explicit way to opt out of multi-device syncing/backups #1714
Comments
|
Hi @lxgr, Yes, your understanding of multi-device credentials is correct. RP that do care about veting device syncing can currently opt-out with device attestation.
Since this is not UX friendly, because the error happen after te registration, I assume that we will soon add another preference selector for registration to specifically request devices without syncing, or an option to generate a key that will never be synced. |
|
I believe that so far the WG has rejected all proposals to have a relying party opt out signal of multi-device credentials. The RP needs to make a decision if their account recovery is stronger than sending a password reset email to the person's apple or google account, then they can perform some sort of stepup to be able to accept the credential if the authenticator is unknown (there is still an open question, if platform authenticators will provide attestations) or the credential is multi-device. The RP can cookie the browser and take that plus the multi-device credential to authenticate from the same browser, or if the cookie is not available due to it being a new device they can perform stepup.(Authenticate with a password, phone call, or roaming single device authenticator.) I think the idea is that RP should not reject multi-device credentials, but can use a cookie, DPK extension(when available) or other factors to step up the authentication to the appropriate level. It will be more work for some relying parties, I agree. This is pushing them towards taking a risk-based approach. |
|
This might unfortunately disqualify the use of platform authenticators in areas where two-factor authentication is explicitly mandated by a regulator, e.g. the EEA in the domain of secure cardholder authentication. A risk decision such as this:
is explicitly prohibited by law in some scenarios there (and password reset emails are not an allowable alternative).
Do we really want to encourage the use of cookies as a form of device binding? If anything, RPs should be using DPKs for that use case, right? On a related note, as a WebAuthN user, I explicitly don't want some of my credentials to be synced to my keychain under any circumstances (in particular the ones relating to financial transaction authorizations). Maybe there should be a parallel discussion around whether users should be provided with a way to opt out of key backups/syncing on a per-key basis? This is a different concern than the one of RPs opting out, though. |
It should not be assumed that simply using a reset email for a platform account will grant access to multi-device credentials.
This is an implementation discussion and would not be part of the WebAuthn specification. |
I read @ve7jtb's comment as implying that multi-device credentials only have to be better than the most common flow of email access recovery, not as a way of resetting access to an authenticator platform account holding multi-device credentials, but I even disagree on that point: While this is arguably the most common scenario, as it is, many of the existing platform and roaming authenticators provide security guarantees significantly exceeding that. This is something that can enable new use cases, e.g. Secure Payment Confirmation. It doesn't seem wise to implicitly roll these security properties back, in the interest of usability, without at least offering a way for RPs to opt out of it. (I do understand that making multi-device credentials opt-in, rather than opt-out, could hurt adoption.)
Got it, thank you @timcappalli ! So if this isn't something the WebAuthN specification would cover, is there any adjacent specification, or is it completely up to implementors? |
No, it is an authenticator implementation decision. |
|
I was making the point that unless the RP is doing something better than email password reset now they have no reason to reject multi-device credentials. It may be that depending on implementation they may be significantly more secure, but I think we can agree that they won't be any less secure. We should concentrate on how to uplift multi-device credentials if required and not focus on rejecting them. My comment about cookies is out of practicality. More RP are going to be able to do that than reimplement their servers to support DPK. DPK is a better option when available, but there is no guarantee that it will be available on all authenticators. Cookies are sort of low tech but work today as a way to know if the device/browser has previously authenticated with a given credentialID. RP who are concerned should probably start there. I don't know how financial institutions are going to deal with the change. perhaps on Android they will only create non discoverable credentials to get around syncing, though that is not part of the spec, and will not work with the updated non modal UX. It is probably best for them to plan to use DPK as a signal when they can in SPC. |
Every financial institution in the EU is doing something better than email password resets, as is required by regulations.
Rejecting multi-device credentials will be possible, either via #1692 or more generally via requiring attestation and blocking all implementations known to sync. The suggestion here is to offer RPs an option to indicate a preference for (not) syncing. This would allow implementations to invoke alternative behavior without requiring user intervention (for implementations that make sync capability a user choice via opt-in or opt-out, per credential or globally). |
As mentioned, some institutions are required by regulations to properly implement identity proofing. This extends to account recovery, and device syncing. Those institutions will either:
My guess is that the implementation considerations that will be provided will be to either:
|
This would indeed be a way to enforce the current, non-syncing behavior if I understand it correctly. Given that DPK is accepted as proposed, this proposal is then mostly syntactic sugar on the RP/API consumer side. On the implementor side, it still seems useful to have, e.g. for UX purposes (as there is no point in uploading and showing a credential in a user's syncing account and downloading it to their other devices, if it can effectively never be used anyway). |
|
The DPK is a device-bound key for use with the multi-device credential as a device signal for risk assessment. It does not replace the multi-device credential. |
RPs are free to ignore it and only use the DPK for all authentication decisions (and out-of-band mechanisms for new device registration) though, right? Effectively, this would be a complicated and (for implementations) intransparent way of opting out of syncing. |
|
RPs can do anything they choose. That is not the intended usage though and wouldn't be covered in the specification. |
|
I understand that it might not be the intended usage, but I'm hoping to raise some awareness that it still might become a somewhat common pattern due to the regulatory and risk constraints outlined above. If that assumption holds true, migrating from implicit to explicit RP behavior (where implementations would be receiving the "we will never use the synced credential" signal) might be hard or impossible. |
|
I'd recommend discussing in the WebAuthn Community Adoption Group. |
As of now, yes, that is correct. The general position of the WG has been that we want to avoid fragmenting the ecosystem, so we're wary of adding more authenticator selection constraints. There was recent discussion around this in #1688 too. See also: #461, #445, #441, #396.
Rejecting multi-device credentials will be possible, either via #1692 or more generally via requiring attestation and blocking all implementations known to sync.
The "feature toggle" angle is interesting, though. We have this for user verification and discoverable keys, so it's not categorically out of the question. Maybe the fact that we're about to allocate authenticator data flags for this is a hint that it's important enough to warrant a corresponding feature toggle parameter. But still, I feel like it's too impactful for how blunt it is. Even if it only disables syncing rather than rejecting the authenticator outright, that's still quite intrusive. It could easily be misunderstood as a "make it more secure" parameter, which is not at all true. We don't want RPs to use that without carefully considering the implications, because that will get users locked out and driven away from using WebAuthn at all because of the hassle (making them less secure in the end). And again, attestation already provides RPs most of the same powers but in a form that's also verifiable. |
Sorry, to clarify – are you suggesting attestation as a way of opting out of syncing, or attestation and subsequently (upon learning that it's a syncing implementation) not using a given authenticator at all? As far as I understand, the former is only a temporary side effect of attestation that will likely go away once the "backup indicator" is specified and implemented, right?
I do share that concern, as the standard mode of operation of audit-heavy organizations/industries is to just disable all options that aren't explicitly required in the interest of security, and ones that do actually impact it somewhat doubly so.
Agreed – but the other possibility here is some organizations/industries never adopting WebAuthN and sticking with proprietary app-based solutions (or worse, like SMS-OTP). |
Sorry, I mean that RPs can "opt out" of credential syncing by requiring attestation and rejecting any authenticator not known to not sync (sorry for the multiple negations, they are significant). It doesn't allow for simply disabling a sync feature, though (thus "most of the same powers"). It's a roundabout way, but it's the only way - even with the authenticator data flags - if you need to strictly forbid syncing. You still need a valid attestation from an authenticator you trust, because otherwise the authenticator can just lie about the flags. Deny-lists (where you accept anything not explicitly on the list, even if unknown) don't work for enforcing a strict attestation policy, only allow-lists do.
Yes, there's nothing that intrinsically prevents syncing authenticators from implementing attestation. For example the "apple" attestation statement format was added specifically to support Apple's platform authenticators, which have now announced plans to introduce syncing. And yes, it's also true that an authenticator that currently supports attestation but not syncing could add a sync feature later. It would be up to that authenticator vendor and any relevant certification authorities to decide if that change needs to be reflected by a change in AAGUID, attestation certificate or the like. |
The backup indicator is mostly for RP that want syncing. In that case it can be used without attestation. If you want to use it for security eg deny syncing it can only be trusted in the context of an attestation. In some cases where an authenticator supports both types of credentials and provides an attestation, the indicator can be trusted to differentiate between the two kinds of credentials. I believe that backup vs not backed up would be under user control not RP. This may get in the way of some of the higher security use cases, though likely no more than platform authenticators not having CC/CSPN/FIPS certification minimum pin length and retry limits for EIDAS etc. |
However, registrations would still be synced. If you as an RP do a new registration when you see a new DPK, you either:
To fix these problems, you need to
|
This is not correct. @timcappalli has made it clear that the data flags are an optional hint, and not a strict assertion that the device does or does not do backups. Which pretty much means they are not a strict rule (the same way that a lot of authenticator selection criteria are hints and not actual criteria). There are now only three situations that exist:
There is practically no way to opt out of multi-device credentials, you have to "opt in" to strict attestation checks if you want single devices. |
|
I propose we close this issue as the question was answered quite a while ago and the current discussion is very circular. This can be picked up in the WebAuthn Community Adoption Group. |
Yes, that's what I said: that you (the RP) cannot trust the authenticator data flags unless they come from an authenticator whose attestation you have deemed a trustworthy assertion that the flags are accurate. This is true for all the flags and does not change with the introduction of synced keys. |
|
Somewhere berried in this there was a request to rename the bit flags to hints. We should specifically discuss that and create a pull request or close. To that point, all information other than the signature itself is untrusted outside the context of a trusted attestation. That includes UV and UP. I don't see why these flags would be different. I don't think they need to be called hints, but don't feel strongly about it, if people think it would be useful to give RP more warning. |
See this discussion: "These are hints, not security properties." However, we do not name or label them as such in the specification meaning that all current RP's and consumers probably incorrectly assume they are security properties.
So either they are strict and a security property OR they are a hint and may or may not represent the true state of the device, even under attestation. That's why it's critical we select and use the correct language because today they are hints, but we advertise them as though they are a security property. Our use of wishy-washy and vague language has already led to CVE's (CVE-2020-8236 - https://hwsecurity.dev/2020/08/webauthn-pin-bypass/, by passes in okta, azure ad, etc.) . This certainly has the feeling of ending up as another trap we are laying for RP's. |
|
The flags are security properties, but a critical question for any security property in any security system is who is the guarantor of that property? This critical question is not unique to WebAuthn, or even to digital systems, which is why it is perhaps glossed over in the spec. In WebAuthn (from an RP point of view) that question can be answered only through attestation, and if you know who the guarantor is you can then decide to what degree you trust them to set the flags accurately and truthfully. That some RPs forget to check the UV flag is unfortunate, but the (contextual) need to verify the UV flag is an explicit step in both RP operations. The spec has never been vague about that. |
|
@emlun No. They are not. The author of the feature themself, quote stated "These are hints, not security properties." Second the UV flag checks are another problem unto themself, especially because preferred doesn't require an RP to check the UV flag, and so many RP's do not. There is also no guidance to direct RP's to store the state of UV from an initial registration to ensure it's consistent (And ctap2.0 breaks this anyway because it forces UV even under discouraged, but then will never UV during auth). |
Sorry in advance if I missed the most recent state of the discussion on multi-device credentials, but if I understand the current proposals correctly,
There might be a roundabout way to accomplish this (e.g. through always requesting a device-bound key per #1658), but am I understanding it correctly that there will be no "easy" way to do so, other than effectively only relying on device-bound keys and ignoring/discarding the "actual" key?
Is this intentional? At least for some scenarios, account takeover/phishing might be a large enough concern that RPs might decide to not accept certain (probably mostly host-based) authenticator models' attestation keys anymore for their service, even though they might otherwise be satisfied with the authenticator's security policies and implementation.
The text was updated successfully, but these errors were encountered: