Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Authentication flaws in the REST API (if you give 3rd party your private login info)

This site may earn commission on affiliate links.
So, the API in the original iPhone SDK was public? The one hacked together by the community by jail breaking the first iPhone 2Gs, then reverse-compiling header files from the objects and resources?

I have a different definition of public. I call that an unauthorized API, or a private API, because I don't think the owner of the API should be held responsible for <B>flaws that only appear when the API is not used as intended</B>.

Would you hold Microsoft to that same standard? 90% of Windows security exploits are in private API's. So should we just disregard those and say Windows is perfect because hackers aren't using the API as intended so no flaws actually exist in Windows? No? So why hold Tesla to a different standard?

Whether the API was initially intended as private or not, it doesn't matter now. Tesla knows the API is out there. They've not done anything to close it down. They've promoted apps based on it. If they change it now, users will get upset if Tesla breaks their apps. And trying to then blame the users for using those app in the first place isn't going to win Tesla any popularity contests either, especially with Elon going on and on about how he's a fan of open source and against proprietary patents. It may not have been public initially, but it sure has to be treated like that now.

The whole principle of designing an API for private use is anyway flawed. Inevitably the shortcuts you take by thinking it is private comes back and bite you in the butt. Somebody out there is going to reverse engineer it and now you're stuck with a badly designed API that you now have to support in perpetuity. Not only that, but by keeping it private, you don't have a lot of eyes looking at it, which means you're going to make mistakes. You should just design every API in the first place as if you're going to publish it on google.com's homepage.


So I wholeheartedly agree with nspollution. The Tesla REST API is flawed. Badly.

Do you realize how little work it will be for a hacker to exploit this? All they need to do is create a really compelling app or site that gives users a few cool features (track battery life over time, historical location, whatever), spend a little money promoting it, and they'll easily get a few 100 users signing up. But why would a hacker go through that trouble and expense? Oh, let's say for a few thousand 50% out of the money puts that will become in the money the moment you have a 100s of cars misbehaving in unison from an exploit that will be so well published it will make the current "Short Tesla" movement look like something created by Sal Demir. At that point all the blame in the world for users being so "stupid" as to give their usernames and passwords to a 3rd party site doesn't help you with TSLA trading at $70.

There shouldn't be an API that takes a username/password in the first place that will enable this.

Usernames/passwords lead people into a false sense of security. They think by providing credentials, it somehow protects them - especially if they can see a visible side effect. (Logical fallacy: 'Site X' takes my username & password and displays my account balance. Only my bank would know my account balance. Hence 'Site X' is my bank.).

Case and point - there are WiFi hotspots out there that use a pre-shared WEP or WPA key. You go to the front desk, you get a key that you can use for some time. The purpose of the key is to protect the hotspot from users that don't pay for the service. HOWEVER, that's not what users think - they assume the key will mean the network they connect to is legit. Except that it so doesn't mean that. Try the following experiment the next time you're in such a hotspot: Bring up an open WiFi hotspot, and see if anybody connects to you - chances are nobody will. Now enable authentication and use the same pre-shared key from the front desk and route traffic to their real network. Your hotspot will become very popular very quickly. It's the easiest MiTM attack in the world, all because users think that because they entered a password they must be safe. And a MiTM attack on a hotel hotspot trivially gives you a credit card number.

I know it's mindboggling to us, but there are users out there who bought a Model S, but doesn't know you can change the % of charge (was in another thread posted earlier this month. I forget which.). That same user isn't going to think twice about entering his credentials into some mytesla.com site and use a cool map to see where he's been in the last few months and how much electricity he used to get there.

The way out for Tesla is to provide a different mechanism as soon as they can, publish it as wide as they can, and retire the existing one.


