If you can host the 0.5 TB database then it shouldn’t be too hard to do the check yourself.
I have to be honest, I miswrote in my post before, sorry! The whole discussion is about emails and not passwords. Your password isn’t checked with haveibeenpwnd, that is another service, but that’s not used here. Here, and this is what HA checks, we are talking about email addresses and not passwords.
Sorry for the misunderstanding, I just took the quote and answered without realising that’s not what we’re talking about here. To answer the thread title, there is no sending of passwords anywhere!!!
I’m very sorry to tell you that, but you don’t get the way it works. You still try to argue that there is something send, that could be seen as personal data, but that isn’t true!
What is done with this api call is the same with weather (all weather providers), with updates for devices (eg. zigbee), with update checks for HA and a litterally thousands more. Every component/integration that you use does make a call “outside” once in a while. That is simply how things work.
What one doesn’t want is, that personal data is shared in any way, if a call has to be made, it must be safe for your data. And that is exactly what is happening here. A request is send, to get a list. And to shorten that list, the first letters will be shared. Let me give you another example:
If you want to download a list with all cities in your country with more than 10000 people, you send a request. To shorten that list, because you know the city you’re looking for starts with “R”, you include exactly this in your request (give me a list with all cities over 10000 people that starts with R). There is absolutely no data send, that could even lead to any kind of compromising your data. This part is totally local.
If you want to, you can always ask for the full list, so no data beside (I want a list) is send. But it will not make things better, just the data that is shared with you is way bigger, that’s all.
The system from https://haveibeenpwned.com/ is fool proof and safe, again, this is fact.
I see why you try argue that way, but again, please go to the site and read up how they work and why they do it that way.
So to sum it up, if your arguments would be true, I would say you’re right, it’s not ok. But your argument isn’t true and therefor can’t be taken into account for a final decision.
I can’t say it strong enough, this is not what is happening here, see above. This is, simply put, nothing but a call to check for updates. So no, nothing goes out the window, if someone understands how this is working.
It seems a bit confusing what exactly is done here, so I just want to make it very clear:
Your email address will be compared to a downloaded list of hacked email addresses. That’s all, nothing more, nothing less!
This could be an interesting for those who’s in the field
https://cablej.io/blog/k-anonymity/
Though scope is somewhat limited to singular brute, a pattern recognition (multiple user) would increase the results significantly.
The attacker’s gonna be sorely disappointed when they go to all that trouble and can only close my curtains.
Brilliant - I started with the automation but, frankly, prefer to opt out completely so have followed your approach and blocked api.pwnedpasswords.com on PiHole and my firewall.
Frankly, I think not providing an opt-out is retrogressive - users may have very good reasons for the passwords they use and be entirely happy to accept the residual risk. This is the HASS equivalent of forcing car owners to clip the seatbelt then sit ON it when they don’t want the bloody annoying buzzer but don’t want or need to wear the seatbelt!
Respectfully, you have no idea what you are talking about. First, it’s a subset of your hashed password that is sent. Not an email address (nor did I see where anyone was claiming an email address was being sent). Secondly, read the source code. Supervisor is sending out a portion of your password(s) (which could be quite a few depending on how many secrets you have in your secrets.yaml
file) to HIBP without the user’s consent.
import asyncio
import io
import logging
import aiohttp
from ..exceptions import PwnedError
_LOGGER: logging.Logger = logging.getLogger(__name__)
_API_CALL = "https://api.pwnedpasswords.com/range/{hash}"
async def check_pwned_password(websession: aiohttp.ClientSession, sha1_pw: str) -> bool:
"""Check if password is pwned."""
sha1_pw = sha1_pw.upper()
try:
async with websession.get(
_API_CALL.format(hash=sha1_pw[:5]), timeout=aiohttp.ClientTimeout(total=10)
) as request:
if request.status != 200:
raise PwnedError()
data = await request.text()
buffer = io.StringIO(data)
for line in buffer:
if not sha1_pw.endswith(line.split(":")[0]):
continue
return True
except (aiohttp.ClientError, asyncio.TimeoutError) as err:
_LOGGER.warning("Can't fetch hibp data: %s", err)
raise PwnedError() from err
return False
"""CheckAddonPwned class for check."""
@Job(
conditions=[JobCondition.INTERNET_SYSTEM],
limit=JobExecutionLimit.THROTTLE,
throttle_period=timedelta(hours=24),
)
async def run_check(self) -> None:
"""Run check if not affected by issue."""
await self.sys_homeassistant.secrets.reload()
for addon in self.sys_addons.installed:
secrets = addon.pwned
if not secrets:
continue
# check passwords
for secret in secrets:
try:
if not await check_pwned_password(self.sys_websession, secret):
continue
except PwnedError:
continue
See the line that loops through the secrets? Yeah, that is grabbing the password and sending it (hashed) to HIBP. So, please, stop with the defense. A portion of a password (hashed or otherwise) is being sent from an instance without the user’s expressed permission. That is fact. It’s in the code. Feel free to examine it yourself.
There are so many things wrong with this statement. First, every integration that is added to HA MUST be initiated by the user in some way, shape or form. This is the implicit consent that you authorize your instance of HA to communicate with an external resource. If I don’t want my instance of HA to communicate with a weather provider, I don’t enable that integration. If I don’t want my instance to do update checks with HACS, I can disable it. In this instance, if I don’t want my instance of HA to communicate with HIBP, there is no way to turn it off. Again, it’s in the code, so aside from forking the code, there is nothing that a user can do to stop this check beyond blocking the call at their firewall.
This is where I take issue. If my instance of HA is allowed to make external calls to any service that I haven’t given my explicit permission to call, then that’s a problem and not the premise upon which HA was built.
Although there’s no official means of opting out, blocking the destination has proven to be an easy workaround.
In contrast, I have found it to be far more difficult to throttle Supervisor’s frequent connections to version.home-assistant.io
. I don’t want to block it but simply to increase its polling interval from several minutes to several hours. That is proving to be far more challenging than I expected. Supervisor contains more than one service that periodically accesses the URL. It not only uses that URL to retrieve the latest version info but to check Internet connectivity, Add-on updates, and something else. It’s that ‘something else’ that’s proving to be elusive and is responsible for calls to the URL every 5 minutes or so.
Well, you could actually write a cron that runs every several hours that whitelists version.home-assistant.io
and then blacklists it again after like 5-10 minutes.
Not a pretty solution (more of a hack, really), but it might solve your goal?
Errrr … !!
That’s the super secret Skynet version. Didn’t you know? lol
So … how long after ‘judgement day’ is that ?
I’m just trying to see how long I can go without building my bunker and stocking it with the essentials I’ll need (twinkies (apparently they never go off) 3 1/2 inch floppy disks (you always need a high-tech coaster) BetaMax Video tapes … cos it’s better technology than VHS (It JUST IS !!!) etc. )
You spelled Laserdisc wrong.
No, I chisel video information into ‘teak’ as it’s much more thermally stable and hard to ignite, reading it back is still a problem I’ve not yet solved though.
Edit: though not sure about woodworm …
Opt~out/in Password check to third party?
If you prefer it as optional, pls vote. Better for the devs to hear the community.
You gave permission when you updated to 2021.3, having read the release notes. You had a choice
Ummm… the password checking thingie is not mentioned at all in the 2021.3 release notes.
Surprise surprise, if I use Password1, Password2, Password4 someone may be able to guess my 4th password.
Exactly why I create a random password for everything.
Sorry, it’s not a core feature it’s a supervisor feature and I got the version number wrong.
Actually, I didn’t because I did not update to 2021.3 nor do I run Supervisor. My fear is that this will come to Core and it is why I am highly vocal about this change.
It won’t come to core, because it’s part of supervisor.