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.
Why would you assume troll haters would have any issue with this?
They have an issue with anything that isn't duckies and bunnies. They still want me to prove I actually own a Tesla :)
Appreciate the explanation of API and how it might be exploited/compromised.
How robust do you think the API currently is and how would you quantify the risks?
No, they don't have an issue with non duckies and bunnies. It's a question of credibility of the poster.
The real overall point isn't so much a commentary on Tesla, but on our move to an API-driven world. Security needs to be front-and-center, even in the early days when the API doesn't do much.
Having said that, the Tesla flaws have more serious consequences than the Hue lightbulb flaws (an attacker can just turn on/off the lights), but they are harder to exploit.
The key things an attacker could do (in order of badness):
1. Track your every move (potentially using the data to rob your house or something like that)
2. Significantly reduce the life-time of your battery and incur high power costs
3. Cause annoying "ghost" behavior in the car (e.g. open the sunroof while you're driving in the rain)
Technically #3 could be dangerous, but not directly. If you were surprised by your horn honking, the sunroof opening/closing, the lights flashing at the wrong time, it could distract you and being distracted is never a good thing while driving.
Hopefully, they will one day add more powerful commands to the API. But I hope never under this security model.
The ultimate irony of this is Elon's roots at X.com/Paypal, which certainly knew how to do authentication, even in the days when it was hard to get right...
I think the issue is that they didn't think about this in terms of external consumption, but instead only through the glasses of the mobile app. And that gets back to my point about the importance of API design in these "Internet of Things" devices like cars and lights.
APIs live long past their initial purposes.
Just to clarify in my own 'layman' language, tesla owners could use a third party website, at their own will give that website their login credentials, and then that website or anyone that has some form of administrative access to the os/db/app/web server(s) could see associate a car and it's owners login credentials and then use them for malicious purposes. Right. I agree, I think it's called Phishing whether for malicious intent or not. If you don't want this to be a problem for you, don't login to a website other than teslamotors.com with your teslamotors.com userid and password.
I think you should begin your remarks with something like 'a user that leverages the iPhone and/or Android App provided by Tesla is not at any risk with people potentially messing with their car. If you are willing to publish your login credentials on the internet, then you run the risk of other people controlling your car'. Unless I'm missing something here ...
I moved this to my regular O'Reilly blog. No idea why I posted it to G+. I never use G+.
I don't disagree about the importance of security, but I would not hail OAuth as the lasting solution. We have authentication-method-du-jour here in Internetland, as I'm sure you're aware. As fast as we harden our authentication methods, the faster the bad guys scramble to circumvent them.
That said, your point about making authentication revokable is on point and should be considered carefully by Tesla. Further, there is no reason for unencrypted http transmissions anymore. The issues don't evaporate when you use SSL, but they sure are less exposed to the casual listener.
Personally, I hate OAuth, but that's because it's more work to get right in settings where that extra work is putting a huge lock on a small door. In this case, I would concur that the door is worth the additional effort to lock well.
It's not about Phishing attacks. Not at all.
The Internet of Things is about a world in which all our "things" can talk to each other. Consider, for example, a scenario in which my home automation system knows when I am scheduled to wake up. It gradually turns up the lights using a sunrise color profile before the alarm goes off, and then begins warming up the Tesla Model S when I wake up.
That's what the API enables. The world is not/should not be limited to the approved iPhone app.
Here's an example of a value-added web site that leverages the Tesla API.
That web site need not be malicious. He could mistakenly store your user name/password (he says he doesn't, and I have no reason not to believe him). Or he could be hacked.
Your choices are:
a) Never leverage value-added applications/web sites
b) Take risks because of unnecessary flaws in the Tesla REST API
I want the value-added applications. That's what the Internet of Things is about. Tesla needs to fix this.
I am a vocal critic of OAuth and generally considered an OAuth hater.
Having said that, the Tesla Model S API is a poster-child use-case for OAuth. They should have gone that direction.
If I give my credentials to a third party site, and my horn starts honking, and I then change my password, is the token on the third party site still valid?
@Zero: yes, it is apparently good for up to 3 months after changing the password if the blog is correct that there is no revocation mechanism.
Have you notified anyone at Tesla about this? I am not too familiar with REST or the Tesla API but it does sound like you're bringing up a real issue. I agree that security is not the priority it should be for most applications, particularly for those on the web. I am still amazed that many financial institutions do not even offer 2-factor authentication for online banking & trading, for example. And of course, those that do, most people don't take advantage of them...
It particularly bothers me that Tesla chose to write its own security stuff. Personally I would feel better if they had used nothing but proven, open-source software.
It's not about Phishing attacks ... today. I could throw up a site, let's make it social media centric, say, you give me your credentials and I'll plot in NRT your location on map, in fact everyone's location on a map, and show those Model S's that are within 3(?) miles of you, I won't disclose any information about you, just that there is an S nearby. I'd make it an app for the iPhone/Droid and people that don't even own an S will download it just so they can go and see one if it's nearby. Maybe I'm a guy in Russia, hired by big oil/ice and once I've achieved critical mass, I 'attack' all owners registered with vented windows, max range charge, horn honking, etc. just to create some bad media hype about Tesla - would you consider that Phishing(probably not, no credit card)? What if Facebook created the app ... do you trust Facebook to secure that information appropriately? I go back to my original statement, don't share userid and password with *untrusted* sources regardless of how much value a website/app might add. I don't disagree that they could make adjustments to mitigate the risk you have suggested ... and at the same time, if you are willing to give out your creds then you run the risk associated with it. I'd personally rather have Tesla engineers building more cool new stuff than mitigating the risk you've outlined.
If done right, the tokens can be revoked and no harm done.
But not under the current API design. Under the current API design, your screwed.
I'd rather a solid architectural foundation for the software. Then build the features.
For all systems, not just Tesla.
@GReese, nice write up. One question though, my impression was that when the car is in Drive, the horn can't be honked, the lights can't be flashed, lock/unlock don't work.
Of course that would have to be regulated at the web portal level, not in the smart-phone app level, otherwise you could write code to speak to the REST api to get around that limitation. I've not tested this, but I'm curious.
The current API is not meant for public consumption. The items you clarify as "major" issues would theoretically exist if Tesla intended for 3rd parties to access the API. As it stands, the API exists only for 1st party Tesla apps to use.
Yes, I know the API has been reverse engineered.
Yes, I know there are several unofficial apps/services already in existence.
Yes, I know these things provide value to users.
But in the same way that someone constructing a house might temporarily use a staircase before the handrails are installed or the doors are locked, the API as it exists today is effectively for internal consumption of Tesla-authorized apps only. It doesn't need OAuth or cataloging of applications or revoking access YET, because Tesla doesn't intend for you to give your password to any other party. Any user that does acts at his own risk. And any user that finds that risk unacceptable can instantly nullify any negative effects by simply turning off remote access in the car.
Complaining about the lack of security for 3rd party apps at this stage doesn't seem to be fruitful, and worse, might be construed as scaremongering. We all know Tesla has scrambled to make the car and remote access functionality available to us in record time. I'm glad they've managed to cobble together a functional API that allows their own first-party apps to work, and it does so in a secure manner. There is no API weakness that allows a password to be stolen or a user to be impersonated. The only risk lies in a user giving a password to some other unauthorized party. What we have right now is a house with one lock and key. It works and it's secure. Tesla can never prevent you from giving your key to someone else, and pretending that this is a security flaw in the API is nothing more than highfalutin grandstanding.
So instead of complaining that all the bedrooms and bathrooms aren't finished yet, how about we just enjoy the fact that we're able to use the kitchen and living room, and wait and see what Tesla does if and when they do open up the API for public use?
@bcorob Nice answer, and I totally agree with it.
But GReese makes a good point that too many API's are built with security as a "feature" or, even worse, as an afterthought. Security has to be built-in and, more importantly, it has to be pervasive.
That said, I think Tesla will be alright.
And folks:DO NOT enter your Tesla account password in any other place than the Tesla website or the Tesla app. IT IS NOT SAFE! (Not ever.)
The whole "Tesla doesn't intent for 3rd parties to use the API" is an infuriating misunderstanding of the role of APIs.
If Tesla doesn't intent for 3rd parties to use the API, that in itself is a huge fail. There is a lot of value that can be added to the Tesla by third-parties, and the world is moving towards an API-driven reality.
APIs enable value creation beyond what the original vendor intended. That's a good thing.
In the end, your non-argument is the same as saying "I only intend my front door for me to walk through."
And regardless of Tesla's intentions, writing their own custom authentication was STUPID. They could have used OAuth and it would have served all purposes. Instead, they wrote a custom authentication that is poor for all purposes.
This topic is beyond my experience and understanding. However, you wrote Instead, they wrote a custom authentication that is poor for all purposes..
Is there any argument that the designers could make for doing it the way they did it that would somehow take into account that these people are far from inexperienced when it comes to internet security?
There are different levels of APIs. From what I can see here, Tesla's current API is a private one and by their very nature private APIs aren't intended for public consumption.
It seems to me that what you would like is for Tesla to publish a public API, and if/when they do so I would expect them to have designed one with security functions fitting its public nature. Until that happens however whatever people decide to do with the (reverse-engineered) private API must be seen as an unofficial hack that while quite possibly useful will necessarily have its caveats.
GReese, take it easy, dude ;-)
If you read bcorob's reply again, I'm sure you'll find that he says several times that the API is not intended for 3rd party use TODAY. That's how it is and that is not at all a huge fail. Remember that the iPhone started off without the AppStore? Remember that Facebook started off without an API?
We don't know what Tesla will do, but I assume (which is very dangerous, I know), that they will update their API over time and create a secure version of it, usable by 3rd parties.
Thanks for the clarification, that makes me feel better. Hopefully their public API will be designed more securely.
No. This authentication system is inferior to most anything else out there. There are two things they could have done to make it less secure that they, thankfully, did not do.
There is no such thing as a private API.
That's how it is and that is not at all a huge fail. Remember that the iPhone started off without the AppStore? Remember that Facebook started off without an API?
without an API
There is no such thing as a private API. Tesla maybe intended for it to be private. I doubt it. The whole token mechanism is highly suggestive that it was, in fact, designed for 3rd party usage (just poorly designed for that purpose).
REST APIs will be discovered. The Internet of Things will win out. You need to make them secure from the start.
An ecosystem of valuable tools is already evolving around these APIs. The genie is out of the bottle. It always gets out of the bottle.
GReese said: "There is no such thing as a private API."
I don't know which computing planet you come from or what type of programming experience you have, but that statement is so wrong that it made me cringe. Your credibility just sunk by 3.
I write about APIs for a living. The article is posted to O'Reilly broadcast for that reason.
You do know that the driver can turn off remote access at anytime from the car.
I agree with you that security should always be top concern.
Change your password monthly.
@Greese - My next comment is really not intended as an insult, so please don't take it that way, I'm just pointing out a flaw in your response to chrisdl.
There are a lot of people who write about things for a living who don't seem to have a clue what they're talking about. John Petersen comes to mind re: investing. I also recently read a book of essays by Bruce Schneier the security 'expert', which revealed to me that his status as an 'expert' is, at best, questionable.
So stating the fact that you write about something for a living is not all that convincing.
Private APIs have been around since the dawn of computing. I find it strangely cute that someone who purports to write about APIs doesn't know this.
As far as I can tell from this thread there is no security problem with the Tesla API, the security problem only arises if Model S owners start sharing their passwords with random strangers on the internet. Also, grass is still green.
GReese, thank you for the research and pointing this out. as the things you can do over the API right now are minor they might have not taken the apisecurity too serious and made something simple.
However this concept is obviously very weak and if you don't have the knowledge / Time / Money to do something, you have to use the most important software development skill of all... copy & paste :)
There are a lot of people who write about things for a living who don't seem to have a clue what they're talking about.
Yes. My point was not to say that my being a writer about APIs was in itself proof, but to arm people who want to judge with the information on which to look and see on their own if I know what I am talking about.
I am pretty sure my credentials speak for themselves on this matter.
Bruce Schneier is a security expert. He's very smart, especially when it comes to understanding human factors.
He doesn't do cloud security that well though.
Private APIs have been around since the dawn of computing.
The REST world is very different from your Win32 APIs.
I responded on your G+ post, but basically I don't see a problem with it as it is - yes, it would be nice if they used OAuth (heck, I would even like 2FA for a web site that gave OAuth tokens), but this was never intended to be used outside of their mobile app. They have and will continue to break apps that are built on it (I have been using it since the mobile app was introduced, and my app has been broken twice). People shouldn't be giving their credentials to third parties in any case, so all of the attacks that follow from that are just because people are being stupid.
I just don't buy the "private API" argument. In the world of the Internet of Things, there's no such thing as a private API.
And, as I noted above, the authentication mechanism is just dumb even if they could control the privacy of the API.
But the reality is they can't control the privacy of the API and there are already very useful 3rd-party tools on the Internet. Those will only increase.
I happen to know George professionally, and he can certainly defend himself, but some of you guys should really take 30 sec to check out Google or LinkedIn before calling into question someone's credibility on a topic.
The excuse that the APIs were never meant to be public is, at best, making excuses for Tesla. That's like saying I don't need locks on my doors because my couch and TV are not meant to be public either.
REST APIs will be discovered and reverse engineered, sites like Tripography or the 51 page thread over on the other Tesla site are proof of that. Its what geeks do for fun. Nothing necessarily malicious about it, its just the way things are. The APIs will (or will let) Tesla do some cool things, but the concept also carries some inherent risks which www should expect Tesla to manage.
The problem is that security always ends up being an afterthought. Devs will hack something together, which inevitably falls over at some point (often very publicly) and they are left duct taping some bigger hack in place.
If we stick to the house analogy, its easier and cheaper to pre-drill for deadbolts and pre-wire for an alarm while the house is being framed than it is after you have moved in.
I think that was George's point--put in something robust and scalable now while things are just getting started, rather than being forced to do it later when it will certainly be more expensive and may still not work as well as it should.
@GReese "There is no such thing as a private API"
Huh? That doesn't parse. My company builds and uses many private REST API's to have various software components talk to each other, within our product. REST is a nice standard way to communicate but of the 5-6 Restful API's in our main product, only one is public.
You've got your 15 minutes of fame, looks like:http://www.forbes.com/sites/reuvencohen/2013/08/22/newly-discovered-flaw...
First, congratulations, this issue has made national news and was quoted unattributed and out of context. Bah! Journalists trying to get a FAIL story on Tesla. But that doesn't mean it shouldn't have been written -- it's factually correct insofar as it warns of a set of specific actions that might compromise the security of a limited number of features (also disclosed in the original writeup).
That said, there is a certain amount of "don't take candy from strangers" implicit in the cited security vulnerability. If I opt not to give my credentials to value-added tools, the Tesla and it's mobile app will function with no security vulnerability. That's what I did -- I don't give out original login information to anyone but a trusted certifying authority. And by making that choice, I've denied myself use of some value-add sites. Sigh.
But I don't take candy from strangers. Even though there is a perfectly good technological solution to this, there is also an element of personal responsibility involved as well.
Why I'm posting this is not to make a feeble attempt to discredit @greese's argument because it is correct. However, characterizing "the safest car in the world" as easily hackable is fodder for an out of context negative news bite that does not understand nor contemplate the extent, seriousness or personal choices involved exposing this. My $.02
@GReese, your Auth points are very pertinent if this API is ever to made public, I'm not disputing that at all.
You've got your 15 minutes of fame, looks like
This isn't my 15 minutes of fame. If you think this is about fame, you need to follow me on Twitter. I do this shit all the time. Ask the OpenStack or vCloud teams in cloud computing.
I live and breathe APIs. And I've had more fame than this.
Omar, thank you for explaining my original reply about security in APIs more clearly (and with more words).
About George's credibility: George provoked on purpose by saying that private APIs don't exist, while he very well knows that they do. What he meant to say is that private APIs on the internet don't exist. Even that is arguable. Tech writers know that they have to be precise in what they write, so that there can be no wrong interpretation. George writes technology books and blogs. Next, George provoked again by telling bent about "[bent's] Win32 APIs". Hence, George's credibility is still down by 3. He's lucky it's not down by more or he'll have to appear in front of the credibility commission soon! ;-)
Yeah, as expected, the publicity around this will focus on the wrong thing -- what people should get is that they shouldn't be giving their credentials to third parties, instead you get people who don't know anything but have lots of readers to say "OMG, there is a flaw!".
There isn't any security flaw - it just doesn't do what you want, which is safely allow third party access. It wasn't designed to do that, so no problem, don't use it for that.
what people should get is that they shouldn't be giving their credentials to third parties
This is most definitely NOT the moral of the story.
A good API isn't usable with end-user credentials. Period. And it's not hard to do.
The moral of the story is that when you are building a connected device, you should think about the security of your API first. It's not about Tesla. It's not about giving your credentials to third parties.
All APIs get used well beyond the initial use cases. Bad ones break or create issues when that happens.
A good API isn't usable with end-user credentials.
I can think of:
OAuth (which requires end-user credentials to approve each client)
PKI (which quickly becomes a hideous mess)
Could you quickly sum up some other of the most prominent alternatives?
So, lets be clear, a "private" API only means that its not documented. This might be for any number of reasons like its functionality that the owner does not want to expose to 3rd parties or that it might simply not be ready for prime time yet or they might expect the API to change and don't want devs wasting time coding against the old API.
But you can generally still make calls to private APIs if you find out about them, they depended on security by obscurity. Apple is the poster child for this--they have myriad private APIs that you can still code against--and will get your app bounced if you want to sell through the app store.
The excuse that the APIs were never meant to be public is, at best, making excuses for Tesla. That's like saying I don't need locks on my doors because my couch and TV are not meant to be public either.
That is a completely erroneous analogy. It's not that Tesla's APIs are unprotected, it is that they are protected in a non-GReese-compliant manner. Which isn't a problem for anyone other that GReese.
The APIs in question are private APIs because they were never intended for access by third parties, not because third parties can't access them if they try really hard. And third parties that do try to use them won't get any access to the car anyway so it's not a security issue. It only becomes a security issue when car owners start passing their passwords around to strangers, for which I can only say, don't do that!
This is the poster child of a PEBKAC issue. Replace user and try again.
Maybe in the future sometime Tesla will provide third-party accessible APIs. They don't today and as far as I know never pretended that they do.
@jat -- @GReese does have completely valid points. His writeup was thoughtful and his defenses well crafted. I have no quarrel with what he's said and I believe it adds value. I also think you're correct in saying what people should get is that they shouldn't be giving their credentials to third parties but the problem with that statement is that directing people's take-aways is almost always the next best thing to suicide.
People read what they want into what you write and hear what they want in what you say. What @GReese said, if I understand correctly, is that there is a potential exploit affecting a constrained set of cases in the event a user takes certain actions (providing their credentials to someone other than Tesla). @GReese, correct me if I'm wrong on this.
In no case is question the credentials of the poster a good idea. That won't make a problem go away if one exists and it sure won't solve one.