[sane-devel] Remove user authorization support from net backend / saned frontend?

[Steven Santos]

Here is my thinking:

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.

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.).

So, my thought is that finding a way to support this is a better direction
than just deleting it.

On Wed, Apr 6, 2022 at 12:03 AM David Ward <david.ward at gatech.edu> wrote:

> As suggested, soliciting comments on this issue:
> https://gitlab.com/sane-project/backends/-/issues/588
>
> The description is included below. Thanks!
>
> ------------------------------------------------------------------------
>
> The user authorization handling in the net backend is insecure for at
> least two reasons:
>
>   * it uses the MD5 cipher, which is cryptographically broken
>   * it provides no protection against a man-in-the-middle attack
>
> I believe this handling in its current form should simply be removed. In
> an environment where user authorization is necessary, system
> administrators need to find their own way to support this that meets
> their requirements. Using an insecure solution built into SANE should
> not be provided as an option; note that operating on a private network
> does not really diminish the issues with it.
>
> The direct way to achieve this, without breaking the current protocol,
> is for sanei_authorize() to simply return SANE_STATUS_GOOD. (Code that
> is no longer used as a result can be removed, and documentation can be
> updated.) This change should of course be very apparent during upgrades:
> I would suggest that authorization unconditionally fail if a
> <backend>.users file still exists, requiring the system administrator to
> understand this change and manually remove the file.
>
> While it remains possible to implement user authorization with stronger
> ciphers and in a way that affords some protection against MITM attacks,
> this would necessarily change both the protocol and the file format, so
> it would still seem best to remove the existing handling.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20220406/a8acc5c6/attachment.htm>