Server: Support specifying a password hash to `FAKTORY_PASSWORD` instead of plaintext

[f3ndot]

For the Faktory server, it would be nice to optionally supply a password hash to FAKTORY_PASSWORD for additional security with the Web UI's HTTP Basic. If we use the standard form:

$2a$12$KH2Yy3w5bx.fljs0kCEB4uXGIcGXFRadfTy8mx7myzVb8LXsIo.o2

Faktory can detect a hash and use it as such, otherwise assume a plaintext.

Alternatively an optional FAKTORY_PASSWORD_HASH or FAKTORY_HASH can be prioritized over FAKTORY_PASSWORD if set.

The rationale for this suggestion is minor but threefold:

• Some systems may use bcrypt, scrypt, or other hashes for other HTTP Basic auths outside of Faktory and being able to re-use it for Faktory's Web UI would be nice without slumped security posture of exposing its plaintext equivalent in Faktory's configuration
• Web UI would get a slower/harder password check which is a desirable property for authentication
• If somehow, for whatever reason, that configuration parameters of the Faktory process is exposed-- whether through Faktory server itself as an exploit, the image, or host machine with configured parameters-- the attacker could not connect to the server and inject jobs or cause chaos.

I recognize that FAKTORY_PASSWORD is also used for client/server authentication, assuming that implementers of the client-side known to keep a longer connection, the additional cost/slowness of a hash comparison shouldn't be too much of a penalty. And obviously clients would still always supply the plaintext into FAKTORY_PASSWORD.

[mperham]

I think it’s a great idea, PRs welcome.

[f3ndot]

Excellent. I'll take a stab at it. Been meaning to expand my rudimentary Go skills.

[f3ndot]

Seeing that #495 is under way, the client hashes the plaintext password for transmission to the server, and there is already separate support for Web UI passwords via the [web]\npassword config element, I'm going to take a stab at only implementing this for the Web UI.

I agree with @estheruary that using golang.org/x/crypto is an acceptable module to use for the common algo support.

Out of the gate I plan to expose FAKTORY_WEBUI_PASSWORD (for env var compatibility with [web]\npassword) and support the current OWASP-recommended set of password hashing libs Argon2id, bcrypt, scrypt, and PBKDF2 all in the PHC format. Unfortunately this has opened a can of worms since the nonstandard interface of x/crypto between the algos and seemingly no popular/de-facto PHC decoder in Go. I'll see what I can do as a first pass.

I think a larger conversation needs to be had about how these algos would be used in a Faktory client/server context if we endeavour to do so. It feels weird to support hashes for Web UI but not for the server, but the latter does use the password as as a "master key" to derive per-connection "keys" so the current protocol/approach cannot have a simple password hash configured for the server. A breaking change would have to occur and begs questions about TLS being required (while recognizing it could terminate in front of Faktory) or guarantees of a secure channel etc.