My background: I've created and shipped 100s of API's that are used by thousands of developers and hundreds of millions of end-users daily. The most well known (by end-users) are the Wireless API's that has shipped inside Windows since XP SP2 until today. If you've used a wireless network on a PC, you've used something that was built on an API that I designed. And yes, I've also gone through the whole cycle of patching a security exploit that I caused (in a private API nonetheless) - it's not a good feeling, but it's something I've learned from. Tesla still has a LOT to learn.
 
Sadly, I expect them to shut it down before 2014 because of the way your concerns were raised. So thank you for that. Not.

Considering the number of Model S's on Microsoft campus, all by Microsoft employees with Windows Phones, and Tesla Bellevue and Seattle employees actively demonstrating the Windows phone apps as part of selling the car... yeah, that will cause a legal issue (and seriously bad press) if Tesla were to take away that API access now.

They can of course scramble quickly to release a Windows Phone app to avoid that, but fixing the API is less work.
 
Seems the arguments fall into two categories: A) the API is flawed because it can be exploited or B) the user is flawed for giving away their user name and password to a non-tesla entity.

My vote is that B is the root cause and that's where the accountability resides. If a user is going to share their digital identification it's all bets off IMHO. It's indeed sensationalism to blame the API provider that it can possibly be exploited. Whose API is not susceptible to exploitation? No one's including expert George's.
 
Sometimes all this tech talk does is to scare us innocents.....just sayin'.

I think, in this case, it should. At least a little. NOT in the sense that there's some kind of immediately exploitable hole that will crash your vehicle.

But instead that there are real things you need to consider when you leverage third-party tools that aren't true of other, better written environments out there. I think any environment is flawed if it requires you to have this kind of special knowledge.

Right there is what I'm talking about. I reassured myself that I'm ok using the Tesla app and you come back with a confusing answer that made me say "Wait. What....?" until I realize you're talking about third-party tools again. In my opinion it's irresponsible and it makes me seriously want to retitle this thread :

"Using the Tesla App is perfectly ok, just don't give anyone else access to your credentials"
 
Deonb, can't quote your long post. But two big issues identified:

1) 90% of Microsoft exploits are in private APIs.

Not sure where you get this. Can you provide a reference? This is not my experience, but maybe terminology getting in the way. P.S. I've got more than 30 years of experience in that field, with the last 13 as CTO of a network security company, and lead the security response teams with tens of thousands of networks under our management.

Anyway, the answer is yes I would hold Microsoft to the same. If they had a private API intended for one purpose, and third parties re-purpose that API for another purpose it was not suitable for, then something got exploited by the third party use that would not be exploitable with the original use, then I would neither call the API flawed for its original purpose, nor hold Microsoft accountable.

2) Hacker website.

Using OAuth would have zero affect on that scenario.

The hacker would still collect the authentication tokens for hundreds of cars, and once he has enough could launch the attack.

The flaw here is giving control to untrusted third party websites, not the authentication mechanism.
 
Would you hold Microsoft to that same standard? 90% of Windows security exploits are in private API's. So should we just disregard those and say Windows is perfect because hackers aren't using the API as intended so no flaws actually exist in Windows? No? So why hold Tesla to a different standard?

When people talk about Windows security exploits in APIs, they are talking about things like memory overruns, old code that is not supposed to be run but will run if you call it, etc. They are not talking about people giving their credentials to others.

My background: I've created and shipped 100s of API's that are used by thousands of developers and hundreds of millions of end-users daily. The most well known (by end-users) are the Wireless API's that has shipped inside Windows since XP SP2 until today. If you've used a wireless network on a PC, you've used something that was built on an API that I designed. And yes, I've also gone through the whole cycle of patching a security exploit that I caused (in a private API nonetheless) - it's not a good feeling, but it's something I've learned from. Tesla still has a LOT to learn.

Your background is truly impressive, and there's a chance I've crossed paths with you in person over the past several years. But I'm sad to see another case of a Microsofty spreading FUD regarding a competing product; even though it is with good intentions.
 
