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

Re: SMTP-SASL auth failure caching.

Expand Messages
  • Keean Schupke
    Hi, Comments inline: ... This all looks good to me... will do! ... Okay, will fix too. ... The alldig(buf) check makes sure there is no trailing junk, but
    Message 1 of 77 , Dec 1, 2007
    • 0 Attachment
      Hi,

      Comments inline:

      On 01/12/2007, Victor Duchovni <Victor.Duchovni@...> wrote:
      >
      > Given that there is also a "var_cache_service", to allow different
      > clients to choose split caches, this seems reasonable. Given the generic
      > nature of the cache, the parameter that controls the cache database name
      > is mis-named.
      >
      > #define VAR_CACHE_NAME "smtp_sasl_auth_cache_name"
      >
      > It should be something like "cache_map" (along the lines of
      > address_verify_map). And then in master.cf something along the lines of:
      >
      > master.cf:
      > auth_cache unix ... cache
      > -o cache_map=$smtp_auth_cache_map
      >
      > main.cf:
      > # Optional:
      > # smtp_auth_cache_map = btree:/var/lib/postfix/smtp_auth_cache
      >
      > Minor drawback is that the "smtp_auth_cache_map" parameter won't be
      > known to "postconf".

      This all looks good to me... will do!

      >
      > Violation of Postfix indentation style... :-) The opening brace of a
      > function should be its own line... Variable declarations are followed
      > by a blank line and then the code.

      Okay, will fix too.

      >
      > > +static int smtp_sasl_parse_cache_value(char *buf, long *timestamp,
      > > + char **respdsn, char **respstr) {
      > > + if ((*respdsn = split_at(buf,':')) != 0
      > > + && (*respstr = split_at(*respdsn,':')) != 0 && alldig(buf)) {
      > > + *timestamp = atol(buf);
      > > + return (0);
      > > + }
      > > + msg_warn("bad smtp_sasl_auth_cache_map entry: %.100s", buf);
      > > + return (-1);
      > > +}
      >
      > May want to validate the DSN string here, and perhaps use strtol()
      > or sscanf() instead of atol() to check for trailing junk, ...

      The alldig(buf) check makes sure there is no trailing junk, but proper
      validation would be better.

      > > + smtp_sasl_make_cache_key(buf, session->host,
      > > session->sasl_username, session->sasl_passwd);
      > > + if (cache_client_query(STR(buf), get_buf) == 0) {
      > > + if (vstring_strcpy(put_buf,STR(get_buf))
      > > + && smtp_sasl_parse_cache_value(STR(get_buf),×tamp,
      > > + &cached_respdsn,&cached_respstr) == 0
      > > + && timestamp + var_smtp_sasl_auth_cache_time > now) {
      > > + dsb_update(why, cached_respdsn, DSB_DEF_ACTION, DSB_MTYPE_DNS,
      > > + session->host, var_procname, cached_respstr,
      > > + "SASL [CACHED] authentication failed; server %s : %s",
      > > + session->namaddr, STR(put_buf));
      > > + status = -1;
      > > + } else {
      > > + /* timeout or corrupt cache entry */
      > > + cache_client_delete(STR(buf));
      > > + }
      > > + }
      > > + vstring_free(put_buf);
      > > + vstring_free(get_buf);
      > > + vstring_free(buf);
      > > + return (status);
      > > +}
      >
      > With SASL soft failures, the DSN should perhaps be downgraded from 5XX
      > to 4XX here? And validated somewhere to be either a 5XX or 4XX?
      >

      The downgrading happens automatically, the cache_update happens after
      the resp->dsn has been changed by the soft_bounce patch. So no need to
      alter things on the query side.

      >
      > Here, you should be more selective (code == 535) about which SASL auth
      > failures are cached as "bad password" errors. While soft-fail on AUTH
      > failure is reason agnostic, blocking all deliveries for the same password
      > requires more care.
      >

      No problem with that... will do

      Regards,
      Keean Schupke, Fry-IT Ltd.
    • 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.