[Pkg-sogo-maintainers] Bug#1142810: sogo: TOTP 2FA broken with SQL user source: secret stored but not recognised at login

[Benoit]

Hi Peter, 
Thank you for the very quick turnaround. No need to apologise at all. 
I tested your patched packages (sogo, sogo-common and sogo-activesync 5.12.1-3+deb13u3 from people.debian.org/~wiene/debs/) on the same production system that originally exhibited the bug (Debian 13 trixie, SQL/PostgreSQL user source). 
It fixes the issue. 
After enabling TOTP and confirming the code, logging out and back in now correctly prompts for the TOTP code, and 2FA stays enabled across repeated login cycles. 
The "SOGoRootPage New TOTP key ... must be created" line no longer appears in sogo.log. 
I confirmed it over several enable / logout / login cycles. 
So from my side this is fully resolved. 
Thanks especially for taking the time to look into this in the middle of August, when most people are on holiday. Much appreciated. 
It would be great to see this reach stable (and bookworm) as a regression update. 
Best regards, 
Ben

Le Samedi 15 Août 2026 13:30 CEST, Peter Wienemann <wiene at debian.org> a écrit:

 
Control: tags -1 + security trixie bookworm fixed-upstream patch

Hi Ben,

thanks for your report. I am sorry about that.

On 2026-07-26 15:17:14, ben wrote:
> Package: sogo
> Version: 5.12.1-3+deb13u2
> Severity: important
> 
> 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.
I prepared a patch that hopefully fixes this:

https://salsa.debian.org/wiene/sogo/-/commits/trixie-pending

(corresponding debdiff is attached).

It integrates upstream commit [0].

Ben, do you have an opportunity to test whether this actually fixes the 
issue for you? You can find debs including the patch on [1].

@Security team: Do you think this justifies a regression update for DSA 
6366-1?

Best regards

Peter

[0] 
https://github.com/Alinto/sogo/commit/623f083cd94842766c6d9430cf3bdad8fc4d5dbc
[1] https://people.debian.org/~wiene/debs/
 



 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-sogo-maintainers/attachments/20260816/eab1bc8b/attachment.htm>