<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On 12 Aug 2021, at 13:04, Liviu Chircu <<a href="mailto:liviu@opensips.org" class="">liviu@opensips.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252" class="">
<div class="">
<div class="moz-cite-prefix">On 12.08.2021 18:36, Adrian Georgescu
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:2728B611-4B69-46F1-A116-734421E29E4B@ag-projects.com" class="">
<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 class=""><font face="monospace" class="">Hi Adrian,</font></p><p class=""><font face="monospace" class="">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 class="">
</font></p><p class=""><font face="monospace" class="">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 class="">"Can we get away with dropping ha1b and
storing half the data per user?"</i> ... was the big question.</font><br class="">
<font face="monospace" class=""><font face="monospace" class=""><br class="">
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 class="">
</font></font></p><p class=""><font face="monospace" class=""></font></p></div></div></blockquote><div>Hi Liviu,</div><div><br class=""></div>I would very much like to see this feature ported back to 3.2 please!</div><div><br class=""></div><div>Regards,</div><div>Adrian</div><div> <br class=""><div><br class=""></div></div><br class=""></body></html>