Case of stolen device and same key by muliple user

[hetin k]

Hi all,

does stolen device case come under threat model of security key? Does relying party has any concern over stolen device?

is it legitimate to use same key by multiple user? does standard has any guidelines regarding this or it is based on relying party policy?

Thanks

[Arshad Noor]

Any Relying Party (RP) that does not factor in stolen Authenticators
into their threat model is not addressing all their risks. "Account
takeovers" and privacy breaches are just two consequences that can
result from stolen credentials.

It will be a rare RP that will legally permit multiple users to share
the same credential - perhaps in situations that permit parents and
their children to login to controlled sites. In almost any other
situation, RP Terms & Conditions will most likely prohibit sharing
credentials; but, it is not something RPs can technically prevent - it
is just a legal means of minimizing their liability.

The FIDO/WebAuthn specifications cannot take policy stands - they can
only enable technology to do specific things; RPs must review and
understand the technology thoroughly and establish the policy they want
to implement to addresses their business requirements.

To give you an understanding of how our open-source FIDO Certified
server implements security policy, take a look at:

https://docs.strongkey.com/index.php/skfs-home/skfs-administration/skfs-security/skfs-policy

Here is a web application demo that implements these policies:

https://demo.strongkey.com/fidopolicy/

These are not the only policies that are possible; but you don't want to
get carried away defining too many custom policies. Ideally, an RP
should define no more than 3-4 policies that cover most of their
business risks.

Arshad Noor
StrongKey

> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/8f4b49cd-91ed-4bac-a631-dbe6cc8a76cbn%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/8f4b49cd-91ed-4bac-a631-dbe6cc8a76cbn%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[Emil Lundberg]

> does stolen device case come under threat model of security key? Does relying party has any concern over stolen device?

Yes, the user needs to protect their security key from theft much like they would protect a password or house key. RPs should allow users to add and remove security keys at any time so the user can "revoke" keys they've lost. Ideally, RPs should also allow users to set nicknames for their keys to help keep track of which is which.

>is it legitimate to use same key by multiple user? does standard has any guidelines regarding this or it is based on relying party policy?

Yes, it is legitimate - both using the same authenticator for multiple accounts, and multiple persons using the same authenticator with a shared account. If the authenticator is well-behaved, the RP cannot tell whether it is being used with multiple accounts or by multiple persons.

Emil Lundberg

Software Engineer | Yubico

--

You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/8f4b49cd-91ed-4bac-a631-dbe6cc8a76cbn%40fidoalliance.org.

[Emil Lundberg]

