SoylentNews is people
SoylentNews
A WiFi connected tea kettle, the iKettle, was recently tested by Pen Test Partners and found severely lacking, spewing forth WiFi access codes for encrypted networks to unencrypted clients with just a few tricks. As reported by geek.com:
Ken Munro, a researcher at Pen Test Partners, recently took to the stage in London to show off what he and his co-workers discovered. Their mark was the iKettle, which was proclaimed "the world's first WiFi kettle" by its creators on the crowd-funding site Firebox.
He was able to trick the kettle into connecting to an unencrypted WiFi network just by giving it the same name as the encrypted network it was originally connected to and using a directional antenna to make sure the signal was loud and clear. Once they'd hijacked the wireless connection, Munro and his partner were able to convince the iKettle to spill the key for the encrypted network.
All it took was two little commands sent via Telnet. And being the helpful little kettle that it is, it even handed Munro the key in plain text.
Original Story: http://www.geek.com/news/connected-kettles-found-brewing-up-security-problems-1637249/
(Score: 3, Informative) by Hyperturtle on Wednesday October 21 2015, @08:52PM
You are mostly going to be fine.
I have a coffee maker that is capable of turning on and off via remote control, a clock/timer, time of day based on the position of the sun in the sky... and random noise on the power line that triggers the timer whenever the refrigerator runs while vacuuming.
Provided that stuff isn't also trying to phone to an alternate server (like, to auto-update themselves because they go to google by default or something), you will likely be able to keep control over it.
If you set up a non-routable local area network for them to speak on, all the better. Your own management of them can be via the server you mentioned, which can straddle both networks if you have two nics and limit the smarthome network to one of them; don't put a default gateway on any of the smarthome devices and you will be OK.
Unless they *require* access to the internet to update themselves. I'd hope that is what the server can also do for them and roll out patches or something or at least hold the files and you can launch them manually.
And.. the real money on my commentary is that I don't have experience with the ESP8266, but it looks like you're on the right track. I could be wrong, but I think your approach is right from a technical point of view.
(Score: 2) by q.kontinuum on Thursday October 22 2015, @06:08AM
You are right about me not being experienced with ESP8266, I didn't even flash a "hello world" LED blinker yet. However, from the specs it looks unlikely the device will start doing any auto-updates of its firmware. The device [github.com] has 96kB of data RAM + 64kB of instruction RAM only (Yes, it's a Harvard architecture). Compared to other CPUs at similar price-point (ATTiny/ATMega8), this is plenty, but for fancy auto-update etc., that would come as a surprise indeed.
For connectivity: I have a WiFi router which is the gateway to the internet. Any connected device would have outbound access to the internet. Routing for inbound connections would have to be configured manually on the router. The "Home server" is a NUC box running mainly as a KODI based media server. Together this would allow for a fancy user-interface with links to reciepes etc.
However, there is another option as well. I could have a small app on my phone, avoiding the neccessity of an additional server running on the NUC. The drawback is that the ESP needs to store timer information. It has an EEPROM of 4KB, so this is feasible as well, but it would increase the complexity of the firmware, which is presumably harder to debug than any code residing on my NUC.
The ESP can be configured as access-point. That way it could be accessible even without a router. I could connect to the "oven" AP and use an app to set the timer. But this means I have to connect to a different AP whenever I intend to program the oven. Also this would not allow for time-of-day programming, just for delay and duration, due to lack of NTP access.
If intended to build this as a product, the solution would probably be to offer AP mode to the user for initial configuration (stored in EEPROM), offer an app to configure access to the users router, and use this router-connection later for the oven to access an NTP server and for the user to program the oven. I'd need to add a hardware reset-button though to allow setting new AP and password, and also I'd probably need a small, cheap transformerless power-supply [microchip.com]. Actually I think its woth giving this some more thought, since this would be a wifi controlled power-switch witch could be applied to arbitrary devices.
Registered IRC nick on chat.soylentnews.org: qkontinuum