View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0006151SOGoBackend Generalpublic2025-10-08 14:592025-10-15 15:48
Reporterthe2nd Assigned Toqhivert  
PrioritynormalSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Platformamd64OSUbuntuOS Version22.04
Product Versionnightly master 
Summary0006151: Dont reject authentication if password_hash != cached_password_hash
Description

Hello,

i encountered the following issue. When authenticating sogo against OTPme (https://github.com/the2nd/otpme) via ldap with different token types (static password and OTP), the authentication with the second token fails with the following error:

<0x0x55b150d6a790[SOGoDAVAuthenticator]> tried wrong password for user 'username'!

The problem seems to be the following:

  1. a request is sent to sogo by DAVx5 with a static password
  2. sogo verifies the password against ldap
  3. on success sogo caches the password (hash)
  4. a request is sent to sogo by the sogo webinterface with an OTP as password
  5. sogo compares the OTP hash with the cached password hash and fails with "tried wrong password " error
  6. no ldap request is done

As a workaround i set SOGoCacheCleanupInterval = 1; which fixes the issue but puts a lot more load on the ldap server.

So i would like to ask, if it would be possible to add a configuration parameter to control the behavior of sogo in case the request password (hash) does not match the cached password hash. Failing with "tried wrong password " makes it impossible to use sogo with different token types. So adding an option to change the behavior to "try ldap auth if password_hash != cached_hash" would fix the issue.

I think the same error should appear, if a user tries to login shortly after changing its password, while the old password is still cached. But i have not tested it.

Regards
the2nd

TagsNo tags attached.

Activities

qhivert

qhivert

2025-10-15 14:48

administrator   ~0018356

Hello,
How does otp.me work exactly?
If I understand correctly, it sets in your ldap server one static password and one or several OTP in the userPassword field? In that case, how long the otp is valid?
Because once a user is logged in, the password will be encrypted in the database and cache and give the browser the key to decrypt it. That's way, for each request, sogo can get the password in plain for its imap request. So if you're otp last less than the user session, you will get imap error. Isn't that your case?
the2nd

the2nd

2025-10-15 15:48

reporter   ~0018359

Hello,

no, I don’t think that’s the problem.

OTPme uses python-ldaptor to implement its own LDAP server. The passwords/OTPs are not stored in LDAP but verified during LDAP authentication. The OTP is a session-based OTP that comes from the OTPme SSO login page.

The usual steps are:

  • The user logs in to OTPme using an OTP and a PIN.
  • An OTPme session is created on the server, and the browser displays an SSO portal with links/buttons to log in to different web applications (e.g., SOGo).
  • When the user clicks the SOGo button, a new session-OTP is generated from the existing OTPme session.
  • The session-OTP is passed to the SOGo login page via JavaScript. The JavaScript part simply imitates a normal user login (it enters the username and session-OTP, then submits the login form).

This session-OTP is then used by SOGo/IMAP to authenticate against otpme-ldapd. The session-OTP remains valid as long as the user is logged into the OTPme SSO portal.

This works fine without any issues.

The problem is that while the user is logged into SOGo webmail with the session-OTP, there might be a second request (e.g., from DAVx5 on a mobile phone) using a static password. If this request is sent to otpme-ldapd by SOGo/IMAP, it would normally be verified successfully. However, it seems that SOGo compares the static password from the new DAVx5 request against the cached session-OTP from the SOGo webmail login - which obviously fails - and then rejects the request.

If I set

SOGoCacheCleanupInterval = 1; as described here: https://www.sogo.nu/support/faq/sogo-caches-my-password.html

the problem disappears. But since the password is no longer cached, every single request (e.g., clicking an email in webmail) triggers an authentication request to otpme-ldapd, resulting in higher load.

I hope this clarifies things a bit.

Issue History

Date Modified Username Field Change
2025-10-08 14:59 the2nd New Issue
2025-10-15 14:48 qhivert Note Added: 0018356
2025-10-15 14:48 qhivert Assigned To => qhivert
2025-10-15 14:48 qhivert Status new => feedback
2025-10-15 15:48 the2nd Note Added: 0018359
2025-10-15 15:48 the2nd Status feedback => assigned