Re: Authentication caching and password changes
On 05/03/2025 5:31 AM MDT Diego Alvarez via dovecot <dovecot@dovecot.org> wrote:
In Dovecot docs (https://doc.dovecot.org/2.3/configuration_manual/ authentication/caching/) we see:
- User logs in with password Y. The cached password X doesn’t match Y and the previous authentication was unsuccessful, so Dovecot doesn’t bother doing another backend passdb lookup (until cache TTL expires). The login fails.
Anyone knows why they chose this design ? Why not simply do a passdb lookup instead of waiting for cache TTL to expire ?
You didn't copy and paste the whole context of this documentation comment:
https://doc.dovecot.org/2.4.1/core/config/auth/caching.html#early-change
When looking at the full context, this is a situation where a user is either using a password that isn't yet valid (= a bad password, so it's a valid denial), or the user did change their password but the Dovecot system doesn't see the change for some reason (= server/admin issue).
In the above situation, doing a passdb lookup without waiting for cache TTL expiration is simply the same situation as not having a negative cache at all. So either don't use the negative cache or fix the password sync (and if you can't fix the authentication sync delay, you can't use a negative cache).
An unlikely situation is that the user is using the wrong password originally, and then changes their password to this wrong password. You can always reduce the negative cache TTL if you want to catch this rare situation, at the cost of a lower cache hit rate more generally.
michael
I understand all this, I just wanted to know why not fall-back to a passdb lookup anyways ? Is it for performance reasons ?
I mean, doing the passdb lookup could eliminate this rare situation that a legitimate use might find themselves in.
Thanks!
--------------------Original message--------------------
From: Michael Slusarz via dovecot <dovecot@dovecot.org>
Sent: Sunday, May 4, 2025 9:35
To: Diego Alvarez <diego@emailgurus.com>; Diego Alvarez via dovecot
<dovecot@dovecot.org>
Subject: Re: Authentication caching and password changes
> On 05/03/2025 5:31 AM MDT Diego Alvarez via dovecot <dovecot@dovecot.org> wrote:
>
> In Dovecot docs (https://doc.dovecot.org/2.3/configuration_manual/
> authentication/caching/) we see:
>
> 1. User logs in with password Y. The cached password X doesn’t match Y and the
> previous authentication was unsuccessful, so Dovecot doesn’t bother doing
> another backend passdb lookup (until cache TTL expires). The login fails.
>
> Anyone knows why they chose this design ? Why not simply do a passdb lookup
> instead of waiting for cache TTL to expire ?
You didn't copy and paste the whole context of this documentation comment:
https://doc.dovecot.org/2.4.1/core/config/auth/caching.html#early-change
When looking at the full context, this is a situation where a user is either using a password that isn't yet valid (= a bad password, so it's a valid denial), or the user did change their password but the Dovecot system doesn't see the change for some reason (= server/admin issue).
In the above situation, doing a passdb lookup without waiting for cache TTL expiration is simply the same situation as not having a negative cache at all. So either don't use the negative cache or fix the password sync (and if you can't fix the authentication sync delay, you can't use a negative cache).
An unlikely situation is that the user is using the wrong password originally, and then changes their password to this wrong password. You can always reduce the negative cache TTL if you want to catch this rare situation, at the cost of a lower cache hit rate more generally.
michael
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-leave@dovecot.orgI understand all this, I just wanted to know why not fall-back to a passdb lookup anyways ? Is it for performance reasons ?
I mean, doing the passdb lookup could eliminate this rare situation that a legitimate use might find themselves in.
Thanks!
--------------------Original message--------------------
From: Michael Slusarz via dovecot <dovecot@dovecot.org>
Sent: Sunday, May 4, 2025 9:35
To: Diego Alvarez <diego@emailgurus.com>; Diego Alvarez via dovecot
<dovecot@dovecot.org>
Subject: Re: Authentication caching and password changes
> On 05/03/2025 5:31 AM MDT Diego Alvarez via dovecot
<dovecot@dovecot.org> wrote:
>
> In Dovecot docs (https://doc.dovecot.org/2.3/configuration_manual/
> authentication/caching/) we see:
>
> 1. User logs in with password Y. The cached password X doesn’t
match Y and the
> previous authentication was unsuccessful, so Dovecot doesn’t
bother doing
> another backend passdb lookup (until cache TTL expires). The
login fails.
>
> Anyone knows why they chose this design ? Why not simply do a
passdb lookup
> instead of waiting for cache TTL to expire ?
You didn't copy and paste the whole context of this documentation
comment:
https://doc.dovecot.org/2.4.1/core/config/auth/caching.html#early-
change
When looking at the full context, this is a situation where a user is
either using a password that isn't yet valid (= a bad password, so
it's a valid denial), or the user did change their password but the
Dovecot system doesn't see the change for some reason (= server/admin
issue).
In the above situation, doing a passdb lookup without waiting for
cache TTL expiration is simply the same situation as not having a
negative cache at all. So either don't use the negative cache or fix
the password sync (and if you can't fix the authentication sync
delay, you can't use a negative cache).
An unlikely situation is that the user is using the wrong password
originally, and then changes their password to this wrong password.
You can always reduce the negative cache TTL if you want to catch
this rare situation, at the cost of a lower cache hit rate more
generally.
michael
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-leave@dovecot.org
participants (2)
-
Diego Alvarez
-
Michael Slusarz