#849 Add basic HTTP auth
I would like to add basic HTTP auth to the endpoints and the UI. I can get this done pretty quick.
Reason needed
This is a concern since every device that has connected to the wifi will essentially remember the password forever and there’s no way to revoke access. A compromised device that once accessed it can’t be prevented from messing with the rayhunter.
Proposed Changes
Add to the configuration section in the GUI an area
- A toggle whether a password is required
- Ability to set password
- Ability to update password
- Ability to set password timeout (enforced on rayhunter)
On the backend endpoints it would enforce the password (if enabled). Basic http auth is compatible with pretty much everything including CURL.
1
This would be useless without also having HTTPS support. That is a prerequisite for any type of password protection.
previous conversation: https://github.com/EFForg/rayhunter/issues/22
Based off the conversation @untitaker mentioned then it seems like adding TLS support even with a locally generated self signed root CA we could get some protection. That would at least prevent leaking the credential, plus there’s some CSRF issues while there’s no auth which could have an attacker on another tab make a call to delete recordings or do all sorts of stuff.
Any objections to me starting with adding TLS support then?
@BeigeBox
I am concerned that with the self-signed cert it will just condition users to ignore those warnings without adding much security.
Like mentioned in the other issue, right now our security boundary is the WiFi network itself, and so in order to revoke access you just gotta change the wifi password.
I don’t agree that a password is useless without TLS. A device having access to the WiFi network does not automatically mean it’s able to observe all packets within that network. A device may run malicious software that doesn’t have the right permissions to capture packets, but still is able to send network requests.
But: Most of the devices we install rayhunter on have glaring security holes, and letting a malicious device onto its WiFi network is going to be problem in other ways. We use those security holes to install rayhunter.
So I think it’ll not fix much in this situation, and I don’t think it’s worth the effort.
Instead we should probably figure out if we can disable the WiFi AP in a cross-platform way, which would fix a ton of issues at once (detectability of rayhunter devices too). It seems people already do that and connect via USB tethering only.
Well, I got bored last night and did end up adding TLS functionality to my fork.
At the moment it generates certs when the user selects the configuration option.
In the future I’ll add in an upload to the configuration where they could provide their own certs. Reason being is this is especially useful if the user is using a local DNS server (or hardcoded hosts record) to resolve the host/domain name. For example I want to grab a cert that I was issued for one of my domains, so the cert validates on any machine on the network using my custom DNS resolver which has some hard coded resolutions). In that case they could have valid certs which don’t throw an error. I hope you’ll consider it’s inclusion, it’s not vibe coded slop and I tried to cover all angles including documentation completely.
EDIT: The TLS feature is off by default, and the user would have to turn it on themselves, so there’s little risk to it’s inclusion in my opinion.
Good call on the issue of disabling the wifi ap. After I finish the TLS (and if you’ll approve the scope of work for authentication/authorization) I could spike on that next.