<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <div class="moz-cite-prefix">On 12.08.2021 18:36, Adrian Georgescu
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2728B611-4B69-46F1-A116-734421E29E4B@ag-projects.com">
      <div class="">The auth_db module has some dramatic changes which
        are either undocumented or not backwards compatible and is
        unclear how to handle this.</div>
      <div class=""><br class="">
      </div>
      <div class=""><a
href="https://opensips.org/docs/modules/3.1.x/auth_db.html#param_password_column_2"
          class="" moz-do-not-send="true">https://opensips.org/docs/modules/3.1.x/auth_db.html#param_password_column_2</a></div>
    </blockquote>
    <p><font face="monospace">Hi Adrian,</font></p>
    <p><font face="monospace">Indeed, with the addition of RFC 8760
        support (support for SHA-256 and SHA-512-256 auth algorithms),
        me and Maksym Sobolyev decided to try and remove the "ha1b"
        feature, originally designed to accommodate some broken SIP UAs
        who cannot follow the basic SIP authentication spec.  The
        feature had been in there since the very beginnings, and we were
        not sure if anyone is really benefiting from it anymore
        nowadays.<br>
      </font></p>
    <p><font face="monospace">A strong reason for removing "ha1b" was
        the sheer number of hashes to be stored per subscriber.  Since
        we now have 3 algorithms (MD5, SHA-256, SHA-512-256), there are
        3 hash-columns to store.  With the "ha1b" feature, there would
        be 2 x 3 = 6 hashes in total to store, per user.  So you can see
        where this is going: <i>"Can we get away with dropping ha1b and
          storing half the data per user?"</i> ... was the big question.</font><br>
      <font face="monospace"><font face="monospace"><br>
          Still, we agreed that if there is still enough traction for
          the "ha1b" feature from the community, we can easily re-add
          the ha1b logic and 3 more columns to the table and backport
          everything to 3.2.  It's a trivial task, frankly.<br>
        </font></font></p>
    <p><font face="monospace"><font face="monospace">The big question
          is: on your platform(s), can you control the software in all
          SIP UAs that incorrectly include "realm" information in the
          "username" field (which should really be just the <b>user</b><b>'s
          </b><b>name</b>!) and fix the problem on the phone side?<br>
        </font></font></p>
    <p><font face="monospace"><font face="monospace">PS: I noticed the
          3.2 migration page is missing any info on ha1b.  Will get it
          fixed soon, depending on the outcome of the discussion.<br>
        </font></font></p>
    <p><font face="monospace"><font face="monospace">Best Regards,<br>
        </font></font></p>
    <pre class="moz-signature" cols="72">-- 
Liviu Chircu
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/liviuchircu">www.twitter.com/liviuchircu</a> | <a class="moz-txt-link-abbreviated" href="http://www.opensips-solutions.com">www.opensips-solutions.com</a>
OpenSIPS Summit 2021 Distributed | <a class="moz-txt-link-abbreviated" href="http://www.opensips.org/events">www.opensips.org/events</a></pre>
  </body>
</html>