Considering the number of Model S's on Microsoft campus, all by Microsoft employees with Windows Phones, and Tesla Bellevue and Seattle employees actively demonstrating the Windows phone apps as part of selling the car... yeah, that will cause a legal issue (and seriously bad press) if Tesla were to take away that API access now.

They can of course scramble quickly to release a Windows Phone app to avoid that, but fixing the API is less work.

First, I can speak with some authority that it would not cause a legal issue.

Second, if they fix the API the Windows Phone app will still stop working, so I don't know what you're suggesting.
 
Seems the arguments fall into two categories: A) the API is flawed because it can be exploited or B) the user is flawed for giving away their user name and password to a non-tesla entity.

My vote is that B is the root cause and that's where the accountability resides. If a user is going to share their digital identification it's all bets off IMHO. It's indeed sensationalism to blame the API provider that it can possibly be exploited. Whose API is not susceptible to exploitation? No one's including expert George's.

I have to agree with this.

If I give away my user name, password, and other authentication credentials for my bank account to an unknown third party, I shouldn't be surprised when the money gets transferred out.
 
I am still waiting to hear some concrete recommendations from George (nspollution) on how Tesla could make things better. Something more than just "use OAUTH". Something practical too, given that they don't have an army of programmers to crank stuff out like Twitter and Facebook. What makes the community surrounding this API so special is the incredible willingness to share more than just opinions.

Use OAuth *is* a concrete recommendation. It fixes everything, and it doesn't take an army of programmers. It's actually quite simple.

- - - Updated - - -

If a user is going to share their digital identification it's all bets off IMHO. It's indeed sensationalism to blame the API provider that it can possibly be exploited.

How many times do I have to point out that users do this all the time with systems much more sensitive than Tesla? Do you use Quicken? Mint.com?

Who will get the blame when Useful 3rd Party Site X gets hacked and Tesla passwords/tokens are leaked and a bunch of Tesla owners start experiencing problems as a result.

Tesla.

Whose API is not susceptible to exploitation? No one's including expert George's.

This is about an architectural flaw that makes it easy to exploit the Tesla API through normal use cases. I am not aware of any such flaw in the API I designed. You are welcome to analyze it and point out any you find.

- - - Updated - - -

Using OAuth would have zero affect on that scenario.

The hacker would still collect the authentication tokens for hundreds of cars, and once he has enough could launch the attack.

The flaw here is giving control to untrusted third party websites, not the authentication mechanism.

OAuth would have a huge effect on that scenario.

Specifically, the minute any exploit to the third-party site was detected, Tesla would be able to de-authorize all tokens just for that third-party site.

Often, the fact that the tokens were compromised is detected long before the attackers have the time to analyze the data and exploit it.

You can't stick your head in the sand and say people should not use third-party web sites. It happens all the time with all kinds of apps like Twitter or devices like the Philips Hue. And it will only become more common.

The proper response is to be safe in that world, not pretend that it doesn't exist.

- - - Updated - - -

If I give away my user name, password, and other authentication credentials for my bank account to an unknown third party, I shouldn't be surprised when the money gets transferred out.

How can you call something that is normal and has value to users the problem (the users) instead of taking basic and customary defensive programming procedures (Tesla)?

You don't use Mint.com or Quicken or any other third-party banking tools?
 
Well, that won't stop people from blaming you when the API gets taken away.

They can blame me if they want. But that would be fairly childish. Blame the messenger, etc.

- - - Updated - - -

Considering the number of Model S's on Microsoft campus, all by Microsoft employees with Windows Phones, and Tesla Bellevue and Seattle employees actively demonstrating the Windows phone apps as part of selling the car... yeah, that will cause a legal issue (and seriously bad press) if Tesla were to take away that API access now.

They can of course scramble quickly to release a Windows Phone app to avoid that, but fixing the API is less work.

I don't see how they actually accomplish the shut down of the API without getting rid of the mobile apps, but there is no legal issue associated with dumping the API. Companies do that all the time, even with much more at risk.
 
BOTTOM LINE

