Not trying to be intentionally dense, genuine confusion/question.
You have to use hash functions appropriate for passwords (like bcrypt; don't use hashes like sha256 for this). And if you hashed correctly, it's still practical for an attacker to brute-force simple/common passwords. But at least users with hard-to-guess passwords get protected from your breach facilitating credential stuffing attacks.
It’s essentially a nontrivial unit of work to brute force the hash (or exploit collisions for a compromised hashing algo). That’s not impossible but it’s important not to overstate its safety too.
If you create a matcher like
@wp-admin {
path /wp-admin\*
path /wp-login\*
Then you can just service up that handler's endpoints:
handle @wp-admin {
basicauth {
username pwhash_goes_here
username2 pwhash2
}
# reverse proxy config etc, e.g.
reverse_proxy http://127.0.0.1:8080
And now only the wp-admin and wp-login endpoints are protected, but the rest of the site is unaffected.
IMO the biggest weakness of basicauth (when deployed over TLS) is the fact that most server configurations store the passwords in plaintext, usually in a config file. This is like storing passwords in plaintext in a database. Caddy does not allow this. You have to use a secure hash on the password before adding it to your config: https://caddyserver.com/docs/modules/http.authentication.pro...
Of course, password hashes are slow, so KDF'ing a plaintext string at every HTTP request can grind even powerful servers to a halt. So Caddy can optionally cache hash results in memory (we do expect memory to be safer than a config file -- and Go is a memory-safe language in this regard). And while this can introduce nuanced timing variances (fast if recently hashed), they do not necessarily correspond to correct passwords.
If you think this stuff is interesting and want to help make Caddy's basic auth even better, feel free to contribute or sponsor: https://github.com/caddyserver/caddy