4 ms·
I’d say the things hitting your endpoint are going to be entirely automated scanners that are looking for unauthenticated resources or low hanging common passwo
by ratorx 4y ago
I’d say the things hitting your endpoint are going to be entirely automated scanners that are looking for unauthenticated resources or low hanging common passwords. If you have even a moderately strong password, it’s just noise. I’d be wary about drawing any significant conclusions from logs, because the sophistication of attackers you’ve excluded are quite low.
I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. What you’re trading off for is complexity and convenience vs security. In the URL case, a password is more secure (and treated as such) and lots of care is usually taken to make sure the hashing scheme is timing resistant etc. I don’t know if Caddy makes equivalent guarantees, but I’d be very surprised if path matching was not just a string match/regex/trie. In terms of time to crack, just prepending these characters to the password would give you more protection, because that then has to go through a resource intensive hashing process.
An example of defense-in-depth would be to host at home only. Here, it’s because you’re nesting actual isolation (which is a good security primitive by itself), with a strong password. This gives you protection even if your threat model is “caddy is borked and is letting anyone do anything”.
Now in reality, you can do just about anything and it’ll work (because in the grand scheme, you’re probably not a high value enough target for any high cost attacks). If you secretly happen to be, then you can afford an actual security audit, rather than relying on random info from HN :)
- diarrhea 4y ago> I’d say defense-in-depth is more about nesting strong cryptographic primitives, than simply adding layers. I like this insight, thank you. One rebuttal I have: appending those characters to the password would make it a stronger password, but it wouldn’t add another, wholly different, mode to authentication. It would be the same thing, just harder (and I don’t need a longer password as it stands). What if this mode is flawed in itself? That’s when a wholly different one is desirable. In that spirit, I had also thought about just slamming http basic auth in front of everything. Even if that basic auth uses weak credentials, it adds to security in a multiplicative/exponential way (multiple passwords/systems), over just a linear one (single but long password). I suppose that’s also what you mean by layering.
- ratorx 4y agoLinear/multiplicative stuff is actually quite helpful for discussing the path thing. Adding a “password” path is actually only increasing your security by a constant factor per character because of the risk of timing attacks (unless you are sure that the path matching algorithm is secure against it now and in the future). Ideally a 2nd layer would guard against it in a multiplicative way (an entirely different with system). Cryptographically, adding characters to the password rather than to the path is better (because it increases the search space exponentially) than adding characters to the path, which can be brute forced separately per character. But this assumes a very perfect view of software, where there are no bugs. Once you add a risk model for bugs, then there might be small values of path length where the additional constant factor is better than the multiplicative one that you get from adding characters to your password. So your rebuttal holds, depending on the exact bug risk model you have. I think nowadays, tailscale/wireguard is really convenient and pretty secure as a 2nd layer. I was averse to self hosting my password manager in the past due to not being comfortable having the consistent time to secure more critical applications, but I might actually move to a world where I host more critical things myself behind a VPN.