Re: dovecot config for 1500 simultaneous connection
Rajesh M wrote:
i wish to improve the performance further by caching the logins. current the same is kept disable because when user's change passwords then they are not able to immediately login with the new password for some time. How to solve this issue.
Dovecot shouldn't be doing that. According to
https://wiki2.dovecot.org/Authentication/Caching
Data is used from the cache if it's not expired (auth_cache_ttl setting)
- If authentication fails this time, but it didn't fail
last time, it's assumed that the password has changed
and a database lookup is done.
As I read it, an authentication failure will cause an update of cache credentials. The problem I encountered is the converse -- a user changes their password, but forgets to update their mail reader's or web browser's stored password, which continues to work until the TTL expires.
Another related security situation I've encountered is when a fraudster has phished a user's password. A user/admin changes the password, but forgets to invalidate dovecot's cached entry, allowing the fraudster contunuing access to the mail account until the TTL expires or user logs in with new credentials. I've been burnt by this one.
Joseph Tam jtam.home@gmail.com
On Feb 14, 2017, at 5:50 PM, Joseph Tam jtam.home@gmail.com wrote:
Another related security situation I've encountered is when a fraudster has phished a user's password. A user/admin changes the password, but forgets to invalidate dovecot's cached entry, allowing the fraudster contunuing access to the mail account until the TTL expires or user logs in with new credentials. I've been burnt by this one.
I’m no expert, but should the code that updates the password hash in the database also immediately try to log into dovecot for the user with a fake password?
Authentication should fail but the cache would be updated?
Or, doesn’t Dovecot expire the cache’d entry on failed authentication?
On Tue, 14 Feb 2017, KT Walrus wrote:
Another related security situation I've encountered is when a fraudster has phished a user's password. A user/admin changes the password, but forgets to invalidate dovecot's cached entry, allowing the fraudster contunuing access to the mail account until the TTL expires or user logs in with new credentials. I've been burnt by this one.
I?m no expert, but should the code that updates the password hash in the database also immediately try to log into dovecot for the user with a fake password?
Authentication should fail but the cache would be updated?
I guess you could write a hook for that, but that's not a scalable solution if your auth database is used by many different services that do their own credential caching.
I do this manually i.e. if I have to invalidate mail system cache, I log in with wrong credentials.
Or, doesn?t Dovecot expire the cache?d entry on failed authentication?
Dovecot does have a auth_cache_negative_ttl setting.
I think the best proactive approach is to keep auth_cache_ttl modest (a few minutes) rather than hours or days.
Joseph Tam jtam.home@gmail.com
participants (2)
-
Joseph Tam
-
KT Walrus