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

[Salvatore Bonaccorso]

Hi Peter,

On Sat, Aug 15, 2026 at 01:30:01PM +0200, Peter Wienemann wrote:
> 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?

Let's fix this via a regression update to the DSA. Can you plese
upload to security-master?

Regards,
Salvatore