Loading ...
Sorry, an error occurred while loading the content.

Re: SMTP-SASL auth failure caching.

Expand Messages
  • Keean Schupke
    Okay, a question about the verify service. If I do this, it seems that there will be all sorts of strange interactions with the normal verify service. You may
    Message 1 of 77 , Nov 30, 2007
    • 0 Attachment
      Okay, a question about the verify service.

      If I do this, it seems that there will be all sorts of strange
      interactions with the normal verify service. You may have conflicting
      goals...

      for example, the cache time for password expiry would need to be
      around 90days, but I don't think you want verify to cache delivery
      addresses for that long?

      Is it not going to be confusing to have the same config variables
      (cache-timeout etc...) affecting two completely different parts of the
      system?

      Regards,
      Keean Schupke, Fry-IT Ltd.

      On 30/11/2007, Victor Duchovni <Victor.Duchovni@...> wrote:
      > On Fri, Nov 30, 2007 at 06:10:22PM +0000, Keean Schupke wrote:
      >
      > > > What happened to the suggestion of using the "verify" service? The patch
      > > > as implemented potentially has multiple processes writing the table,
      > > > we don't support this mode of operation. You seem to be working around
      > > > that by turning off both the idle timeout and the max use counter, and
      > > > presumably using a transport with a process limit of 1, so you have just
      > > > one delivery agent running "forever", but this is not a good idea.
      > > >
      > >
      > > Nope, it uses locking on the table,and the smtp process terminates
      > > just fine.
      >
      > There has not been much stress-testing of multi-writer Berkeley DB use
      > in Postfix, this is not recommended. It may work for you, but Postfix
      > only supports single-writer use. If the patch is to be adopted, it likely
      > needs to switch to a single writer model.
      >
      > There is already a suitable single writer in place, namely verify,
      > which already caches delivery status information, so all you have to do
      > is cache auth failures.
      >
      > > As for a whole other process to do this... seems a bit like using a
      > > sledgehammer to crack a nut. Besides, the SMTP process would still
      > > have to go through the SASL authentication, so we would introduce a
      > > whole extra authentication attempt for mails the successfully
      > > authenticate.
      >
      > You did not understand me correctly. No verification probe is sent, you
      > cache status for real messages, not probes, with new code that updates
      > the verify cache with AUTH failure status information, where the lookup
      > key is "nexthop/user/pass" dependent.
      >
      > > The code here is strongly based on that in verify.c but it makes more
      > > sense to me to do the caching where you actually use the SASL
      > > authentication.
      >
      > Yes, of course, but use verify(8) as you database, not a new database
      > accessed directly from smtp(8).
      >
      > > > Don't store the unhashed password in this table. You are leaking
      > > > sensitive data. Use a pre-image attack resistant hash function. SHA-1
      > > > should do. You can get SHA-1 from OpenSSL's libcrypto.
      > >
      > > Are you sure its necessary to do that? The passwords are in plain text
      > > in the sasl_passwd map file? Perhaps I could tweek the file
      > > permissions a bit.
      >
      > This violates security principles by leaking passwords into additional
      > files, and yes the permissions would need to be right, but is best
      > practice to avoid doing that. I prefer to avoid fine-tuning approaches
      > that are not best-practice.
      >
      > > So, TODO
      > > 1) fix accidental c++ comments.
      > > 2) look at changing the file permissions on the db file.
      >
      > No, look to use verify(8) as your database, with hashed lookup keys.
      >
      > > Questions:
      > > 1) Should I get rid of the in-memory hashtable option (and lose the
      > > post_init function, as it is only used in that case).
      >
      > Verify already supports both options. Use the verify_clnt_update()
      > and verify_clnt_query() interfaces.
      >
      > --
      > Viktor.
      >
      > Disclaimer: off-list followups get on-list replies or get ignored.
      > Please do not ignore the "Reply-To" header.
      >
      > To unsubscribe from the postfix-users list, visit
      > http://www.postfix.org/lists.html or click the link below:
      > <mailto:majordomo@...?body=unsubscribe%20postfix-users>
      >
      > If my response solves your problem, the best way to thank me is to not
      > send an "it worked, thanks" follow-up. If you must respond, please put
      > "It worked, thanks" in the "Subject" so I can delete these quickly.
      >
    • Victor Duchovni
      ... Yes, that s the idea. Also CPUs have historically gotten faster year-by-year. Moore s law is looking a bit more feeble lately, we are getting the
      Message 77 of 77 , Dec 4, 2007
      • 0 Attachment
        On Tue, Dec 04, 2007 at 09:04:19PM +0000, Keean Schupke wrote:

        > How about we make the key iterations a config variable, and let the
        > user make the balance between speed and security?

        Yes, that's the idea. Also CPUs have historically gotten faster
        year-by-year. Moore's law is looking a bit more feeble lately, we are
        getting the feature-size scaling (more cores per die) but the clock-rate
        seems to have stalled for a bit.

        Finally, the table will not be in the chroot jail, proxymap/proxywrite
        won't be chrooted even when other processes are. So some "postfix"
        processes will have less access to the table than others.

        Anyway this is all coverging to something sensible. The question for
        the smtp(8) side is whether making the password hash the key is the
        best choice. We could make "nexthop user" the key, and stick the
        password hash in the result. That way deletion will actually work.

        Otherwise, new passwords will be set before the fail map entry expires,
        and the table entry becomes orphaned.

        If this change is made, the entry is valid only if not expired, and the
        password hash matches. Looks a lot an /etc/shadow entry with a user name
        and PKCS#5 v2 password hash, only it perversely records invalid passwords!

        --
        Viktor.

        Disclaimer: off-list followups get on-list replies or get ignored.
        Please do not ignore the "Reply-To" header.

        To unsubscribe from the postfix-users list, visit
        http://www.postfix.org/lists.html or click the link below:
        <mailto:majordomo@...?body=unsubscribe%20postfix-users>

        If my response solves your problem, the best way to thank me is to not
        send an "it worked, thanks" follow-up. If you must respond, please put
        "It worked, thanks" in the "Subject" so I can delete these quickly.
      Your message has been successfully submitted and would be delivered to recipients shortly.