Attackers can crash the wallet via the gRPC service

[SWvheerden]

The BasicAuthCredentials::validate method compares the username and
password for the service (specified in the service's configuration file) with the
BasicAuthCredentials parsed from the network. To do so it uses
Argon2::default().verify_password which takes a plain text password string and
a hash of the expected password. Unfortunately, the wallet implementation
inverts these parameters and instead of passing the client supplied password to
the function, it uses the expected password and performs PasswordHash::parse on
the attacker controlled input.

The way argon2 hashes are designed, allows users to store the hashing
parameters (salt, memory usage, CPU usage, etc) in the hash itself for future
updates and flexibility. This means that PasswordHash::parse does more than
parsing a hashed password; it sets the parameters (including algorithm, memory
used, and time spent) that will be used to verify the password, therefore the
parsed data should come from a trusted source, for instance a database or a local
configuration file, as is the case with the wallet.

Because the parameters are controlled by the attacker, it is possible for them to
crash the program or use an arbitrary amount of resources on the victim system.
This issue could also lead to complete authentication bypass due to the current
design: an attacker can supply a hash with parameters that are less secure than
the default ones defined by the argon2 crate. For example the argon2 specification
defines the minimum hash byte length to be 4 bytes, so an attacker could send a
hash with these parameters and they would have to only brute-force 2^32
passwords to find a collision with the actual password.
This situation is rendered several orders of magnitude harder due to the better
defaults that the argon2 crate defines for the minimum hash size, which is 10
bytes, making the attack unfeasible.
The likelihood of this issue is deemed low as it is expected that most
configurations will keep wallets and node running on the same host.

If the existing authentication method is retained, the client must provide a
password for the server to hash and compare with the stored hash of the expected
password.

[SWvheerden]

This will be partly address for most use cases by: ##5930