(Although, as Arshad points out, sharing an account and/or authenticator may violate the RP's terms of service. But that is a contractual issue rather than a technical one.)

Emil Lundberg

Software Engineer | Yubico

[Tim Cappalli]

Creating a discoverable credential with credProtect level 3 (UV required) can help ease some of the concerns of someone picking a security key up off the ground and easily gaining access to an account.

tim

---

From: 'Emil Lundberg' via FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Sent: Tuesday, November 22, 2022 09:35
To: hetin k <het...@gmail.com>
Cc: FIDO Dev (fido-dev) <fido...@fidoalliance.org>
Subject: Re: [FIDO-DEV] Case of stolen device and same key by muliple user

 

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CANMnvkxe%2BzJhaGRsZkKqj5exdXz4%2BnBLFUEm%2BSJi89L4X2g6pA%40mail.gmail.com.

[My1]

I would also add the date of creation AND last use, in order to prevent any swaparound ideas (e.g. deleting an existing Key and adding a new one under the same name.

Also a notification if anything is changed on the security key side can also be a good option.

While maybe not fool proof there are ways. for example FIDO is generally associated with 2FA, be that a password on the Site, or plain and simple UV for the token.

@tim I dont think you even need credprotect on that front as long as the site makes sure there's SOME SORT of second factor involved.

I mean no matter what credprotect states, if the site forces a password, or even better just UV, the attacker wont get in, without having that.

Regards

My1

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CANMnvkwQdcDQFmkpndozfmgUhcwY0Te%3DT%3D9_72B6oGM9_2RYFw%40mail.gmail.com.

[hetin k]

Thank you all.

[As Negras]

Gaukite „Outlook“, skirta „Android“

---

From: fido...@fidoalliance.org <fido...@fidoalliance.org> on behalf of hetin k <het...@gmail.com>
Sent: Wednesday, November 23, 2022 7:38:38 AM
To: My1 <teamhyd...@gmail.com>
Cc: Emil Lundberg <em...@yubico.com>; FIDO Dev (fido-dev) <fido...@fidoalliance.org>; Tim Cappalli <Tim.Ca...@microsoft.com>

Subject: Re: [FIDO-DEV] Case of stolen device and same key by muliple user

To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAL-7hFQfev-MybWSfA%3DhYP2G5Hb89TGTPXVobNRorQD1XXdiUw%40mail.gmail.com.

[Kosuke Koiwai]

> https://demo.strongkey.com/fidopolicy/

I'm just curious that "Restricted - Apple" allows attestation:none
while it claims to be "a very secure policy".

The demo site also says "Does NOT use Passkey (Coming soon)." I'm
wondering if you have found any workaround to force single-device
credentials on iOS16+ devices.

Thanks,

Kosuke

> To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
> To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/b2bad69f-20a4-86c3-670a-aee415a4fc35%40strongkey.com.

[Arshad Noor]

Hi Kosuke,

This web application was created when Apple supported only the Developer
Release of FIDO/WebAuthn. At the time, Apple was sending an "apple"
attestation that could be verified as originating from an Apple device
(MacBook or iPhone); as such it could be classified as a "Restricted"
policy.

However, when Passkey became a release feature, we realized that Apple
devices did not send any attestation during registration (they were
sending "none").

Unfortunately, it appears our engineers updated the "Restricted-Apple"
policy on the back-end to include "none" attestation in addition to
"apple" attestation, but did NOT update the visible policy definition in
the web application that only shows "apple". We apologize for this
misleading behavior and will correct it this week.

However, if you test out a new web application we created that
integrates Citrix environments leveraging SAML SSO, you will find that
within this web application's Key Management page, you will see a
Passkey show up as an "Unknown Authenticator" while an Apple device
using an older operating system (such as a MacBook with macOS Big Sur v
11.6.4) shows up as a Platform Authenticator when used with TouchID. You
can find the new web application, leveraging the new FIDO Alliance UX
Guidelines at:

https://citrixgateway.strongkey.com.

RPs expecting to use Apple devices with Passkeys currently are not going
to get the signals they need with standard FIDO/WebAuthn protocols -
since they devices do not send any attestations. I imagine, Apple gets
proprietary signals when you accept storing the Passkey within iCloud;
consequently, they can afford to assume the risk of storing your private
key in their cloud (assuming you trust them with your private key) - but
any other RP that does not have access to those proprietary signals is
flying blind.

We will need to wait and see what happens with WebAuthn Level-3 is
standardized. If the specification provides a mechanism to create a
device-resident credential WITH an attestation that does NOT rely on a
Passkey authentication, then there may be a secure path for RPs. Until
then, all an independent FIDO Server supplier like StrongKey can do is
provide a signal to RPs that an Unknown Authenticator was used within
the registration process and let the RP make a decision on what they
want to do. If the FIDO policy is set to reject Authenticators without
an attestation, then the only recourse is for the RP to provide a signal
to the user that they are using a device/Security Key whose security
attributes cannot be determined using industry standards, and as such
the registration is being rejected.

Hope that helps.

Arshad

[Kosuke Koiwai]

Hi Arshad,

Thank you for the clarification. I remember iOS passkeys beta rejected
registration requests with attestation:direct/indirect in early days.
I also hope Apple's future implementation will provide RPs a way to
create device-bound credentials with attestation.

Kosuke