6 ms·
Caddy comes with basic auth support because it's still useful for a lot of use cases. IMO the biggest weakness of basicauth (when deployed over TLS) is the fac
by mholt 5y ago
Caddy comes with basic auth support because it's still useful for a lot of use cases.
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.providers.http_basic 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 https://github.com/caddyserver/caddy
- LAC-Tech 5y agohappy new year. Caddy is such a great piece of software. It has great defaults 'out of the box' but at the same time doesn't feel like I'm drowning in incomprehensible magic. We need more software like this!
- hasel 5y agoIs this supposed to be used to put entire domains behind basic auth or should you use it for specific end points?
- g_p 5y agoYou can do this for specific endpoints in Caddy, or whole domains/sites. 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.
- makeworld 5y agoIt can be used for either. Depends what you'd like to do. Maybe the domain is admin.mysite.com and so you want to wall the whole thing off. I've used it for specific endpoints as well though, like to protect certain folders of a file server.
- mholt 5y agoYou can do either. To Caddy, "entire domain" or "specific endpoints" are all the same thanks to request matchers. You can precisely customize which requests have basic auth applied to them: https://caddyserver.com/docs/caddyfile/matchers https://caddyserver.com/docs/caddyfile/matchers
- mmcnl 5y agoCaddy is truly amazing. Thanks for that. Tip for me would be to improve the documentation and add more examples, just to get the hang on what the Caddyfile philosophy is. I've spent literally hours just to come up with a single line in a Caddyfile (and in the end it worked).
- francislavoie 5y agoThis page explains the structure of a Caddyfile: https://caddyserver.com/docs/caddyfile/concepts https://caddyserver.com/docs/caddyfile/concepts. What are you missing from there?
- IggleSniggle 5y agoI’m confused by this. If you have the username, the hashed password, the salt, and the algorithm used, all present in the config file, then what’s the difference between doing what caddy does here and just having the plaintext password in the config file? Isn’t that just the same thing but with extra (known) steps? Not trying to be intentionally dense, genuine confusion/question.
- nvllsvm 5y agoIt's essentially impossible to reverse the hashed password. This is particularly helpful for users who reuse the same password for everything online.
- eyelidlessness 5y ago> It's essentially impossible to reverse the hashed password. 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.
- mholt 5y ago... for one account. It takes N times as many more resources to do that for N more accounts. The attacks are impractically expensive for most attackers.
- spiffytech 5y agoIf an attacker compromises your stored plaintext passwords, they can test those username+password pairs against other online services, since lots of users reuse passwords. If you store hashes instead of the actual passwords, the attacker doesn't get the user's credentials. 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.
- 5y ago