Hi
Not sure whether this is the correct list to ask ... if it's not please direct me to the correct one.
Is it possible on to log a bit more detail when auth failure occurs when using saslauthd?
saslauthd[2119]: do_auth : auth failure: [user=DELETED] [service=smtp] [realm=DELETED] [mech=pam] [reason=PAM auth error]
What I want is the IP address and if possible the incorrect password (just to see how far they are off). Is this possible?
thanks Jobst
On 04/25/2017 07:00 PM, Jobst Schmalenbach wrote:
What I want is the IP address and if possible the incorrect password (just to see how far they are off). Is this possible?
I hope not. That's a terrible idea. Every time a user fat-fingers their password, your plain-text logs have a copy of their almost-correct password.
On Tue, Apr 25, 2017 at 07:14:56PM -0700, Gordon Messmer (gordon.messmer@gmail.com) wrote:
On 04/25/2017 07:00 PM, Jobst Schmalenbach wrote:
What I want is the IP address and if possible the incorrect password (just to see how far they are off). Is this possible?
I hope not. That's a terrible idea. Every time a user fat-fingers their password, your plain-text logs have a copy of their almost-correct password.
As always there are tradeoffs ... I have a reasonable strict password policy, so by looking at the failed passwords I can see how far the tries are off the real thing, so it actually is a good thing for me. Also I learn which passwords are used for cracking, which again is a good thing. As for the logged passwords - this is a non user server, only two people have access ... so reading the logs is difficult for imap/sendmail users in the company ...
J
On Wed, 26 Apr 2017, Jobst Schmalenbach wrote:
On Tue, Apr 25, 2017 at 07:14:56PM -0700, Gordon Messmer (gordon.messmer@gmail.com) wrote:
On 04/25/2017 07:00 PM, Jobst Schmalenbach wrote:
What I want is the IP address and if possible the incorrect password (just to see how far they are off). Is this possible?
I hope not. That's a terrible idea. Every time a user fat-fingers their password, your plain-text logs have a copy of their almost-correct password.
As always there are tradeoffs ... I have a reasonable strict password policy, so by looking at the failed passwords I can see how far the tries are off the real thing, so it actually is a good thing for me. Also I learn which passwords are used for cracking, which again is a good thing. As for the logged passwords - this is a non user server, only two people have access ... so reading the logs is difficult for imap/sendmail users in the company ...
Sorry, listen to Gordon; this is a terrible idea.
You accept a certain amount of password leakage into log files as hard to avoid (a user puts their password into a username field without noticing), but deliberately logging typoed passwords, or indeed valid passwords but for the wrong account into a log file, so you can keep an eye on what's being used is a step beyond simple bad practice.
If you have a strict password policy, then you should have mechanisms in place to enforce it, but not human ones.
jh
On 4/25/2017 7:00 PM, Jobst Schmalenbach wrote:
Is it possible on to log a bit more detail when auth failure occurs when using saslauthd?
saslauthd[2119]: do_auth : auth failure: [user=DELETED] [service=smtp] [realm=DELETED] [mech=pam] [reason=PAM auth error]
What I want is the IP address and if possible the incorrect password (just to see how far they are off). Is this possible?
what protocol are these users connecting with thats using saslauthd ? http or smtp or imap or what? I'm pretty sure that by the time you've gotten down to the SASL layer, saslauthd has no clue what iP address the client request originated from, so logging the IP of the failed request had best be done at a higher layer.
On Tue, Apr 25, 2017 at 07:15:43PM -0700, John R Pierce (pierce@hogranch.com) wrote:
On 4/25/2017 7:00 PM, Jobst Schmalenbach wrote:
snip
client request originated from, so logging the IP of the failed request had best be done at a higher layer.
Good answer, makes sense. As for the higher layer used - can be either sendmail or imaps as both use the saslauth. Just need to find a way to "connect" the sasl request to the caller that issued the sasl request ...
thx Jobst
On 4/25/2017 10:19 PM, Jobst Schmalenbach wrote:
Good answer, makes sense. As for the higher layer used - can be either sendmail or imaps as both use the saslauth. Just need to find a way to "connect" the sasl request to the caller that issued the sasl request ...
doesn't sendmail and your imap demon log failed authentication requests ?