Hi folks, I’m the creator of Have I Been Pwned and the Pwned Passwords service. I also love Home Assistant and have just read through this whole thread. I think this feature should be configurable and it looks like that’s coming, which is great. But there’s also a heap of content here which really misses the mark in terms of both the risk of bad passwords and how Pwned Passwords works. I’ve just published a blog post to address this so rather than go through it all one by one here, have a read of the post if you’re interested and ask any questions in the comments over there: https://www.troyhunt.com/home-assistant-pwned-passwords-and-security-misconceptions/
30 Likes
Fantastic read! Thanks for taking the time to respond with your thoughts!
1 Like
Ok fine. I’ll make my passwords better! Thank you for the nice explanation
I’m sorry, I have no idea why that is happening. I know docker, I know code, but maybe there’s some unique HA herbs and spices involved?
Thanks for taking the effort of writing, but in my opinion making a difficult password is still just a temporary solution to this problem. In my opinion only a two factor auth is a real solution to the problem.
Interesting read. For what it’s worth, I did end up finding the time to upgrade everything and change my MQTT security.
2 things that I feel strongly about though:
- You should be prompted before setting passwords if they are insecure, not at some arbitrary time after the event.
- Any notification like this should be dismissable and not expected to reappear every hour… Fill the logs with warnings, fine, but a notification every hour is not reasonable.
4 Likes
Thank you Troy for you reaction. Also thanks to the developers for creating and maintaining HA which is free and which you can choose to use or not.
some of the reactions made me think of this
https://pbs.twimg.com/media/Ecpq5lbWsAE1gBn.jpg
1 Like
I can talk a litte bit about it from the perspective of an addon dev. A addon can alert the user about an pwned password at the start of an addon. It if the developer enables the support for it with proper config schema’s. But as we have seen a few weeks earlier, a lot of addon don’t validate the configuration schema.
1 Like
I think this is exactly how this will happen in the future. Set up/start add-on and it’s checked along with some frequency for newly-compromised passwords. However, right now we’re at the difficult catch up period where a new feature is implemented and it’s clearing up all the previously unchecked secrets
1 Like
I think you missed the point here a bit.
I completely agree with your blog post, if you where the administrator or the owner of a network of services. Feel free to implement whatever you decide is safe.
The car analogy is what it is. All analogies are weak, that’s why they are analogies and not 1-1 comparable. But you missed the point there. In this case it’s about the difference of responsibility on public roads vs. personal space.
Cars warn you about a number of unsafe decisions and so does Home Assistant, but that’s where the similarities end. Everything else can be adequately discussed by simply talking about the technology rather than trying to find things IRL to compare to.
This is however first and foremost not a technical issue. It’s about responsibility and accountability, no one can duck those with “I thought the tech was enough, so I’m not accountable”.
I believe that however unlikely that HIBP (or HA code) would be a point of failure in security, you (as a person) do not want to be tried as accountable for whatever happens. (And I would never suggest you should take any such accountability)
There aren’t government regulations defining how the software is built. You can be any age to operate it. Home Assistant is free. And so on and so forth.
I must interpret this incorrectly. Frankly, there are tons of regulations on how software is being built and also being used. There are also several external services connected to HA that are also regulated involving such things as alarms. Depending on how you operate them, they will affect things like insurance.
This is why Zero Trust has become such a buzzword in recent years.
I hope you can see for some, this goes for external services also and some here have this thought including on HIBP. We’re bombarded with hearing “trust us, our service is on the safe side” and in the end, there several disappointments.
Firstly, “they” is just me (HIBP is a one-person community-centric project I alone run). Secondly, per the explanation above you never send your password so no, I don’t know what it is. And finally, no requests are ever logged beyond very short-term transient data as part of the underlying platforms it runs on so still no.
Can you see that the above statement requires trust to someone most people don’t know?
Which is all most of us are asking for, thank you! And thank you for taking the time to address this.
Since one of my posts had the honor of being included in your blog, let me respond.
I spent years in a career in Information Security and was influential at the national level in that role. Believe me, I’m OK with encouraging strong passwords. I agree that applications have a central role in that encouragement.
But it’s not good to make this an obsession. Whenever a developer thinks “I’m going to make those damn users do things MY way!” the application is going off the rails. It’s like the server in a restaurant saying “this place would run so much better if it weren’t for all those customers!”
True, we’re not paying customers. All the more reason you want to present a system which meets our needs and which we want to use. I’ve been involved in many different types of volunteer organizations, and developed applications used by tens of thousands of users. These applications had to be better and easier to use than the alternatives or they’d simply be ignored. “If you don’t like it, leave” is not a good philosophy if you want to accomplish great things.
One more point: Why does it take a firestorm like this to have a fix even considered, while the change which introduced the problem was slipped in with virtually no discussion at all? This seems backward. It should be easier to fix than to implement a poorly designed feature.
21 Likes
I’ve read your post again. I think the discussion should be kept as close to the development of Home Assistant as possible. Commenting on your blog will not benefit HA, especially as you are quoting people from here with cut n paste. Same thing with posting on twitter. Thats not where the HA discussion is occurring. If you really like HA as much as this community does, I hope you will take your time to discuss here and help an open source community thrive.
4 Likes
I believe it’s not OK to take names and quotes from this thread and post it in a separate blog. Each posts are taken out of context and the person who wrote his comment does not really get an honest opportunity to argue for their position in the issue.
As seen above, there are more than one question on mr Troys statement and his request to register on his blog to address this is unrealistic.
Therefore I find the blog post by mr Troy Hunt not very productive and contributing for this community.
Rather poor netiquette for those who unfortunately got involved. Adding to this, promoting the blog post on Twitter makes this even worse.
P.S I had to edit this message, as it was flagged as inappropriate. I’m looking forward to see why this was an inappropriate opinion.
5 Likes
People thinking that their home network, their private network, is 100% secure clearly don’t know much about IT security and the various threat vectors. Unless you’ve spent thousands on expensive intrusion detection kit and AI to detect changing threats then it’s not. Even then, it’s probably not.
Passwords are not perfect, but it is what we have today. It would be nice if all our IoT devices supported OAUTH2.0 or mutual SSL, but they don’t.
All this change is doing is ensuring you haven’t set a password that hasn’t been compromised, I really hope you don’t use these passwords elsewhere on the internet!!
The worst kind of password is an already compromised password. They are usually the first used in an attack. Passwords should NOT have to be complex (requiring upper, lower, symbol, number) as that isn’t anymore secure, in fact it’s less secure ( NIST Password Guidelines and Best Practices for 2020 (auth0.com), they just need to be long (preferably over 10 chars) and NOT be compromised elsewhere.
I welcome this change.
2 Likes
I fully agree. My name was used as well. It was just an observational opinion and now mr Troy, who has a business and a name to run “uses” my “hobby” opinion out of context.
Edit… I have thought about a bigger response to discuss what he wrote there… But I think I have nothing to gain with that. I use homeassistant purely as a hobby and just have some doubts about all this “forced education” on password usage. It’s not my cup of tea atm. Although I fully agree it is better to use secure passwords.
And to respond a little on my previous post, since the time homeassistant “added” this feature the extra traffic (api) to HIBP can filter all homeasssitant users out. Again, I have no other devices deliberately asking info from his platform. I think (personal hobby opinion) you do not have to be a very good data analyst to trace back the source of the request (IP address, hash of password being checked etc.).
But as Troy said… we have to trust him.
1 Like
And what I also thought lately… what if Microsoft would have just added this “feature” in a windows update? I think the world would have be too small and it would have made it into all mainstream media 
1 Like
Like software that you installed being automatically updated to suddenly do something with your personal data that you didn’t consent to? Yeah that’s quite a big threat to your security. Most of us in this thread thought that the devs would never do such a thing, that’s why we used it in the first place.
Ah, so you welcome the devs using your personal data in a way you didn’t consent to? So if in a weeks time they forcibly update your system to add your location to a publicly available map of all home assistant users will that be OK?
Fact is that this change overstepped the mark and people should have been given the choice whether or not they wanted to participate having been given all the facts of how it worked up front. Likelihood is that 99.999% would have happily accepted the change in those circumstances without issue.
Instead you now have a huge swathe of end users who feel violated and upset, and rather than trying to allay their fears most of the responses from ‘technical’ users, major contributors and senior devs has been sarcasm, derision and dismissal. That’s really poor by anyone’s standards.
16 Likes