<div dir="ltr">Here is my thinking:<div><br></div><div>With the recent development of eSCL now being supported natively on Windows, I think we will see SANE used as an integral part of central scanning solutions more and more. I know at least one effort is underway to create an eSCL "reflector" to make this process easier.</div><div><br></div><div>With these developments, I think in a short period of time, many people will want some form of authentication baked in, especially if it can be used with SAMBA or other directory and policy framework (i.e. show this user or this machine this scanner based on these policies. Set this default scanner based on these policies. Set the scan directory to this based on these policies. You get the idea.). </div><div><br></div><div>So, my thought is that finding a way to support this is a better direction than just deleting it. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 6, 2022 at 12:03 AM David Ward <<a href="mailto:david.ward@gatech.edu">david.ward@gatech.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As suggested, soliciting comments on this issue:<br>
<a href="https://gitlab.com/sane-project/backends/-/issues/588" rel="noreferrer" target="_blank">https://gitlab.com/sane-project/backends/-/issues/588</a><br>
<br>
The description is included below. Thanks!<br>
<br>
------------------------------------------------------------------------<br>
<br>
The user authorization handling in the net backend is insecure for at <br>
least two reasons:<br>
<br>
* it uses the MD5 cipher, which is cryptographically broken<br>
* it provides no protection against a man-in-the-middle attack<br>
<br>
I believe this handling in its current form should simply be removed. In <br>
an environment where user authorization is necessary, system <br>
administrators need to find their own way to support this that meets <br>
their requirements. Using an insecure solution built into SANE should <br>
not be provided as an option; note that operating on a private network <br>
does not really diminish the issues with it.<br>
<br>
The direct way to achieve this, without breaking the current protocol, <br>
is for sanei_authorize() to simply return SANE_STATUS_GOOD. (Code that <br>
is no longer used as a result can be removed, and documentation can be <br>
updated.) This change should of course be very apparent during upgrades: <br>
I would suggest that authorization unconditionally fail if a <br>
<backend>.users file still exists, requiring the system administrator to <br>
understand this change and manually remove the file.<br>
<br>
While it remains possible to implement user authorization with stronger <br>
ciphers and in a way that affords some protection against MITM attacks, <br>
this would necessarily change both the protocol and the file format, so <br>
it would still seem best to remove the existing handling.<br>
<br>
</blockquote></div>