log failed plaintext password for specific user only
Hi,
We are logging failed authentication attempts, with the attempted password as auth_verbose_passwords=sha1
The question: is it possible to configure auth_verbose_passwords=plain for a specific user only? Turning it on globally would be too much sensitive information for the purpose.
Reason:
We are currently observing a high number of failed authentications for a specific user, coming from *many* diffirent IPs across the globe, with most IPs only trying once or twice, making this difficult to block. The number of failed authentications cause this account to regularly become blocked in AD.
We would like to know if they are trying older actual passwords from the user, or if it's just dictionary attack.
Thanks!
On 23/03/2022 11:47 mj lists@merit.unu.edu wrote:
Hi,
We are logging failed authentication attempts, with the attempted password as auth_verbose_passwords=sha1
The question: is it possible to configure auth_verbose_passwords=plain for a specific user only? Turning it on globally would be too much sensitive information for the purpose.
Reason:
We are currently observing a high number of failed authentications for a specific user, coming from *many* diffirent IPs across the globe, with most IPs only trying once or twice, making this difficult to block. The number of failed authentications cause this account to regularly become blocked in AD.
We would like to know if they are trying older actual passwords from the user, or if it's just dictionary attack.
Thanks!
Well, is the sha1 value same every time? If it is, then they are trying same password each time.
Aki
Op 23-03-2022 om 11:11 schreef Aki Tuomi:
Well, is the sha1 value same every time? If it is, then they are trying same password each time.
Aki
Yes, understood. :-)
The SHA1 changes, but each SHA1 is tried multiple times.
The question is: can we find out, just for this specific user, WHAT the attempted passwords are?
On 23/03/2022 12:18 mj lists@merit.unu.edu wrote:
Op 23-03-2022 om 11:11 schreef Aki Tuomi:
Well, is the sha1 value same every time? If it is, then they are trying same password each time.
Aki
Yes, understood. :-)
The SHA1 changes, but each SHA1 is tried multiple times.
The question is: can we find out, just for this specific user, WHAT the attempted passwords are?
- Try hashing possible password candidates and compare
- Temporarily log everyone's passwords and then sanitize logs after you're done.
No way to enable that option for a single user.
Aki
On 23/03/2022 19.30, mj wrote:
Op 23-03-2022 om 12:29 schreef Aki Tuomi:
- Try hashing possible password candidates and compare
- Temporarily log everyone's passwords and then sanitize logs after you're done.
No way to enable that option for a single user.
While there is no way to enable that option for a single user, setting the following:
auth_debug = yes auth_debug_passwords = yes
Will enable it for all users. Possibly your concern is that you don't want to see legitimate users' passwords? In which case, you can rest assured that you only see the FAILED passwords for all users, not the CORRECT ones.
If you decide this is something you want to do, then you can find the culprits by grepping for "MD5" in the dovecot log, and then revert your configuration when you've collected enough info.
P.
On Wed, 23 Mar 2022, mj wrote:
We are currently observing a high number of failed authentications for a specific user, coming from *many* diffirent IPs across the globe, with most IPs only trying once or twice, making this difficult to block. The number of failed authentications cause this account to regularly become blocked in AD.
We would like to know if they are trying older actual passwords from the user, or if it's just dictionary attack.
Rather than messing around with dovecot configuration, I think you can process trace (strace?) the auth process and intercept read/write buffers to a few key low numbered sockets and extract username/plaintext passwords from them, filtering out those you don't need.
Sort of hacky, buy avoid messing about with dovecot, or even restarting it.
You can possibly extend this by taking the auth information, and triggering a block if you recongize it as a dictionary attack, but it may be too late as your AD will see it by that point.
Joseph Tam jtam.home@gmail.com
participants (4)
-
Aki Tuomi
-
Joseph Tam
-
mj
-
Plutocrat