I wrote up a critique of the authentication model in the Tesla REST API: https://plus.google.com/118015857958369316512/posts/URd647tAEsD
The troll hunters will hate it, I'm sure.
+1 mrspaghetti -- about 30 comments ago.
So you're argument is that I should not write about anything that isn't a glowing puff piece on Tesla?
I'm not paid to be in Tesla's PR department. I am an expert in cloud computing and API design and I write articles from time-to-time on those subjects. I'm also a Tesla owner. Made for a natural thing to do on my day off yesterday to write an article combining the two.
No, if you had been paying attention you would have noticed that my argument is you did a sensationalist hyperbole piece misleading people to think there is an actual security problem in the car, when in fact the only issue is that the car is lacking a feature that you'd rather it had. Third-party access to the car may mean the world to you, and would certainly have been nice to have, but you would have been better served actually asking for that instead of pretending its absence is an actual security issue.
I'm gonna disable API access to my girl and plead Tesla to go this route:http://www.policymic.com/articles/45905/motorola-introduces-password-pil...
@Greese, you are dead right in everything you wrote. I am amazed at the stupidity of some of the attacks here both on your person, and on the content of your message.
If my online bank had a security mechanism like this, I wouldn't worry. Because there is no way anyone could ever tempt me to give them my password. And if someone was STUPID enough to do that, shame on them and their loss, like several posters above have mentioned.
But the capabilities of the Tesla Model S API, and the incredibly USEFUL applications that could be developed on top of it, make it SO tempting that even people who have been warned about the fact that with access to their battery statistics, they also give a third party access to the GPS location of their car and the capability to unlock it, they still go ahead and willingly supply their username/password to someone they know nothing about. Volkerize search on my handle and the term OAuth to see me pulling my hairs out over that one.
Tesla should have gone OAuth with their API from the get go. I have looked up a profile on Linked In from someone who looked like he was lead architect for Tesla's software design team and contacted him about it months ago, but no reaction. I hope this gets their attentions.
This just in:
I am “expert” reviewer of banks, and I have to warn you that your money in the bank is not safe.
I have just discovered that if you give the userid and password of your online bank account to someone else, they can steal your money! That clearly means that banks security API is flawed: it allows other users to type in your credentials!
Let’s call Forbes and have them write a nasty article criticizing banks!
Actually, the authentication for most banks is fundamentally flawed.
There are very good reasons for allowing third-parties access to your bank accounts, Tesla account, or Twitter account. These entities should make sure they are designed in such a way that doing so does not create or at least minimizes the problems that can cause.
Twitter does that.
Tesla does not.
Do you not have a day job?
@sia, read my post and try to wrap your head around it. I have seen and spoken with many people on this forum, who would NEVER give the username/password of their bank account to anyone, that still have willingly given their Tesla username/password to unknown third parties who did nothing other than promise, cross their hearts hope to die, to not misuse that. Why? Because the third party offered a nice web app that shows battery statistics.
Tesla owners are being persuaded into giving their password away to unknown parties on a daily basis. This is actually happening! Volkerize it! Until now, these third parties have proven to be been relyable. But anyone who just finished "Programming 101" in community college can write such a web app and get Tesla owners to give up their password. If one of them misuses that trust and THAT gets picked up by the media, the shitstorm coming down on Tesla will be tremendous!
All it takes is one mediocre programmer that shorted on TSLA, and one more gullible Tesla owner
If one of them misuses that trust and THAT gets picked up by the media, the shitstorm coming down on Tesla will be tremendous!
The issue of street cred came up so I amazon'ed George for a refresher of what was written so far. It seems like your knowledge is seasoned in JDBC, MySQL, Java, REST, and cloud. In the reviews for your REST book, a reader mentions that examples were simple, focused around GETs only, and gave dangerous security advice. It's easy to find 1 bad review everywhere though. Moving on, I checked out your Cloud Architectures book, which focused only on Amazon EC2 and maybe 1-2 other services as an addendum. Reading the sample chapters, it was mostly command lines and general musings about what people think the word cloud means.
It seems to me you're good at the basic college student stack, had an early career change, got a MBA after a BA in philosophy, and became a technical journalist. Now, why this is important, is for each reader to interpret. If you did not mention your fame it would not be under attention atm.
Those technologies are great, but you wait for people to make something then criticize or assert improvements without thinking up clear examples (as mentioned by the readers who bought and reviewed your books). It's cool to be passionate and ambitious about theory, download and use popular web stacks, then talk about them. It's just fun and profitable though.
The internet of things is more than a CRUD. My radio can already GET waves, so what. Either you really believe that bringing REST to public attention would be revolutionary for consumers, or just wanted a name behind an idea, it isn't pushing ideas forward and even set back a legendary man's name (Tesla not Elon (okay Elon too)) back by 3, by stifling advancement with example-less writings. Those are just books, which you may not have total content control over.
In one of your blogs "The Good, the Bad, and the Ugly of REST APIs" it mentions that "chatty APIs suck." In your definition a chatty API is one where "any API that requirements me to do more than a single call to perform a single, common function." Aside from a grammar error no one has caught since 2011, you are not even considering Web Sockets, secure handshakes, or asynchronous behavior using the JVM's more modern techniques. Chatty APIs are the essence of "internet of things." When discussing such high concurrent processing in real-time and real-life, some more advance languages, practices, and thinking required. For example, Erlang is the basis for modern messaging servers, Scala + Netty to accept tiny incoming REST requests, or even Erlang as the HTTPS front-end. Why focus on such low-level options when a world of software on the level of Tesla S's ingenuity exists?
Grow old and think young. Software is a humble man's game.
In the reviews for your REST book, a reader mentions that examples were simple, focused around GETs only, and gave dangerous security advice. It's easy to find 1 bad review everywhere though.
And yet you willfully selected the one negative review in a sea of good to great reviews. If you actually read the content of that review with respect to the rest of the reviews, you'd know that particular reviewer clearly didn't know what they were talking about.
I brought up my expertise because people were asking me why I would write this article. I wrote this article because of my expertise in REST API design.
As far as verification goes, it's easy to verify my body of work. You had to try really, really hard to paint that work in a negative light. I will guarantee you will not find an informed critic who is aware of my work who won't concede I know what the hell I am doing with REST APIs and cloud computing.
The rest of your analysis is actually worse than your cherry-picking of a single negative book review above.
Thanks GReese for the information. I had wondered about the security and I do not know enough to check it out myself. I am glad you put this information out there.
@Greese...we have issues with some of your unreasonable statements such as giving an ICE car for a loaner is the biggest injustice perpetrated on Model S owners, even in the short term due to shortage of Model S loaners. One has to look at your assertion more closely to validate your present claim given your WAR off base remarks in the past before it can be taken seriously. I still want to know if you own a Model S in a pic taken with you as well as a well known landmark of your city, which I believe you claimed to be Seattle a while ago.
WAY off base
In the above post "Way off base" should read "WAY off base".
@ justineet -> troll hunter
@GReese....I don't know if you are accurate on this issue. I will leave that for folks in the computer field to analyze and give their opinion. But I know one thing for sure: some of your past statements have been very inaccurate or unreasonable....
But I know one thing for sure: some of your past statements have been very inaccurate or unreasonable....
You mention me complaining about giving out ICE loaners when Tesla is supposed to give you out Teslas. It's NOT acceptable. I did not, however, describe it as "biggest injustice perpetrated on Model S owner".
Actually, it probably is the biggest injustice perpetrated on a Model S owner. But that's relative comment. After all, there does have to be a "biggest injustice perpetrated on a Model S owner". I think that actually qualifies. In the scheme of things, however, it's not in itself a horror. It's just wrong and inconsistent with other luxury car maker lending policies.
Fortunately, that hasn't been my experience. I got a Model S 60 loaner when I took mine in.
So, basically, we have you disagreeing with one thing I said and now you're making a big unrelated to-do about in your troll hunting? You are indeed the king of the troll hunters.
Wow, a bunch of people who don't know what they're talking about got their panties in a twist because of a sort of critical article.
George laid out a case for why the API should have a better AuthN and AuthZ model. He called the shortcomings "flaws" and pointed out that their are other well established, simple ways of doing things, especially given that Tesla's API is not some completely off the wall brand new kind of thing. It's a basic REST API that allows an authenticated client to do some things. It's not exactly groundbreaking.
I think he is right to question why it was done this way and call out that it should be improved.
As for why it is the way it is, I'm sure you could only know if you were there at Tesla. I wouldn't doubt that lack of time and manpower at least played some part. Perhaps the performance review process at Tesla encourages developers to make homegrown stuff instead of look for existing solutions. Maybe the developers they hired only know embedded systems and they don't have experience with apps and stuff. Maybe they just did what they that was quick and cheap and intended to fix it later. Who knows. We don't. But why are you guys mad at George for discussing it?
@Greese....I am not making any judgement on this issue you raised...you may be accurate, semi-accurate or completely off base. If there is a problem it should be addressed. If you are semi-accurate, it should also be noted you are blowing the issue by some degree. But I will leave it to those in the computer field to the make proper assessment.....
First of all you came in here expecting "troll hunters", which by the way you are by hunting for trolls. Update slang.
I don't know how many ways to say that it's hard to be impressed when you want so bad for us to think it's a popping fresh idea. My mom literally brought up the same issue because the same thing happened. Software is a meritocracy. Being king of a fad will get you trend followers.
Your highly thoughtful Forbes readers agree, right?http://www.forbes.com/sites/reuvencohen/2013/08/22/newly-discovered-flaw...
Very similar idea to this article posted August 3rdhttp://www.digitaltrends.com/cars/can-your-car-be-hacked-car-hacking-thr...
Compared to yours on August 21sthttp://broadcast.oreilly.com/2013/08/authentication-flaws-in-the-tesla-m...
Similarities arise. Here's an interesting piece from yours:
"As noted above, the impact of any of these very real attack vectors is pretty much economic. I can target a site that provides value-added services to Tesla owners and force them to use a lot more electricity than is necessary and shorten their battery lives dramatically. I can also honk their horns, flash their lights, and open and close the sunroof. While none of this is catastrophic, it can certainly surprising and distracting while someone is driving."
I'll let your reviewers grade your ability to actually do one of those things. I just like how you totally qualify for Fox News and write for O'Reilly. Similarities arise.
the same thing happened to another EV*
Were I a developer on the Tesla team, my response would be:
(1) Log a short-term higher priority bug to reduce token validity time.
(2) Log a longer-term medium priority bug to introduce new API, intended for public use, with an authentication mechanism that allows third party use without user password disclosure.
(3) Make sure business is communicating to customers never to use their password with third party apps.
(4) Ask developers to hold off on third party apps until new API is released (knowing that not all will).
I have been following this for a while. The crux of the matter seems to be:
1. Current Tesla API was not architected for third parties to access - which clearly bothers GReese
2. If a user gives his/her Tesla username and password to a third party today, they might expose themselves to attack. - which GReese points out.
I am not bothered so much by 1. I don't at all care if my devices can talk to one another. In fact I'd rather they don't. I am saying this as a digital design engineer for the last 16 years. We have always talked about the Internet of things. Anyone remember how our toilets were supposed to transmit the health status to the doctor directly whenever you did your business? This model does not work. If everything is to be connected, everything gets more complex, more prone to failures, more expensive to fix, and more prone to hackers. We don't need these to talk to one another, let them mind each others business silently, and yes, with a little more human effort.
Regarding 2: I understand there are "dumb" users who'd give their credentials to someone they don't know, after all, in their mind, their Tesla credentials are not exactly their bank account credentials (hopefully), so why worry?
Well, it turns out, there IS a valid reason to worry, thanks to the OP who pointed this out.
Maybe he was 'reaching' a bit with his title, may be even to get some limelight. Heck, I have fallen prey to that myself, especially when one discovers something like this. I think we should give credit for that, and move on.
My 2 dollars.
@GReese Have you actually tested to see if the tokens remain valid after changing your password on the web site? It seems that you are just asserting that they are valid for three months because the cookie duration is set to three months. It is entirely possible that the cookie is no longer valid on the server side after you change your password. It depends what is in the cookie and how they manage it.
@GReese Ok, I just did the experiment as can anyone else on this list -- I used the app on my iPhone then I went to the web site and changed my password. I went back to my iPhone and restarted that app. It worked at first, but after about a minute or so it suddenly brought me back to the login screen. Obviously something on the server side invalidated that token.
So, in summary - the API is fine for its intended purposes. Don't give you password to anyone and if you do just change your password.
I've seen mixed results on this issue.
By the way, even if the tokens reliably expired on the server after a password change, it doesn't alter the point of the article. It just minimizes one of the issues I pointed out.
Update on Token Expiration
It seems people are getting mixed results on token expiration. My best guess is that there's some caching thing going on here.
I noted this in the article and its implications.
Basically, it means of the issues I have noted:
1. It cannot safely operate over any channel but a trusted SSL connection (minor)
2. It requires the sharing of the user's password with third-parties (major)
3. No mechanism exists for cataloging applications with active tokens (significant)
4. No mechanism exists for revoking the access of a compromised application (major)
5. The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)
#4 should be altered to be:
Only an inconsistent blunt-force mechanism exists for revoking access to a compromised application (moderate)
And actually, #5 should be updated to be:
5. The automated expiration of tokens in 3 months along with the blunt-force token revocation mechanism encourages applications to improperly store your email and password (significant)
I've updated the O'Reilly community piece for #4, but did not bother with #5, but that's all I control. I have notified the O'Reilly editors for the Programming piece.
I also posted this on your G+ post.
Ok, I just ran the test. I started my temperature data collection, which uses cached tokens and makes a request to climate_state every 10 seconds. After it started and asked me for my password (the previous token was no longer valid), I let it run for a bit. Then I went to My Tesla and changed my password. On the request 2:40 after the one before changing my password, it prompted me for my password again. A second trial resulted in a 2:20 delay.
When I did a similar test when I first reverse engineered the API, my recollection was that it was within 20 seconds. So, I could have been lucky before on a couple of tests (perhaps less load as there were few users at that time), or they could have added some latency -- for example, I wouldn't be surprised if they added an LDAP replica to cope with load, which would be consistent with increasing the latency before a token is invalidated. Even with increased latency, I think this is perfectly effective for revoking access from people you have given your password to.
I still think your statement over-reaches, as changing the password is no more blunt than what the user did in the first place -- they gave their password to a third party, so I would think even unsophisticated users would think changing their password would have the desired effect of revoking their access, which it does. Why should they expect a third-party program to behave differently than if they told you personally their password, and then changed it when they didn't want you to have access (knowing that also changed it for everyone else they had given their password to)? Or if they gave you a key to their house, and decided to rekey the lock because they didn't want you to have access any more?
Absolutely, I agree that it would be great if they used OAuth and allowed granular access control. I just don't see it as big a deal as others which have been doing exactly the same thing for a long time -- including mint.com, who asks you for your bank credentials but has the chutzpah to warn against giving your mint.com credentials to anyone. I think your valid complaint reduces to "They didn't use a mechanism that safely allows third-party access".
I think @GReese has done a great dis-service by being an alarmist for this minor issue. The average Joe reading his blog, or the Forbes article can’t tell if @GReese’s claimed risks are actual security flaws, or just a consequence of giving out a user’s password.
The solution is simple: Don’t give your password to strangers! End of the story.
His article and follow-up words raise questions about his motivation. It may be ego, or financial gain. For example, I am sure he wouldn’t mind, if as a result of all this publicity, he gets a job to redesign the Tesla mobile API. :-)
@jat: Your conclusion is fair enough, but not the whole store.
I would summarize it as: "They didn't use a mechanism that safely allows third-party access for an API that provides such useful functionality to Tesla owners that they are already sharing their username/password with third party developers frequently even though they know this is inherently unsafe."
The desire of Tesla owners for applications using the functionality of the API is legit. The motives of, lets say, all existing third parties that create those applications are legit. So that raises the interesting question: are those third parties (and the Tesla owners that create their "demand") wrong in using the API, which not "officially published" and clearly not designed for third party access? Or is Tesla wrong in having designed this API this way to begin with?
I would agree that the term "flawed" is too strong in that Tesla (obviously) didn't mean this API to be public. They were, however, naive in not recognizing the strong desire for it, and have to an extend even ignited the fire by referring to the Tesla as an "iPad on wheels" and emphasizing often that the fact that so much functionality could be added to this car via software is a game changer. It's a game changer in the automotive world for sure. But by 2013, it is common practice in many other area's. And it is what "early technology adopters", which many Tesla owners are, are very much used to.
The demand for a public API could have been foreseen, and it would not have been difficult at all to set the API up like that from the get-go. For IT architects that deal with designing future-proof APIs on a daily basis, it can be frustrating to see that a company that is such a technological front runner in so many ways, dropped the ball on this API like this. Especially when their CEO stood at the very roots of "internet security" (i.e. PayPal).
@sia: "A job to redesign the API"? The OP, (and yours truly, and thousands of others, including the current Tesla developers) could "redesign" it in an hour, implement it in a few days, have it tested and in production in a few weeks. After all, the API itself is fine, it is only the security model on top of it that needs to change. The fact that you suggest that there's "a job in it" indicates your level of experience with these matters.
I just sold my company and have quite enough on my hands. I'm not job hunting.
Also, if I were looking for exposure, I would have shopped the article to a forum with greater exposure and gotten paid for doing so.
I write about APIs for a living
I write APIs for a living. I trust TMC is taking security more seriously than GReese's critics. This particular security issue is not my concern. From reports of a particular application I suspect a SQL injection* vulnerability that can be exploited by anyone who has access to the touch screen (e.g. valet).
If it is a SQL injection vulnerability, it could be possible to gain root to the OS running this particular application. SQL injection is one of the most common means that hackers use to covertly invade servers.
I haven't tested to see if my Model S is vulnerable because I don't want to brick my car (highly unlikely but still...).
S85 - Blue & tan, TP, AAS, VIN #136XX
I'm thinking I'm probably not running SQL.
@pebell: I have treated your comments with respect, but see that you cannot reciprocate. You have no idea about my background and expertise. Your responses are completely irrelevant, this time and last time you responded.
@Greese: Fair enough, I overstated that joke. But I wish you would correct the misconceptions that your article has created.
I find it possible that an application that does searches runs MySQL.
@Rte66 - I would be extremely surprised that a) they are running SQL on an embedded system and b) they would pass unscrubbed data from the UI to it.
I'm sure they know about Little Bobby Tables :).
If you are worried about vulnerabilities in the car itself, I would be more concern about vulnerabilities in pieces they source from others that have been shown to have vulnerabilities -- for example TPMS receivers that blindly broadcast data received from the sensors in the tires to the CAN bus. Unless they want to start building their own processors for things like that, all they can do is select vendors who are careful themselves.
Some new reading on hacking cars:
Hackers Remotely Kill a Jeep on the Highway—With Me in It ...http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/?mbid=so...
I sure hope Tesla has good hackers to test against the bad ones :)