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.