Replace user authentication support in net backend / saned frontend

The user authentication handling in the net backend is insecure for at least the following reasons:

• an MD5 hash of the user's password (combined with a nonce) is sent in cleartext, which requires insufficient computational effort to reverse [CWE-916]
• passwords are stored on disk in cleartext — versus typical digest authentication, where hashes are stored instead [CWE-256]
• there is no protection against an adversary-in-the-middle, which can:
  • send the client an authentication request using an arbitrary nonce, in order to obtain a hash requiring less computational effort to reverse [CWE-760]
  • arbitrarily alter the requests from the client and/or responses from the server after authentication is successful [CWE-290]

Note that these are defects in the current implementation of user authentication. This does not go into other design issues, such as a lack of confidentiality between the client and server (with or without authentication) to protect scanned image data [CWE-359].

Revised: The user authentication should be replaced with a solution that addresses these defects (and other design issues).

Original:

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.