Ensure custom configured password hashing module is loaded or exists

[Ayanda-D]

If a custom password hashing module is configured, current implementation assumes that if the module is an atom, then it can be used, without necessarily checking if its loaded, or exists in the code path. This needs to be fixed to at least check the module's existence with code:which/1 for example, and fallback to either the default rabbit_password_hashing_sha256, or the legacy rabbit_password_hashing_md5, in case of a misconfigured password hashing module.

[michaelklishin]

Falling back to MD5 is a terrible idea. If a module doesn't exist perhaps the node should not boot.

[Ayanda-D]

Shouldn't we draw the same conclusion as when its undefined? And just log a warning/error message that a default module is being used, and the custom module was not found/does not exist. Seems too light a reason for a node boot failure.

[michaelklishin]

undefined means you want the default. A non-existent module means a misconfiguration of some kind.

[Ayanda-D]

Okay understood. Although I still think this check needs to be carried out, and if a boot failure in such a scenario is what you guys prefer, then we at least fail safe, instead of a noisy failure. Personally I'd still prefer a fallback to a default module and just log an error message - but...your call :)