Confirmed Passkey removal does not invalidate existing sessions

[Kirby]

Affected version

2.3.0 Beta 4

Steps to reproduce

1. Create a new account
2. Add a Passkey in browser context A
3. Log into the account with the passkey in another browser context (B)
4. Log into the account with username and password in a third browser context (C) using a backup code as TFA
5. Remove the Passkey from browser context A
6. Check session status in browser context B and C
7. Add another passkey in browser context A
8. Log into the account with the Passkey in browser context B
9. Change the password in browser contect A
10. Check session status in browser context B and C

Expected Result

1. The session in browser context B is invalidated in step 6) while the session in browser context C) is unaffected (Preferred)
   or
   The sessions in browser context B and C are invalidated in step 6)
2. Sessions in browser context B and C are invalidated in step 10

Actual Result

1. Sessions in browser context B and C are unaffected in step 6)
2. Sessions in browser context B and C are invalidated in step 10)

Not invalidating sessions that were created using a removed Passkey seems to be a security issue to me:
A passkey acts like a password replacement - if an authenticator is lost / compromised and thus removed from an account, I would expect all sessions that used it to get invalidated immediately to prevent account abuse - just like they are when the password is changed.

 

[Xon]

Part of the issue is XenForo session management is functionally all or nothing around the password date field.

Only logging out affected sessions with a removed passkey isn't doable without tracking individual sessions or just logging out all sessions.

 

[Kirby]

Yeah I know - but at least invalidating all other sessions for a user when a Passkey ist removed should be easy (by updating UserProfile.password_date).

Ideally I'd store the used TFA option in UserTfaTrusted and tfa_trusted_id in the session.

This would allow to delete affected UserTfaTrusted entities when a Passkey is removed and subsequently delete Sessions that have the deleted tfa_trusted_id

 

[XF Bug Bot]

Automated triage: Design issue

Thank you for reporting this issue. Removing a passkey currently deletes only the passkey itself. Other logged-in sessions are only ended when the account password changes, and sessions don't record which login method created them. Changing this would be a change to how the feature is designed rather than a bug fix.

This is an automated assessment. A member of staff may review and update it.

 

[Kirby]

Changing this would be a change to how the feature is designed rather than a bug fix.

I strongly disagree on this verdict:
Passkeys are considered / advertised as a secure alternative for passwords , eg. they allow to log into the acount without the password.

As such they should be treated with the same care as passwords - removing a password (and setting a new one) invalidates all sessions, including sessions that were created with a Passkey.

At very least the same behaviour should be applied for passkeys:
If a passkey is removed all sessions should be invalidated.
While IMHO not ideal, this would be simple and secure - patch attached.

I therefore consider this a security relevant bug and not a design issue.