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

Reverse-Engineering Google Nest Devices

experimental-platform.tumblr.com

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Reverse-Engineering Google Nest Devices

#11

Post by kuschku »

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription.

This is exactly one reason why using "Cloud" services for long-living things, like Hardware, is a great risk.

When Google shuts down Google Reader, we can all migrate to an alternative easily.

When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on.

Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating.

The reaction of the people on the recent case where Nest went down itself, and people were left without heating, fits well as context for the following excerpt from "The Sorcerers Apprentice" (1797, Johann Wolfgang von Goethe):

    Herr, die Not ist groß!      Sir, my need is sore.
    Die ich rief, die Geister    Spirits that I've called
    werd ich nun nicht los.      My commands ignore.

Re: Reverse-Engineering Google Nest Devices

#12

Post by jedberg »

kuschku wrote: post #11

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. Thi…

> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on.

No, they are left with a normal programmable thermostat with a nicer interface than most.

> Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating.

This is not true. The Nest operates perfectly fine without internet.

> The reaction of the people on the recent case where Nest went down itself, and people were left without heating

That's not exactly what happened. What happened was there was a bug in the software that had an issue when their server became unavailable. But this could happen with any device that is controlled by software. And even if they had a totally open and accessible API right on the device, this problem still would have happened.

I don't like the fact that they lock up the data, but we should probably try to stomp out the myth that the device is totally useless without their servers.

Re: Reverse-Engineering Google Nest Devices

#13

Post by outside1234 »

kuschku wrote: post #11

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. Thi…

The Nest thermostat actually works without an internet connection. You just can't control it remotely without one (or get updates). If Nest vanished, we'd just have what many people currently have, a disconnected thermostat that is never updated.

Re: Reverse-Engineering Google Nest Devices

#14

Post by drdaeman »

jakobdabo wrote: post #10
jimktrains2 wrote: post #4

Earlier quoted context omitted.

> Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server. That's not true at all! SRP[1][2] allows the server to not have the plaintext password ever, even during account creation. Kerberos' KDC doesn't know the plain-text password either[3]. Even HTTP Digest didn't require th…

Speaking of HTTP Digest, I like its concept, easy to implement and supported by all major browsers. Unfortunately MD5 is broken, I wonder whether there is a newer standard using SHA2 or BCrypt for example.

TLS client certificates are even easier, don't require consuming party (the server) to know private key at all, and are reasonably secure.

They are not working for end users, because no browser ever cared about those (UI/UX-wise), but I don't see any reason to not use those for automated access by IoT stuff. Generate keypair on-device, send a CSR, ask user to open browser and check if device's theirs (by comparing a conveniently formatted fingerprint - as a picture and/or series of dictionary words, not hex digits), sign and use if everything's good.

Re: Reverse-Engineering Google Nest Devices

#15

Post by Retric »

jimktrains2 wrote: post #9
Retric wrote: post #6

Earlier quoted context omitted.

If password X is hashed to Y, and you store Y that seems ok. But if you directly check if the client transmits Y then Y is just the new password. At a minimum you should be hashing whatever the client sends and comparing that with the hashed password. PS: Not that most developers should do this by hand.

I don't understand your point. Even if the client sends HASH(password), that effectively becomes the credential. That's where HTTP Digest is less successful (as was pointed out by a sibling and I went D'oh for not remembering). > At a minimum you should be hashing whatever the client sends and storing that. That's a very narrow view of how to authenticate. SRP and client certs certainly don't work that way.

Yes, there are many many more secure schemes out there. By minimum I meant minimum.

The point was what the client sends should not be what's in the database or easily reversible from what's in the database. I guess the larger point was you can't trust clients in any way shape or form.

Re: Reverse-Engineering Google Nest Devices

#16

Post by supergeek133 »

jedberg wrote: post #12
kuschku wrote: post #11

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. Thi…

> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. No, they are left with a normal programmable thermostat with a nicer interface than most. > Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. This is n…

Yeah I'm not sure where/how that started. A firmware update broke the battery charging, device died, and cut off the heat. That's a software problem, not a thermostat problem.

If you bought a Nest, and never connected it, that problem would have never impacted you.

Re: Reverse-Engineering Google Nest Devices

#17

Post by jimktrains2 »

jakobdabo wrote: post #10
jimktrains2 wrote: post #4

Earlier quoted context omitted.

> Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server. That's not true at all! SRP[1][2] allows the server to not have the plaintext password ever, even during account creation. Kerberos' KDC doesn't know the plain-text password either[3]. Even HTTP Digest didn't require th…

Speaking of HTTP Digest, I like its concept, easy to implement and supported by all major browsers. Unfortunately MD5 is broken, I wonder whether there is a newer standard using SHA2 or BCrypt for example.

HTTP Digest also makes HA1 (hash stored on the server) the credential, so if it were leaked, then you could still authenticate as the user.

Re: Reverse-Engineering Google Nest Devices

#18

Post by cptskippy »

jedberg wrote: post #12
kuschku wrote: post #11

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. Thi…

> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. No, they are left with a normal programmable thermostat with a nicer interface than most. > Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. This is n…

> No, they are left with a normal programmable thermostat with a nicer interface than most.

Ehh... I don't think the Nest Thermostat is completely programmable from the hardware itself. You can definitely set temperatures and toggle between heat/cool, heat, and cool; but I don't think you can edit the schedule. Even if you could, I don't think I'd want to. The hardware's UI is beautiful but UX leaves much to be desired.

Re: Reverse-Engineering Google Nest Devices

#19

Post by supergeek133 »

cptskippy wrote: post #18
jedberg wrote: post #12

Earlier quoted context omitted.

> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. No, they are left with a normal programmable thermostat with a nicer interface than most. > Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. This is n…

> No, they are left with a normal programmable thermostat with a nicer interface than most. Ehh... I don't think the Nest Thermostat is completely programmable from the hardware itself. You can definitely set temperatures and toggle between heat/cool, heat, and cool; but I don't think you can edit the schedule. Even if you could, I don't think I'd want to. The hardware's UI is beautiful but UX leaves much to be desir…

You can edit the schedule from the thermostat (at least v3 I think).

But scheduling interfaces are hard.

Re: Reverse-Engineering Google Nest Devices

#20

Post by nitrogen »

jedberg wrote: post #12
kuschku wrote: post #11

> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription. Thi…

> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on. No, they are left with a normal programmable thermostat with a nicer interface than most. > Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating. This is n…

But this could happen with any device that is controlled by software.

Not devices that are designed to be independent and tested for proper function when disconnected.

Post reply on HN