TIPPragma: no-cache
Expires: Mon, 1 Aug 2011 09:00:00 GMT
Connection: close
Access-Control-Max-Age: 3600
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, HEAD
Access-Control-Allow-Headers: Content-Type
Content-type: application/json
[{"success":{"username":"8f7ab27c-6c04-4378-b0b1-dcd4fd468815-0}}]The user will be notified that the connection was successful, as shown in Figure 4-17.
From now on, the SmartThings Hub can command the Philips hue bridge by always
including the value of 8f7ab27c-6c04-4378-b0b1-dcd4fd468815-0 as the authorization token
in the request. For example, it can issue a POST request of the form /api/8f7ab27c-6c04-4378-
b0b1-dcd4fd468815-0/groups/0/action to turn off all the lights, as shown in “Controlling
Lights Using the iOS App” on page 16.
The hue bridge accepts incoming connections on port 80, which does not use encryption. This can
allow a malicious device on the local network to launch ARP spoofing attacks and steal and proxy the
username. However, this architecture is based on a design from the hue team. The SmartThings Hub has no
choice but to use unencrypted communication, because the hue web server communicates only in clear
text.Recall from Chapter 1 that the earlier implementation of the hue app utilized the MD5
hash of the smartphone’s MAC address as the username. We know that was a bad idea,
because it allowed any local device to cause a perpetual blackout. The SmartThings Hub does
not commit this error. The SmartThings team should be complimented for designing this
diligently.
INTEROPERABILITY WITH INSECURITY LEADS TO...INSECURITY 111