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

Re: SMTP-SASL auth failure caching.

Expand Messages
  • Keean Schupke
    Hi, I have applied the suggested changes, but I will wait to post the patch. I can write the documentation, or at least have a go at getting some initial docs
    Message 1 of 77 , Dec 2, 2007
    • 0 Attachment
      Hi,

      I have applied the suggested changes, but I will wait to post the
      patch. I can write the documentation, or at least have a go at getting
      some initial docs done, however there is little point in doing that if
      this patch isn't going to be accepted. Once that has been decided I
      will do the docs.

      I am going to retest with the new umask(077) just to make sure this
      doesn't break anything.

      Do you think I need something stronger than SHA1, I can always encrypt
      using AES with the data and key the same...

      Regards,
      Keean Schupke, Fry-IT Ltd.



      On 02/12/2007, Victor Duchovni <Victor.Duchovni@...> wrote:
      > On Sun, Dec 02, 2007 at 08:43:16AM +0000, Keean Schupke wrote:
      >
      > > --- postfix-2.4.5.orig/conf/master.cf 2007-11-22 09:25:13.000000000 +0000
      > > +++ postfix-2.4.5/conf/master.cf 2007-12-01 21:00:11.000000000 +0000
      > > @@ -24,10 +24,12 @@
      > > rewrite unix - - - - - trivial-rewrite
      > > bounce unix - - - - 0 bounce
      > > defer unix - - - - 0 bounce
      > > trace unix - - - - 0 bounce
      > > verify unix - - - - 1 verify
      > > +auth_cache unix - - - - 1 cache
      > > + -o cache_map = $smtp_sasl_auth_cache_map
      >
      > You don't need to resubmit the patch just for this, but master.cf does not
      > support whitespace in "-o" arguments. Should be:
      >
      > + -o cache_map=$smtp_sasl_auth_cache_map
      >
      > > +++ postfix-2.4.5/src/cache/cache.c 2007-12-01 21:43:07.000000000 +0000
      > > @@ -0,0 +1,237 @@
      > > +/* System library. */
      >
      > Someone needs to write a manpage for the cache(8) service. This is built
      > from comments at the top of the cache.c file. We probably also need new
      > %PARAM doc bits for proto/postconf.proto.
      >
      > > +#define CACHE_DICT_OPEN_FLAGS (DICT_FLAG_DUP_REPLACE | DICT_FLAG_SYNC_UPDATE)
      > > +
      > > + if (*var_cache_map) {
      > > + saved_mask = umask(022);
      > > + cache_map = dict_open(var_cache_map,
      > > + O_CREAT | O_RDWR,
      > > + CACHE_DICT_OPEN_FLAGS);
      > > + (void) umask(saved_mask);
      >
      > Despite the SHA-1 hash (which is important, but not sufficient) the table
      > keys enable off-line dictionary attacks on the password (if one knows the
      > nexthop and username). So the table file "mode" should be 0600, not 0644.
      > So the appropriate umask is 077, not 022.
      >
      > > + cache_map = dict_ht_open("verify", htable_create(0), myfree);
      >
      > Should this say "cache" rather than "verify"?
      >
      > > +static void smtp_sasl_make_cache_key(VSTRING *buf,const char *host,
      > > + const char *user,const char *pass)
      > > +{
      > > + VSTRING *tmp = vstring_alloc(10);
      > > +
      > > + vstring_sprintf(tmp,"%s;%s;%s",host,user,pass);
      > > + base64_encode(buf,(const char*)SHA1((unsigned char*)STR(tmp),
      > > + (unsigned long)VSTRING_LEN(tmp),0),SHA_DIGEST_LENGTH);
      > > + vstring_free(tmp);
      > > +}
      >
      > So this feature depends on OpenSSL's libcrypto. How should that be
      > handled in makedefs? (Question for Wietse I think).
      >
      > Anyway, this is probably enough for now in terms of patches, the key
      > question at this point is whether this should be adopted. Wietse?
      >
      > Is this the right problem and the right solution? Once that's settled,
      > you can post the final patch (combining both the soft_bounce and the
      > auth_cache features) to postfix-devel (this one still has a few bits
      > of soft_bounce in it).
      >
      > --
      > 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.