🚀 Feature: require reauthentication before adding new passkey #4

New Issue

OVERLORD · 2025-10-06T23:57:59+03:00

OVERLORD commented

2025-10-06 23:57:59 +03:00

Originally created by @James18232 on GitHub.

Feature description

Feature request to require the user reauthenticate before adding a new passkey to a pocketID instance (both via code generation to send to a user for use, or directly within pocket id for an admin).

This would obviously not apply to initial passkey setup.

Pitch

This is a hardening step/zero trust approach that removes the risk of a compromised instance leading to persistent access via unauthorised passkeys being added.

The user should have to prove ownership of an existing passkey to add or authorise another for pocket ID.

I consider this important due to the inherent risks of sso allowing unintended access to the pocket ID instance via horizontal movement, poor digital hygiene or otherwise compromised security.

Originally created by @James18232 on GitHub. ### Feature description Feature request to require the user reauthenticate before adding a new passkey to a pocketID instance (both via code generation to send to a user for use, or directly within pocket id for an admin). This would obviously not apply to initial passkey setup. ### Pitch This is a hardening step/zero trust approach that removes the risk of a compromised instance leading to persistent access via unauthorised passkeys being added. The user should have to prove ownership of an existing passkey to add or authorise another for pocket ID. I consider this important due to the inherent risks of sso allowing unintended access to the pocket ID instance via horizontal movement, poor digital hygiene or otherwise compromised security.

OVERLORD closed this issue

2025-10-06 23:58:00 +03:00

OVERLORD commented

2025-10-06 23:58:01 +03:00

@stonith404 commented on GitHub:

I’m not sure this change makes sense. If we add a re-authentication prompt here, we should also require it for creating API keys and creating new users, since both actions can also give an attacker “infinite” access. That would make the flow quite annoying for legitimate users.

If you’re concerned about this risk, a simpler approach is to lower the session duration so tokens expire quickly. You might also want to look at #780, which suggests to add the option to choose between long-lived and short-lived sessions.

@stonith404 commented on GitHub: I’m not sure this change makes sense. If we add a re-authentication prompt here, we should also require it for creating API keys and creating new users, since both actions can also give an attacker “infinite” access. That would make the flow quite annoying for legitimate users. If you’re concerned about this risk, a simpler approach is to lower the session duration so tokens expire quickly. You might also want to look at #780, which suggests to add the option to choose between long-lived and short-lived sessions.

OVERLORD commented

2025-10-06 23:58:02 +03:00

@James18232 commented on GitHub:

Noted.

This could also be solved by having a setting to require reauthentication for pocket ID itself, not just for clients.

@James18232 commented on GitHub: Noted. This could also be solved by having a setting to require reauthentication for pocket ID itself, not just for clients.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#4