Reverse-Engineering Google Nest Devices
experimental-platform.tumblr.com
Reverse-Engineering Google Nest Devices
1–10 of 85 posts
Re: Reverse-Engineering Google Nest Devices
#2> with email and plaintext password
It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case).
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.
In case of a breach, that would be devastating.
Re: Reverse-Engineering Google Nest Devices
#3> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). 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. In case of a breach, that would be devastating.
SRP does not require the server to store either a password or a password equivalent.
https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
Re: Reverse-Engineering Google Nest Devices
#4> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). 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. In case of a breach, that would be devastating.
> 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 the password to be stored in plain text [4]. [Edit: though if you leaked HA1 that effectively becomes the credential]
Moreover, client TLS certificates would also fit the bill, as the client key is never transmitted.
Don't spread FUD if you aren't sure. If you don't know, don't say anything or say you don't know.
[1] http://srp.stanford.edu/ [2] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... [3] http://security.stackexchange.com/questions/15849/does-the-k... [4] https://en.wikipedia.org/wiki/Digest_access_authentication
Re: Reverse-Engineering Google Nest Devices
#5> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). 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. In case of a breach, that would be devastating.
> 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…
> Even HTTP Digest didn't require the password to be stored in plain text
As I understand it, it would still be required to store something that, if leaked, would allow anyone to create valid authentication responses? "HA1" effectively becomes the password, in that leaking it is as bad as leaking the password.
Re: Reverse-Engineering Google Nest Devices
#6> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). 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. In case of a breach, that would be devastating.
> 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…
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.
Re: Reverse-Engineering Google Nest Devices
#7Earlier 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…
> Even HTTP Digest didn't require the password to be stored in plain text As I understand it, it would still be required to store something that, if leaked, would allow anyone to create valid authentication responses? "HA1" effectively becomes the password, in that leaking it is as bad as leaking the password.
Right, edited.
Re: Reverse-Engineering Google Nest Devices
#8> you cannot operate the camera or switch your thermostat’s settings without Internet connection
This should say *remotely. I know it does in the paragraph before, but sometimes people only read bullets.
So is the complaint here I can't find out what data the device is sending back to Nest in whole? And contrary to the post, their Public API is pretty extensive.
Seems to me this is just another person with a concern around no local control/data retrieval. There is at least one other thermostat that has that.
Re: Reverse-Engineering Google Nest Devices
#9Earlier 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…
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.
Re: Reverse-Engineering Google Nest Devices
#10> with email and plaintext password It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case). 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. In case of a breach, that would be devastating.
> 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.