Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wanted to spy on my dog, ended up spying on TP-Link

kennedn.com

Post reply on HN
Print view View original

11–20 of 181 posts

Re: Wanted to spy on my dog, ended up spying on TP-Link

#11

Post by borski »

radlad wrote: post #10
hleszek wrote: post #9

Earlier quoted context omitted.

Home Assistant is making more and more sense to make your own fully local and private home automation system.

Absolutely. I've been using Home Assistant for around 6 years now and it's absolutely amazing for tying hardware from varying ecosystems together. Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.

> Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.

And if they haven’t, you can pretty trivially write your own and distribute it through HACS (I’ve got three integrations in HACS and one in mainline now)

Re: Wanted to spy on my dog, ended up spying on TP-Link

#14

Post by mtlynch »

micah94 wrote: post #5

So we're at the point that finding hardcoded admin passwords is no big deal.

It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow.

This is the way most apps work if they have a default password the user is supposed to change.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#15

Post by xp84 »

hleszek wrote: post #9
xp84 wrote: post #7

Earlier quoted context omitted.

I mean, given that it's updated after setup with the normal flow, I'm okay with it. The thing I've most been convinced of in the past 5 years of building as much 'iot/smart home' stuff out as possible in my house is that nearly every vendor is selling crap that has marginal usefulness outside of a 'party trick' in isolation. Building out a whole smart home setup is frustrating unless it's all from one vendor, but the…

Home Assistant is making more and more sense to make your own fully local and private home automation system.

I love it! But my setup has a lot of sharp edges. It's a combo of things where the "standards compatible" way to connect to HA lacks things like camera control, by dastardly vendors like Chamberlain who basically killed HA support for spite, and finally, by having to use Google or Amazon for voice assistants.

My #1 wish would be for someone to build a HA-native voice assistant speaker. I'd pay $100 each for a smart speaker of the physical quality of the $30 Google Home Mini but which integrated directly with HA and used a modern LLM to decide what the user's intent was, instead of the Google Assistant or Siri nonsense which is like playing a text adventure whose preferred syntax changes hourly. I'd pay that plus a monthly fee to have that exist and just work.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#18

Post by bri3d »

mtlynch wrote: post #14
micah94 wrote: post #5

So we're at the point that finding hardcoded admin passwords is no big deal.

It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This is the way most apps work if they have a default password the user is supposed to change.

The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device.

Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline with no "cloud" or other access, or "lock in"; the app just uses the device secret to authenticate with the device locally. Then the user can set a raw RTSP password if desired.

This way unprovisioned devices are not nearly as vulnerable to network-level attacks. I agree that this is Not Awful but it's also Not Good. Right now, if you buy this camera and plug it into a network and _forget_ to set it up, it's a sitting duck for the time window between network connection and setup.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#19

Post by hank808 »

Gualdrapo wrote: post #17

Got one for my house but what really annoyed me was that I wasn't able to set a fixed IP for it

On your dhcp server (probably your router/gateway), statically assign (reserve) the camera's MAC address to the IP that you want it to have. Sometimes called MAC binding.

Re: Wanted to spy on my dog, ended up spying on TP-Link

#20

Post by yannyu »

bri3d wrote: post #18
mtlynch wrote: post #14

Earlier quoted context omitted.

It's a hardcoded default password, not a permanent backdoor. If I'm understanding the post correctly, the user changes it as part of the onboarding flow. This is the way most apps work if they have a default password the user is supposed to change.

The device should ideally have some kind of secret material derived per device, like a passphrase generated from an MCU serial number or provisioned into EEPROM and printed on a label on the device. Some form of "enter the code on the device" or "scan the QR code on the device" could then mutually authenticate the app using proof-of-presence rather than hardcoded passwords. This can still be done completely offline w…

AT&T routers, for example, ship like this. There's a wifi network and a wifi password printed onto the device.

But that also means then that often anyone with physical access can easily get into the device. The complicated password provides an additional layer of illusion of security, because people then figure "it's not a default admin password, it should be good". The fundamental problem seems to be "many people are bad at passwords and onboarding flows", and so trying variations on shipping passwords seem to result in mostly the same problems.

Post reply on HN