Another risk imposed by this situation is the possibility of the third-party infrastructure
being compromised. This issue has been raised in the community by George Reese. Elon
Musk has confirmed that Tesla has plans to eventually release an SDK for third-party develop-
ers. It is likely that the Tesla-sponsored solution will include access to a remote API, a local
sandbox, OAuth-like authorization functionality, and a vetting process that draws inspiration
from the Apple App Store.
Perhaps Tesla cannot be explicitly and fully blamed for its customers handing over their
credentials to third parties. However, it is the nature of traditional password-based systems
that gives rise to outcomes and situations in which this becomes an issue. Rather than placing
the blame on car owners (who are in most cases broadcasting their credentials to third-party
applications unintentionally), the only way this issue can be remedied is by Tesla offering an
ecosystem in which the secure development and vetting of applications is defined and
encouraged.
Or Just Borrow Someone’s Phone
The Tesla iOS app stores a session token obtained from successful authentication with the
API in the Library/Cookies/ directory within the app, in the file called Cookies.binarycookies. As
shown in Figure 6-11, anyone with physical access to a Tesla owner’s iPhone can grab this file
using a tool such as PhoneView.
FIGURE 6-11. The Cookies.binarycookies file on the iPhone contains the authentication token
Anyone with temporary access to a Tesla owner’s phone can steal the contents of this file
to make direct requests to control the API functionality. The value of this session token has
been documented to be valid for three months at a time.
The probability of this issue is low because it requires physical access to the owner’s
phone. Note, however, that unlike with simple temporary access to a physical key (the role of
THE TESLA MODEL S 181