@Hellis81 I know it’s all sorts of safe to use pwndpasswords API and I understand the noble idea to protect people from making bad decisions. But in the end, shouldn’t people at least have the option to not be “protected” ? Why force babysitting on people ?
I now get buggered about an unsafe password nearly every day on an add-on I have disabled (SSH). If I ever need SSH I will unplug the internet before I use it. How can I get rid of the babysitting ? Only by changing the password and while that IS little effort, it is effort I shouldn’t have to take in the first place…
2 Likes
Collaboration in software development often requires opinions from its development community. My point is that this discussion should have occurred and someone raised the opinion: “No, lets force everyone to send the data out”.
Hijacking an API isn’t really a new concept and Chrome is nor a OS or a server application. Your comments are all based on “let me explain why it’s safe”.
1 Like
Don’t get me wrong. I agree with you.
I just answered someone who obviously has no clue what he is talking about in the thread.
I agree, opt out or permanent dismiss.
1 Like
Keep your insults to yourself. You don’t exactly come across as SecOps.
2 Likes
There needs to be a way to turn this $hit off. it keeps complaining about my MQTT password, i used a fairly simple password as all my MQTT are are internal. I have some 70 odd mqtt Clients and I’m not spending hours logging into every device changing its MQTT password to appease HA;s nagging,.
There should be away to either turn it off or it tells you once only…
So for now my only option is to block it at my router…
3 Likes
Should I take that as an insult? 
No. You just come across as rude.
2 Likes
To be fair, yes, people shouldn’t have to be babysat. But, most “people” are dumb when it comes to both internal and external network security. For instance, search the forums and you’ll find users with local instances of HA being hacked due to that person not understanding the basics of internal network security and having insecure local passwords, especially when their HA instance is externally available on the Internet.
Further, given that most people are running Supervisor, that means that their most critical services are installed as add-ons in HA and most of the time, that’s done with weak passwords because it’s “easy”. This allows for a simple attack vector when it comes to network intrusion as it’s all basically a single network with an easy intrusion entry point.
Do I agree with the persistent notification? No, not at all. However, I understand why the devs built the notification in and its purpose.
1 Like
We actually agree (reading the rest of your post) but this part strikes me as inconsistent with the whole tenor of HA.
Newbies, or often just anyone who asks a “dumb” question, seem to be treated like they don’t belong here. They are sometimes made to feel they shouldn’t be using HA unless they have a lifetime of very specific technical knowledge.
In short, this whole project seems to be designed to keep people who are “dumb” away.
If a certain level of technical ability is a requirement for using HA, it seems to me we can be assumed not to need babysitters for our password strategy.
[Edit: I should add that doing the check and the notification every hour is not possibly justifiably in any way.]
3 Likes
Both your statements are accurate. Or, at least they used to be. I started playing with HA way back in 0.3 days (2015/2016 ish?) and comparing those old versions to today, HA absolutely was targeted to more techie types than it is now. Fast forward to today and it’s evident that the devs have spent a LOT of time trying to make HA more usable by those with little to no technical knowledge (hence why Supervisor and HA-OS (or whatever it’s called now) even exist). Further, and again, to be fair, the HA community today is much, MUCH more welcoming to newbies compared to other projects; If you want to see true toxicity towards newbies, head over to the OpenHAB forums. 
To be fair, I wasn’t actually referring to people JUST using HA. People, by and large, are extremely dumb when it comes to network security. Complicated passwords, ssh keys, etc are too much trouble for the common user. I’ve been in IT for over 30 years and I can’t even begin to count how many times I’ve had to completely wipe not just a single computer, but whole fleets of servers, because some user was too lazy to use a complex password and them giving stupid reasons like “I can’t remember complex passwords!” to “It’s too much trouble to type in 10 characters!”. When you’ve had to give up days of your time because of someone’s laziness (ask any salaried network admin how many days/weeks/months of their lives they’ve given up because of user stupidity), you start to understand why a product that is literally in control of someone’s house and security is trying to make password security better.
Like I said, I agree that there should be an off toggle for this “feature”, but I also understand why it even exists in the first place and yeah, every hour is a bit much.
Sorry about the rant. 
1 Like
It’s very valid from a password perspective.
But how many times have you ran into a server application or linux distro, that out-of-the-box does a password look-up to a third party provider for all your integrations?
Practically, if you sit on the look-up API you’ll get a curated list of IP’s with potential weakness. Especially those that comes ringing at your door and request a hash-download or perhaps ten… and then repeated every hour.
3 Likes
You’re not wrong. Were it me designing the “feature”, I would have done it a lot differently. Hell, even a local db check of known weak passwords or a one time check using character parsing would have been better than an external API call, which I suspect will cause other problems due to rate limiting in the HIBP v3 API as 2021.3 starts getting installed by more and more HA users.
1 Like
You still don’t get the idea and the technique behind this feature. It maybe should have an on/off switch, but the rest of your thoughts are simply not right. And no, this is not rude r offensive, it is simply acknowledging that you don’t get the facts straight, despite @Hellis81 explaining to you how it works.
There is no list of currated IPs with potential weakness. There could be (but it isn’t) a list of IPs, but the rest is just not right. There is no way to know anything about your password, nothing at all, not if it is weak or strong or even if you spelled it right. Nothing. There are five digits from the beginning of your hash, that’s it. With these five numbers you don’t expose anything at all, because with the next api call a different hash is generated and checked. That’s the beauty of hashes and how they work.
And for the general tone in here. This forum is one of the friendliest I have ever seen, newbies will be handled respectfully and even the dumbest questions are answered in a great length, just take this thread as an example. If this forum would be unfriendly, your first answer would have been “live with it”. That is not the case.
HA is a complicated, big system that is not always understandable at a first glance. So answers may very well be short and on the point wihout a loving, warm feeling, but they get you to a solution (mostly). And that is what this forum is about. If you want something else start a petition and get a “We cuddle up” section here on this forum.
That is exactly what is done! A local check of your passwords. To receive a list, there is an api call necessary. How would you propose to get that list with unsafe passwords? With a letter and you type them in? Always with a new update for HA? That wouldn’t make any difference. This api call does exactly what you are describing: it get’s a list with unsafe passwords and checks them locally without exposing your passwords.
And just let me remind you of one thing: it is YOUR unsafe password. You get a reminder to not use it because it is unsafe. I can’t see the point where one would discuss his “privacy” but isn’t willing to change to a safe password… That’s exactly why this feature is implemented: to remind you, that it is YOU who has the power to change things.
2 Likes
I’d do it without the API call. The password hash (well, a portion of it) is still sent externally from the HA instance. The way I would do it is to have a local DB of known bad/common passwords (see NIST Bad Passwords | NBP as an example of local, client-side common password checking) and then a simple character by character check after that to determine password strength. Thousands of open-source projects utilize this method without having to reach outside of the local network to check if a password is considered secure or not for years now with nothing more than simple javascript.
To be honest, I don’t think it’s simply the fact that HA is nagging about insecure passwords that has people up in arms, but the fact that it is reaching out to an external resource with no way to turn it off easily and no notification that it is doing so.
1 Like
I get trying to stop people from shooting themselves in the foot, but you let us disable protected mode for plugins, why not let us disable the nag (and the internet call)?
Some of us have pretty save, vlanned off installs of HA (and all their iot devices), let me be lazy with passwords in this one place. I can guarantee you I’m not using any of these insecure passwords anywhere else.
Failing that, expect to see a new addon appearing that’s one role in life is to disable the check in supervisor.
(Only reason I’m not releasing already is it’s 1:30 in the morning, I’m on holiday, the internet here is awful, and I want test it where I’m within arms reach of my install)
2 Likes
As I’ve mentioned before, if you would like to bring up the technical part. Please post a separate topic on it and feel free to explain why you consider it to be “safe”.
There is no list of currated IPs with potential weakness. There could be (but it isn’t) a list of IPs, but the rest is just not right.
This is a guess and not a guarantee
There is no way to know anything about your password, nothing at all, not if it is weak or strong or even if you spelled it right. Nothing. There are five digits from the beginning of your hash, that’s it. With these five numbers you don’t expose anything at all, because with the next api call a different hash is generated and checked. That’s the beauty of hashes and how they work.
Security is not only about strong/weak passwords. This is a typical faulty security approach. It’s about puzzling pieces of information together.
And for the general tone in here. This forum is one of the friendliest I have ever seen, newbies will be handled respectfully and even the dumbest questions are answered in a great length, just take this thread as an example. If this forum would be unfriendly, your first answer would have been “live with it”. That is not the case.
Yes, the general tone here is friendly. Assuming someone else’s opinion and then add “you don’t get it” is not considered friendly.
That is exactly what is done! A local check of your passwords. To receive a list, there is an api call necessary.
Really? Just a download - no data sent?
1 Like
If I’m also being honest, it’s not the API call that has me up in arms. It’s the fact that I can’t turn off the hourly, nagging messages. Oh, yeah, and if it’s doing the API call hourly too, that would be just plain stupid.
To be clear, doing a check ONCE is totally justifiable. Doing it hourly, nagging the user hourly, and offering no way to dismiss or block this activity is not. And while I’m personally not up in arms over it, calling an outside API without full disclosure and opt-out isn’t a good practice, either.
5 Likes
Oh dear God…
Anyways…
I would believe that millions of hashes take up way to much space for the average HA user to be OK with.
Those who run HA on an old computer could probably be OK with it but the others would probably not.
And those who run HA on mobile homes, boats and other with cellular connection would probably not be happy either.
Not to mention that this list has to be maintained and downloaded again every now and then to be “fresh”.
What good is a database from yesterday?
According to the page they have 613,584,246 passwords.
If we assume that is in UTF-8 then that means about 1 KB per password.
Meaning about 0.5 TB for the full database.
That’s not correct, sorry! What you do, is to check against common passwords and their strength. That is not what is happening here! The api call is to make sure you do not use an already known hacked password! For example, if your password is jd6$("/$$/=fhvöpo rgfuhrgf5(%§8r7bfhefHGVDWZFnnfuiNG it is strong and most likely not on a list for common passwords. But if it was hacked before, for example through the hacking of a database from let’s say Amazon, it would be on the list from the api call. That’s the difference here.
Same applies here, its not about the strength, it is about an already hacked and therefor known unsecure password. I have a similar setup as yours with VLAN for iot devices and so on, and I can asure you, my password (only internal inside the VLAN) is only five letters long, but I don’t get any warnings. That’s because I’m using a not hacked, but short and unsafe password. You see where I’m getting at?
But I can see the point where you don’t want to change a lot of passwords afterwards (in an already existing installation). Do the addOn / custom_component, I will def. install it.
Why? This is exactly the thread where it belongs, it is duscussed here. My opinion doesn’t matter here, it is a fact that this is a safe way (at the time writing this, in ten years it may be different). If you don’t think so, and don’t want to believe people that are telling you, then open a thread and write down, why you would consider it unsafe. Nowaydays it seems to be the general idea, that if someone says you’re not right has to explain himself. Why don’t we do it the other way round, as it was for hundreds of years? If you don’t believe something, give proof it is not believable.
Nope, it is a guarentee. As you might want to read up at the site:
Logging
Only the bare minimum logs required to keep the service operational and combat malicious activity are stored. This includes transient web server logs, logging of unhandled exceptions using [Raygun] (https://raygun.com/), Google Analytics to assess usage patterns and Application Insights for performance metrics. These logs may include information entered into a form by the user, browser headers such as the user agent string and in some cases, the user’s IP address.
See above. It is not about strength or common use, it is about a very specific approach to know about hacked and used passwords.
Yep, really, there is no data send that can in any way compromise your password. It simply is not possible with this approach. Not even for the NSA.
Correct, and it really isn’t needed nor was it ever requested (that I ever saw in the various forums). Checking against an external API, without requesting the user’s permission beforehand, is simply put, shady, regardless of what the intent is. If I don’t authorize said app to make an external API request, it shouldn’t be allowed to make said request. This is especially true for HA which has been billed for YEARS now as a local, privacy focused platform. This move throws years of trust out the window.
Further, what about those people who don’t allow HA external access? Since I don’t run Supervisor, I can’t answer this, but what happens to the log files when HA can’t access this API call hourly? Does it generate tons of log entries? How does someone who’s blocked HA from internet access get a notification that their password(s) may potentially be compromised?
Checking for common passwords and doing a password strength check are both acceptable as they can be done locally. This method, no matter how you argue it, is not done entirely locally. It’s calling an external API (the reason why is not important) without my permission and with no way to disable it outside of forking and modifying the code. That is simply not acceptable in any way, shape, or form.
1 Like