Password Update Synchronization Delay

[GWnbsp]

Password Update Synchronization Delay

Category: Q&A

Description

I've noticed a potential issue with password updates in the mail server. When users change their passwords, there seems to be a synchronization delay where:

1. New passwords don't take effect immediately
2. Old passwords continue to work for some time
3. Authentication state becomes inconsistent

Reproduction Steps

1. Log into the mail server
2. Change password in the account settings
3. Try to log in with the new password immediately - fails
4. Try the old password - still works
5. After some time (varies), the new password starts working

Code Investigation

Looking at crates/jmap/src/api/management/principal.rs, the cache invalidation logic appears to be conditional:

if expire_session {
    self.inner.data.http_auth_cache.retain(|_, id| id.item != account_id);
}

if expire_token {
    self.inner.data.access_tokens.remove(&account_id);
}

This might explain why the password changes aren't immediately effective across all authentication mechanisms.

Questions
Is this behavior intentional or a potential bug?
Would it be better to always clear all authentication caches when passwords are changed?
Are there any considerations about cache synchronization in distributed deployments?
Potential Solution
I have a proposed solution that involves:

Always clearing both HTTP auth cache and access tokens on password updates
Removing conditional cache invalidation
Forcing immediate re-authentication
Would love to get the community's thoughts on this approach before proceeding with a potential fix.

Environment
Latest version of Stalwart Mail Server
Deployment: Docker container
Authentication methods affected: Web interface, IMAP, SMTP
Additional Context
This behavior could potentially cause security issues in scenarios where immediate password invalidation is critical (e.g., security incidents, employee offboarding).

Looking forward to discussing this with the community and maintainers to determine the best path forward.

#944

[GWnbsp]

Proposed code changes:

// Always clear all authentication caches
self.inner
    .data
    .http_auth_cache
    .retain(|_, id| id.item != account_id);

// Force clear access tokens
self.inner.data.access_tokens.remove(&account_id);

// Update permission cache if needed
if matches!(typ, Type::Role | Type::Tenant) {
    self.inner.data.permissions.clear();
    self.inner
        .data
        .permissions_version
        .fetch_add(1, Ordering::Relaxed);
}

[mdecimus]

Hi, you should increase the expiry timeout for the session cache.

[wayneoutthere]

Quick note. I am using podman (many are probably using Docker). After changing password, then running podman restart stalwart-mail this immediately made the new password work in the login page. Just in case anyone didn't want to wait while code being updated.