Agreed - it’s bizarre there’s no whitelist facility as things stand
wait, so adding that line doesn’t work? what about the trusted_proxies option?
The repository has been archived.
Someone willing and capable of cloning it and bringing this great integration back?
Logger: custom_components.hacs
Source: custom_components/hacs/base.py:885
Integration: HACS (documentation, issues)
First occurred: 22:37:57 (1 occurrences)
Last logged: 22:37:57
You have 'custom-components/authenticated' installed with HACS this repository has been removed from HACS, please consider removing it. Removal reason (No longer maintained)
I talked to „my it guy“ and he gave me a good and pretty simple workaround I want to share: just set the login attempts to e. g. 50 or even 100.
you won‘t lose significant safety concerning bruit force or dictionary attacks where we are talking about up to millions of attempts needed but won‘t lock out yourself anymore; as long as you use a strong and unique password of course.
3 Likes
I’ve got a situation where a particular computer must be attempting to authenticate using a ‘remembered’ method that Home Assistant once accepted but now doesn’t want to.
Anyway as soon as this computer tries to connect to the web GUI it’s banned.
Any ideas?!
Sadly this seems to be the only route but it greatly reduces your security. I run an offensive security team and anything over 3 attempts we recommend to bring down. There is a time period before this counter resets, so setting it to 50, an attacker can fail say 49 times in an hour rather than 2 times in an hour. Your IT guy should really look at the security. If your instance is Internet accessible then you’re opening up a larger can of worms.
1 Like
I get your point, in some sense it’s about up to 25 times less safe?
On the other hand, Mike Pound once stated in the famous Computerphile Password cracking video that any 8 character password could (7 years ago) maybe be cracked in a few hours up to a day at 14 billion hashes per second assuming an MD5 encryption (unlikely).
Now I hope I do the maths right: let’s say we could break any 8 character password in one second (!) of computer time with 14b guesses/s… Then if you get 49 guesses per hour, you have 1176 guesses per day resulting in more than 32000 years of guesses until the password is cracked. And I did not take into account 2 Factor Authentification or the fact that my password is of course longer and hopefully complex enough.
So I guess we are still kind of safe? At least this is my understanding at the moment, but I‘m absolutely no expert. Did I get something fundamentally wrong?
I’ve written a little integration addon that adds this functionality: GitHub - palfrey/ban_allowlist: Home Assistant plugin to add IP ban whitelisting. Note it does things in a bit of a hacky way (monkey patching the HTTP ban list code), but it does seem to work for me so far, and I’ve got fairly decent integration test coverage for it. Patches welcomed if there’s any missing features.
5 Likes
Does it supports ip range? Can you write an example with multiple ip in the configuration.yaml so we can se how to correctly write the list?
1 Like
Yep, if we can have an IP range that’s should be perfect.
Multiple ip example is already in the README. See
ban_allowlist:
ip_addresses: ["my.ip.address", "another.ip.address"]
IP ranges: it doesn’t, because I don’t need it. Patches to fix this are welcomed though.
Any future feature requests should be done as issues on the repo, as I’m not here that often, but I pay attention to Github a lot.
2 Likes
Is there any solution to this after all these years? I start to be banned on my own home network… This is very annoying
2 Likes
With the exception that people usually use easy to guess passwords. I don’t brute force a form or auth page. You are talking about if you get the hash and brute force that offline. When targeting a page I will try to either see if the user has already known beached credentials that I can mutate or start using top few thousand lists in hopes that is weak. I’ve gotten domain admin in international organizations by guessing P@ssw0rd! … People be dumb some times.
1 Like
Thanks for sharing a solution! Working nicely for me so far.
I know you said you don’t need it, but I’m not a Python coder to submit a patch either. I think a simple string compare to the first three quads if there is an asterisk to match to in that list would work just fine and make a lot of people very happy sir…
As per your request… REQ: Please add CIDR notation or a wildcard for the last quadrant · Issue #3 · palfrey/ban_allowlist · GitHub 
Great to see there finally IS some kind of „solution“ for this - even it is a „very hacky“ way and tbh feels kinda dangerous to use a custom integration for such a (even security related) core component.
In short: if a custom integration developer can do this, why isn’t it possible to natively add this to the core? I think that is the actual way to go - now that it is proven it is possible.
Did you think about porting this to the core @palfrey?
Hi, I noticed something interesting. I never had issues with banning my own IP address because of the companion app and started recently. I decided to troubleshoot what did I change recently that caused this to happen. I did some network changes and I had to put HA on DHCP so I don’t loose access to it after the change. The IP was anyway reserved so would not change. When I changed back to Static IP, no more banning!!! It might be that when the lease expires, takes a few minutes to renew and in that time the problem occurs, just trying to guess…
I found in logs below:
[supervisor.resolution.checks.base] Run check for IssueType.DNS_SERVER_FAILED/ContextType.DNS_SERVER
Some people reported this happening on DHCP or Static IP. I hope my post will help other people with odd banning issue.
Today it happened again. One more thing I changed that could trigger the ban. I setup 5 widgets on my android and before the bad to happen, I saw the warning with failed auth on all those widget APIs…
I have 5 widgets created, I increased the threshold for ban to 6. Hopefully will sort out my issue.
Update. The trick worked to increase the threshold higher than the number of widgets. I get notification but no more banning.
Nope, I’m still getting bans…
I’ve now added a linux script to check the ip_bans file for my IP and if it’s there, it changes it to 1.2.3.4 instead. Phone can log in again within 5 mins…
Can’t believe this problem is still with us after all this time…
I’ve removed all of my widgets on my android phone and now no longer get IP banned…. Seems like this is something for the companion app devs to take a look at…