Would love to add Pi-hole 2fa to my 2fa auth apps, for added security.
Do you really need 2FA on devices hosted within your own LAN?
1 Like
Yes. I have roommates.
And these roommates are actively interested in breaking into your password protected web admin page? I can't imagine that with any reasonable password choice they would be able to do so.
Well, generally speaking, this is a feature enhancement not only I would be using, so it's not specific to my own personal situation. There can be many living situations where Pi-hole admins might want this feature.
In my case, I use LastPass, and accidents can happen; the LP activity timer hasn't timed out yet, leaving my passwords available; browser form fills saving the info; lots of possibilities including unforeseen ones. Nothing wrong with adding an optional security enhancement, that users can choose to enable or not. No?
1 Like
Do you have 2FA on your router admin page, and on your ssh login to the Pi?
1 Like
I run the Docker PH.
Nevermind, I can see you aren't open to suggestions.
3 Likes
I would love to see this feature implemented. I've enabled 2FA on other network appliances, ssh and web logins and would like to do the same for pihole.
1 Like
You can get close to this with a YubiKey 5 Series. Use YubiKey Manager to generate a long random Secure Static Password and store it in either Slot 1 (short touch) or Slot 2 (long touch) of the OTP interface. This is presented as a USB keyboard when connected.
Connect the YubiKey and ssh to the Pi-hole terminal. Run this command to change the web admin password
pihole -a -p
Enter a password that you can remember and, before pressing Enter, activate your OTP Slot 1 or Slot 2 (whichever one contains your SSP). This will be appended to the password you have typed and the YubiKey will add the Enter key for you. Your Pi-hole password will be updated.
In order to log in to the Pi-hole web interface, you need to know the password part that you typed in, and you need to have your YubiKey available to auto-append the SSP part.
The earlier points made are valid though – if someone has access to your Pi-hole terminal, for example, they can reset your password, so now it's only as secure as your ssh process. And for that matter if they can physically reach it they can pull the card out and mount it. A serious attacker will be finding a different attack vector and a casual roommate will be stopped by a decent password.
So it's worth reassessing what you are trying to achieve. Using the YubiKey approach may be a good solution in some managed situations such as a company, but probably not so useful in a home environment except for the fun of it.
2 Likes
My ssh process uses password protected ssh key + Yubico key...so yeah, the web login is the weaker of the two.
The goal is two fold:
- Re-enforce the login process to limit/prevent brute force attacks.
- Add to the global goal of limiting lateral movement inside my network should a breach occur. I've used other measures toward this goal such as vlanning but since this is core network device it can't really be vlanned off completely.
I'm not worried about physical attack as I'm not that high value of a target. That being said, remote attack is a possibility.
The SSP method you mentioned is a short term option...but long term I would still like to see proper 2FA (preferably hardware key) integration.
Looking at our developer team resources I see no chance of implementation of such a feature. But contributions are welcomed.
For anyone wanting to explore a proper 2FA approach using YubiKey 5 Series, Yubico OTP is a good fit. They host a validation service and it's ready to use out the box. The validation is all done now via HTTP GET calls.
While it's a too big a project for formal integration, might this be something that would be relatively straightforward for a Pi-hole user to retrofit to their own installation? I'm guessing using some mods to login.php needed at the very least. It looks like it comes down to generating a HTTP GET and parsing the success or fail.
The issue with adding things like 2FA is how to do it reliably.
Touting things like 2FA implies a level of security and I'm not comfortable implying that unless I know for certain that the code works and is safe. Slapping in some package or making traceable and identifiable calls to a remote service that we have no control of is not something I'm going to accept easily.
If this is something you really need then look at using a dedicated security package/application that is made for 2FA/SSO and use that as a reverse proxy to manage all of your network services.
Side note: 2FA isn't going to do a thing to prevent or limit brute force attacks.
2 Likes
I agree, that's what I mean by it being too big a project for formal integration. There are all kinds of aspects to consider, privacy, error handling, support, plus whether it even adds any security. I'm not convinced that it does except in very specific circumstances.
Any such mods using the above would be a per-user custom hack at a hobbyist level, so I mention it out of interest for anyone who has a YubiKey 5 Series who wants to play.
Not having the development resources and wanting a proper implementation are both understandable.
Some of the other comments on this request that take the position that 2FA adds very little to no security are baffling and quite honestly concerning. We are talking about a device that handles DNS and thus without properly being secured could open one up to DNS poising.
While 2FA isn't the end all solution, it definitely adds a layer of security to the login process, especially when hardware keys are used. When combined with fail2ban to rate limit login attempts, its a pretty strong combination.
Limit/Prevent was a bad word choice on my part, and I should have said that 2FA helps render the effect of Brute force attack almost moot in that, even if they get the password, without your 2FA, they cannot get in.
"look at using a dedicated security package/application that is made for 2FA/SSO" Perhaps this is the best route forward for me to achieve my goals at this point.
In what way?
2FA has its place and there are some scenarios where it will add security to a Pi-hole installation. I would imagine these are where the Pi-hole is part of a managed infrastructure, for example on-premises kit with access control, network policies and various processes around them.
I can't think of any other scenarios where there is a benefit in adding 2FA to the web admin login. That login should not be world-facing, and for a private device at home what would be protected against with a second factor?
On balance I think the comments on this thread are fair and well qualified, and they make a good point that development is a limited resource which has to be spent carefully where it adds value to typical users.
Idea – it might be interesting in the installation script to have a single question with multi-choice radio buttons. something like : "We are interested to know how people are using Pi-hole. Can you tell us what kind of environment you are installing Pi-hole into?" with answers "Home, Company, Charity ..., Prefer not to say" etc that kind of thing. And the answer is posted once during install and collated for counting types of install.
At a minimum, the upstream DNS servers option could be modified to point to a malicious dns server.
A lot of people run unbound alongside of pihole for a complete package, so in that case, an attacker could brute force the login and then leverage an exploit to gain root privilege's and either modify unbound with malicious records...or disable unbound and spin up some other dns server that they can control.
That's because you are not thinking like an attacker. It doesn't matter if on-premises kits are not exposed to the world, chances are you have something that is.
Take the last pass breach as an example: The attacker got to the engineers computer via their plex server. The engineer failed by 1. Not changing a compromised password and 2. Not updating the software in 3 years but this kind of bug could have easily been a zero day.
So yes, pihole isn't exposed to the web but I do have other services that are and should a zero day be exploited on one of those then they could potentially lead to access to pihole.
Unless you airgap, nothing is beyond reach..not even pihole.
In all those cases the Pi-hole login page is protected by a strong password. A second factor has no bearing here. If I had written up an attack module to exploit a zero day, I wouldn't waste time hunting for possible Pi-holes-that-can-be-monitored-looking-to-replay-web-admin-passwords-at-some-point-in-the-future-maybe. I would simply modify the compromised device's network stack directly right now. In your examples you'd be better off detecting and dealing with the compromised device, regardless of the cause.
Even air gaps have weaknesses. The question isn't whether anything can reach Pi-hole ever. It's who they are, how likely it is, what are they going to do when they get there, why, and what's the payoff.
Just to make it clear, I'm not Pi-hole staff, just a long-time user. This thread is in the Feature Requests category and so people can vote on adding 2FA, and it would be interesting for anyone doing so to post their threat scenario and how 2FA would help it.
1 Like