Dear Maintainer,
Since the security update 5.12.1-3+deb13u2 (which backports the fix for
CVE-2026-33550), TOTP two-factor authentication can no longer be used
when the user source is an SQL (PostgreSQL) source: the secret is stored
but is not recognised at login, so 2FA is silently disabled.
Environment
-----------
- Debian 13 (trixie), sogo 5.12.1-3+deb13u2
- SOGoUserSources: type = sql, PostgreSQL view, canAuthenticate = YES,
userPasswordAlgorithm = ssha512
- Profile store: PostgreSQL table sogo_user_profile
Steps to reproduce
------------------
1. In Preferences, tick "Enable two-factor authentication using a TOTP
application", scan the QR code, and enter the confirmation code.
-> The confirmation code is accepted (setup appears to succeed).
2. Log out, then log in again.
Actual result
-------------
Instead of being prompted for the TOTP code, the user is shown:
"Two-factor authentication has been disabled for your account. Please
visit your preferences to restore its use and reconfigure your TOTP
application."
sogo.log at login shows, on every login:
SOGoRootPage New TOTP key for '<user>' must be created
Expected result
--------------
Subsequent logins should prompt for the TOTP code; 2FA should stay
enabled.
The secret IS persisted correctly
---------------------------------
Inspecting sogo_user_profile for the affected user:
- c_defaults contains "SOGoTOTPEnabled":1
- c_settings contains "totpKey" with a value of length 20
(the write path correctly applies the CVE-2026-33550 change from a
12-char to a 20-char secret).
So the *write* path stores a valid 20-character key, but the *login/read*
path does not recognise it and decides a new key "must be created", which
disables 2FA. The enable (write) and login (read) code paths appear to be
out of sync — this looks like an incomplete backport of the upstream TOTP
fix (5.12.6 / 5.12.7) onto the 5.12.1 base shipped in trixie.
Fix availability
----------------
This appears to be already fixed in the upstream 5.12.x line: sogo 5.12.9-1
is currently in testing/unstable and ships the proper upstream TOTP code
(rather than a backport onto 5.12.1). This report is therefore mainly a
request to have the corrected TOTP handling reach *stable* (trixie) as a
point/security update, since stable users on 5.12.1-3+deb13u2 with an SQL
user source currently cannot use 2FA at all.
Ruled out
---------
- Clock: server is NTP-synchronised and at the correct time.
- Authenticator app: 1Password and Google Authenticator produce the same
code, and the confirmation code is accepted, so the shown secret is
valid.
- Profile size / truncation: c_defaults is ~3.3 kB; c_defaults and
c_settings are TEXT columns (no truncation).
- memcached: healthy, zero evictions; issue persists after restarting
both sogo and memcached.
- A clean disable / restart(sogo + memcached) / re-enable cycle
reproduces the problem every time.