2 ms·
If you're depending on HA's built-in auth, you're at risk of bugs in that code. If you throw up HTTP basic auth on your HTTPS front end, you've now moved your
by oarsinsync 6y ago
If you're depending on HA's built-in auth, you're at risk of bugs in that code.
If you throw up HTTP basic auth on your HTTPS front end, you've now moved your risk away from bugs in HA's code, to bugs in nginx's (or whatever HTTP server you use) implementation of HTTP basic auth AND bugs in HA's code (odds of this being a real event just got smaller)
If you throw a VPN in front of all that as well, you've now moved your risk away from bugs in nginx's code, to bugs in your VPN implementation AND bugs in nginx's code AND bugs in HA's code (odds are now really small).
This is also known as defence in depth.
- sgt 6y agoI realize that but if you don't, then HA won't be accessible to you if you are somewhere where WireGuard is not possible. Does HA have an exceptionally bad security record? I think one just needs to define one's own acceptance criteria.
- oarsinsync 6y agoHence the suggestion of at least throw up a second level of HTTP basic auth from nginx in front. > HA won't be accessible to you if you are somewhere where WireGuard is not possible At that point, you also really want OTP (along with nginx HTTP basic auth), as if you're connecting from a device you don't control, it's not a bad plan to assume a keylogger may be operational. Can you help me understand a situation where you have to get into your HA instance, and none of your own personal devices are able to get online? EDIT: > Does HA have an exceptionally bad security record? Is a lack of regular security fixes needed evidence of good code, or due to lack of inspection / identification of vulnerabilities? HTTP basic auth is like a seat belt. It's a minor inconvenience that adds a layer of security. I haven't had a car crash, nor has my infra been exploited to the best of my knowledge. I still use both HTTP basic auth and seat belts every day.