There are many of you who believe this is a non-issue because one should not use third-party, value-add services. That's an honest opinion, but I definitely don't agree with it.

However, a lot of the thread beyond arguing that one point has been attacks on my motivations and suggestions I should not point out what, from my also honest opinion, is an architectural flaw. That's absolute nonsense, and it's a very dangerous approach to criticism. I thoroughly reject that.

If I believe that the Tesla API is architecturally flawed, it is my responsibility as someone who works in the API field to comment on it. Even if the target is a car I love driving every day.

I believe in a world in which third-party systems add value to devices like the Tesla and the world is better for their interconnectedness. I believe people building APIs should be designing for that world. In that world, the Tesla API fails to protect its users in spite of the fact that it would have required no extra effort to have solved the problem right from the start. To me, that's a flaw. And so I wrote about it.
 
First, I can speak with some authority that it would not cause a legal issue.

Advertising something and then not providing it after it's sold is not illegal? I'm not so sure about that. I'll defer to your judgment. But either way, the bad press issue remains.


Second, if they fix the API the Windows Phone app will still stop working, so I don't know what you're suggesting.

Yes, for 10 seconds. If you replace it with something that is official the app developers will jump on it. Do a week-long overlap of the two, and there'd be no interruption in service.
 
Yes, for 10 seconds. If you replace it with something that is official the app developers will jump on it. Do a week-long overlap of the two, and there'd be no interruption in service.
Tesla has nothing ready to replace it. And has no capacity to work on something like this. There are so many other things they need to be working on and are constantly behind on.
There are two options.
a) They ignore the noise and keep doing what they are doing, releasing an official API/SDK some time 2015.
b) Or they shut this thing down, say "the mobile apps will work again once we have finished designing the new API and new apps have been developed" and we all are screwed.
I'm hoping for a). I think we can increase the likelihood of a) by stopping this pointless discussion. Yes there are flaws. Yes Tesla needs to fix them. There is no imminent danger unless people do stupid things (like hand out their credentials to third party sites).
 
You don't use Mint.com or Quicken or any other third-party banking tools?

No, no, and no. I don't give out copies of keys to my house to other parties. Why would I give someone keys to my bank account or brokerage.

BOTTOM LINE

There are many of you who believe this is a non-issue because one should not use third-party, value-add services. That's an honest opinion, but I definitely don't agree with it.

I believe in a world in which third-party systems add value to devices like the Tesla and the world is better for their interconnectedness.

I don't believe in this at all. I believe in limited interconnection, and in some cases disconnection. Interconnectedness introduces more threat vectors. I believe that systems should be sandboxed or air gapped. I believe that many people are unwittingly willing to network all their systems for the sake of convenience, which increases attack surface dramatically.

I believe people building APIs should be designing for that world. In that world, the Tesla API fails to protect its users in spite of the fact that it would have required no extra effort to have solved the problem right from the start. To me, that's a flaw. And so I wrote about it.

Fair enough. It's an honest philosophical difference. I realize that I sound like Commander Adama:eek: when I say I don't believe systems should be connected or networked.
 
Use OAuth *is* a concrete recommendation. It fixes everything, and it doesn't take an army of programmers. It's actually quite simple.

Ok, lets work in that direction for a while. How about we stand up an OAUTH server and document how we did it, just to demonstrate to Tesla how easy it is. This would make it easier for them to implement something similar.

What I am interested in is implementation recommendations. You appear to have experience doing this before so:
- which open source OAUTH server would you recommend we use?
- How should we do capacity planning to ensure it can serve ~100,000 owners?
- What other surrounding components are needed to get the system fully functional?
- realistically, how long would this take and how many man hours of work?
 
Two things:

#1 Tesla should have a software engineering team that basically works on things like the API and the mobile apps. This is not some huge drain in resources.

#2 Handing out credentials to third-party sites to leverage an API is not stupid. Having an API that puts people at risk when they do so is stupid.