[auth] need a login interception point for authentication-related plugins #2118

New Issue

2026-10-05T01:06:51+02:00

adam commented

2026-10-05 01:06:51 +02:00

The current pwg_login() workflow always calls log_user() immediately after a successful username/password verification.

This makes it impossible for authentication-related plugins (2FA, rate limiter, IP allow/deny lists, geolocation checks, etc.) to properly intercept or control the login flow.

Today, a plugin must let log_user() happen, then manually block the session and redirect the user (e.g. to a 2FA verification page).
This approach is fragile, creates edge cases, and is not ideal from a security perspective because the session is technically "already logged in" before the plugin can perform its checks.

Proposal:
Introduce a small extension point inside pwg_login(), for example a finalize_login hook, that allows plugins to:

decide whether the login can proceed
block the login temporarily (e.g. while waiting for a second factor)
optionally perform their own log_user() once their checks are completed

The core still handles password verification normally.
Plugins simply get the ability to approve or deny the final authentication step.

The current `pwg_login()` workflow always calls `log_user()` immediately after a successful username/password verification. This makes it impossible for authentication-related plugins (2FA, rate limiter, IP allow/deny lists, geolocation checks, etc.) to properly intercept or control the login flow. Today, a plugin must let `log_user()` happen, then manually block the session and redirect the user (e.g. to a 2FA verification page). This approach is fragile, creates edge cases, and is not ideal from a security perspective because the session is technically "already logged in" before the plugin can perform its checks. Proposal: Introduce a small extension point inside `pwg_login()`, for example a finalize_login hook, that allows plugins to: - decide whether the login can proceed - block the login temporarily (e.g. while waiting for a second factor) - optionally perform their own `log_user()` once their checks are completed The core still handles password verification normally. Plugins simply get the ability to approve or deny the final authentication step.

adam closed this issue

2026-10-05 01:06:52 +02:00

adam commented

2026-10-05 01:06:53 +02:00

In addition, the current login workflow makes user enumeration possible through timing differences:

when the username exists, password_verify is executed → slower
when the username does not exist, the function returns much faster

A simple mitigation is to introduce a fake user with a valid hashed password and always run the password verification step, regardless of whether the user exists.
This keeps authentication time consistent and prevents timing-based user enumeration attempts.

In addition, the current login workflow makes user enumeration possible through timing differences: - when the username exists, `password_verify` is executed → slower - when the username does not exist, the function returns much faster A simple mitigation is to introduce a _**fake user**_ with a valid hashed password and always run the password verification step, regardless of whether the user exists. This keeps authentication time consistent and prevents timing-based user enumeration attempts.

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#2118