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

[loganss]

It would have been nice to contact Tesla with a detailed explanation of the perceived vulnerabilities and at least give them a chance to address them than posting to the internet (blog, website, fbook, twitter,... doesn't matter it's all the same on the internet) first. Especially with Tesla being on a roll in the press, most people that see how the media operates could see from a mile away that this topic was going to attract lots of attention. I'm all for critizing Tesla but this seems like they got blindsided.

Sadly people read headlines, come to a conclusion about the contents of the article, then start spreading the panic/misinformation. By the time they're corrected the damage has been done. Sometimes reversable sometimes not.

I'm in the camp that refuses to give my credentials away to third party apps, not even banking apps since a lot of times they're just plain bad, so I'm not worried about this "flaw".

 

[brianman]

I haven't given my Telsa login information to any third party. So am I still at danger of my car being hacked while I'm driving as some of these articles that source your article are saying?

Which article says that?

Tesla Model S potentially vulnerable to hack attempts: Report Latest News and Analysis on Car Tech in India - Thinkdigit

"Most of the controls seen here can also be controlled via the browser based portal from Android and iOS smartphones"

The picture shown includes the entire front dash as well as the accelerator and brake pedal.

I think it's pretty clear what they're suggesting.

 

[aviators99]

By the way, prior to this thread being started, people were using my web page Tesla control every day. The last time it was used was at 11pm EDT on 8/21! :-O

In case anyone thinks otherwise, I use best practices on the web page, and you don't have to worry about vulnerabilities past the point of trusting me (as I've stated before). Of course it is perfectly reasonable to not trust me--simply because you don't know me. But I do promise that I'm trustworthy, FWIW.

 

[brianman]

I don't read them that way, but I am accustomed to reading security-related articles in technology publications.
I'll note again, this was published in a technology blog.

Which gives them an air of authority, ripe for misquoting by the low quality "journalism" that is digested in "sound bites" by the average person.

 

[deonb]

Oh, good grief. At this point, I can only conclude that you must be deliberately missing the point.

I'm not. I'm conceding all your technical arguments. They're 100% accurate. I disagree with where you leave things though:

Flossing with razor blades.

You're leaving the responsibility at the end user. The problem I have is that end users don't know when things are dangerous.

I've been to a Tesla showroom today, and asked them again when they're bringing out a Windows Phone app. Sure enough, again they recommended the 3rd party app created by "some guy".

If Tesla can't get rid of the razor blades, they should at least stop explicitly telling people to floss with them.

 

[markwj]

You're leaving the responsibility at the end user. The problem I have is that end users don't know when things are dangerous.

I've been to a Tesla showroom today, and asked them again when they're bringing out a Windows Phone app. Sure enough, again they recommended the 3rd party app created by "some guy".

If Tesla can't get rid of the razor blades, they should at least stop explicitly telling people to floss with them.

I guess that I do fall on the side of the line towards personal responsibility. I am not sure if it is really that users are not aware it is dangerous (a lot has changed over the past decade in that respect). More that, as has been shown by countless studies, they'll do whatever necessary to get what they want. If what they want is the other side of that 'Ignore Warning' button, they will in general press it. Such is human nature.

So, yes, if there was to be an exploit of this, I would put responsibility both on the end-user and on the service that got exploited. Not on Tesla for not facilitating that third party service with a suitable API.

I don't think that the Tesla showroom salesman is aware/concerned of the effects, and liability, of this. To some extent, the salesman here is acting like a user - following human nature of pursuing gratification at the expense of risk. I would be very surprised if there was a central edict in Tesla that recommended any third party product/service. Certainly, my experience with OVMS backs that up - no way that Tesla corporate would recommend it (or a Tesla legal approve it), but a salesman unofficially saying 'go for it' - sure. Is that right? No. Is that the way of life nowadays? Certainly.

Last point: I am thoroughly in favor of an open API ecosystem. I just think companies should be able to have the choice whether they want to participate in that or not. MIT vs GPL (let's not go there ). I do believe that companies which choose to participate will be the ones that succeed.

 

[nspollution]

It would have been nice to contact Tesla with a detailed explanation of the perceived vulnerabilities and at least give them a chance to address them than posting to the internet (blog, website, fbook, twitter,... doesn't matter it's all the same on the internet) first.

That's what journalists do.

I am not a journalist. I am a technology writer. I identify issues in technology and raise them for a larger discussion.

Especially with Tesla being on a roll in the press, most people that see how the media operates could see from a mile away that this topic was going to attract lots of attention. I'm all for critizing Tesla but this seems like they got blindsided.

Really? A company with a market capitalization in the billions got blindsided?

I published in a technology forum about a real issue. I am not a PR agent for Tesla. I was not disclosing a vulnerability that needed a fair shot at shutting down prior to disclosure.

- - - Updated - - -

Which gives them an air of authority, ripe for misquoting by the low quality "journalism" that is digested in "sound bites" by the average person.

That's not my issue.

 

[AnOutsider]

That's not my issue.

Recurring theme.

 

[nspollution]

Recurring theme.

The other option is for people to remain silent out of fear of being misquoted.

That would be the greater disservice.

 

[heems]

Technology writer or not, this still smells of sensationalism. I'll prove it:

There is a site I am building that adds value added services to your bank. It takes your money and move it around to generate 24% interest while also let's you track all of your finances, tax optimizes all your income and spending, and to boot it gives plans for you and your family's financial independent for the next 3 generations. Really, it's wonderful.

Now when you go to my site please enter you bank account, login credentials, and answer a couple security questions and you will be under way.

Internally, we interface with your bank's "API" - also technically known as posting to site and screen scraping - and all is well. My site is considered a 3rd party tool and it works with any bank that has an online API - i.e. provides online banking.

Nspollution - you have 2 choices. You are a) as a "technology writer" going to have to write an article on oreilly that every bank has a flawed API or b) be known as a hypocrite.

Which one is it? I thought so. No clicks in either eh?

 

[dirkhh]

And there we go. Wall St Cheat Sheets
Our friend George has been downgraded to a senior engineer - no more exec...

 

[brianman]

(1) You're leaving the responsibility at the end user. (2) The problem I have is that end users don't know when things are dangerous.

(1) As it should be.
(2) How far do you want this childproofing of adult things to go?

 

[FlasherZ]

That's what journalists do.

I am not a journalist. I am a technology writer. I identify issues in technology and raise them for a larger discussion.

No, you sensationalized it. It's not a public API, it was reverse-engineered. It was designed with the mobile app in mind, not a third-party ecosystem of app developers. You positioned it as a critical flaw in Tesla technology, when it works perfectly for what it was designed.

Now, you can take issue with the fact that they didn't make an architectural choice to open up the API at the same time and use OAuth for token-based authentication, but that's a completely different matter than "OMGWTF! TESLA CAN BE HACKED!" The former would be expressing concerns with an architectural decision, the latter is just sensationalism to promote a blog.

The minute Tesla publishes the REST-like API for public consumption by third-party providers but doesn't include OAuth, I'll stand with you and trumpet the message. Until then, it should be responsibly handled as an architectural decision you disagree with, not the sensationalism that it currently reads as.

As a result, you've given the impression that the Tesla Model S is a compromised product, when in fact it is not. That irresponsibility lies within your lap, due to the way you explained an architectural/design choice in the context of your particular ideology. Sorry, you won't convince me that is not wrong. A responsible technology blogger would modify that blog post and make it clear that he did not intend for it to be taken the wrong way, and that you understood that the particular API was non-public and not intended for third party, but that you believe -- in your ideology -- that it should be open, that it should use authentication tokens. *That* I agree with, and with you I would stand in that regard. I would not stand with you in calling the Tesla Model S a compromised product, as you have done.

 

[nspollution]

Technology writer or not, this still smells of sensationalism. I'll prove it:

There is a site I am building that adds value added services to your bank. It takes your money and move it around to generate 24% interest while also let's you track all of your finances, tax optimizes all your income and spending, and to boot it gives plans for you and your family's financial independent for the next 3 generations. Really, it's wonderful.

Now when you go to my site please enter you bank account, login credentials, and answer a couple security questions and you will be under way.

Internally, we interface with your bank's "API" - also technically known as posting to site and screen scraping - and all is well. My site is considered a 3rd party tool and it works with any bank that has an online API - i.e. provides online banking.

Nspollution - you have 2 choices. You are a) as a "technology writer" going to have to write an article on oreilly that every bank has a flawed API or b) be known as a hypocrite.

Which one is it? I thought so. No clicks in either eh?

This is an idiotic false choice.

Is it really expected that, in order to be intellectually honest, I'll write about EVERY SINGLE API THAT EXISTS?

That's just plain absurd.

I have a Tesla, I care about it's API. Someone asked me why I thought it was a flawed API, and I wrote it up.

It's really that simple.

- - - Updated - - -

And there we go. Wall St Cheat Sheets
Our friend George has been downgraded to a senior engineer - no more exec...

Depending on how you do the translation, a Russian article appears to have promoted me to CEO.

You win some, you lose some

- - - Updated - - -

No, you sensationalized it. It's not a public API, it was reverse-engineered. It was designed with the mobile app in mind, not a third-party ecosystem of app developers. You positioned it as a critical flaw in Tesla technology, when it works perfectly for what it was designed.

It's not sensationalized, it is 100% accurate and the conclusions follow from a basic premise in the belief in an "Internet of Things", connected and interoperable. If you don't grant that premise, then the conclusion doesn't follow. If you grant it, the conclusion follows.

Just because you don't agree with the premise doesn't make it sensationalized.

- - - Updated - - -

I would not stand with you in calling the Tesla Model S a compromised product, as you have done.

I didn't call the Tesla Model S a compromised product. I said the authentication scheme was flawed. Significant difference.

In the end, I don't care if you "stand with me". Writing isn't about everyone agreeing with you.

As I said before, if you grant my premise, then the conclusion follows. Reasonable people may disagree with the premise. I'm going to write a follow-up article on that subject. But given that my premise is reasonable and the conclusion follows from the premise and the facts in the article, there's nothing intellectually dishonest or sensationalistic about it.

And I'll again point out that, if sensationalism and exposure were my objectives, the O'Reilly community forum is not the ideal place for such an article. I easily could have had other outlets that would have PAID ME for the article. I just wrote this one up in response to a question from THIS FORUM in a technology blog appropriate to the question.

 

[FlasherZ]

It's not sensationalized, it is 100% accurate and the conclusions follow from a basic premise in the belief in an "Internet of Things", connected and interoperable. If you don't grant that premise, then the conclusion doesn't follow. If you grant it, the conclusion follows.

I don't grant your premise that every API is intended to be public, multipurpose, and requires third-party ecosystem level engineering. I would argue that very few practical IT architects would. Your opinion is your opinion, that I will concur with, but your positioning in the blog assumes that everyone believes in your ideology, when, in fact, you're hearing here that it is not the case from the majority of people who have commented.

Just by way of example, I don't believe that the API's used between Postfix, Amavis, and ClamAV on my mail server should have to be full-blown public API's with OAuth tokens. Your "premise" does, which is rather impractical at best.

Again, I would point out that a responsible technology blogger would point out that Tesla's API is non-public, intended only for the mobile app right now, and that before the API is published that the authentication issue would need to be addressed. It's simple to say that we're LUCKY to be able to use the API that was reverse-engineered to get more value out of our cars. You could simply point out that right now it's suitable only for direct interaction with Tesla only, and not third-party ecosystem applications. That would close the loop.

You leave the reader with the impression this is a published, publicly-consumable API, and that the product is flawed. Your poorly-written piece will likely not serve you very well without clarification. Because of this, Tesla may be forced to positively declare this a closed API by pushing out an update to the mobile apps and API server so that it truly is closed -- e.g., no more ability to use the data in other ways -- until it can appease your API religion and publish it with OAuth. That would be a real shame, all because you refuse to clarify your ideology vs. the reality, just to carry bigger press.

 

[ElSupreme]

Even if Tesla implemented OAuth. There is still the EXACT SAME SECURITY FLAW that you claim is eliminated.

A third party asks for your credentials. You hand them over. Third party runs does whatever it wants. OAuth doesn't stop that. Look how many twitter accounts get hacked every day!

Your assumption that OAuth prevents your credentials from getting to a 3rd party is absurd. Sure the way OAuth is supposed to work is the 3rd party sends you directly to Tesla to do the authentication, but most people don't know that, or don't care enough to see that it really happens.

There is no security if you hand over you username and password. And people will do that regardless if OAuth is implemented or not.

 

[FlasherZ]

Your assumption that OAuth prevents your credentials from getting to a 3rd party is absurd. Sure the way OAuth is supposed to work is the 3rd party sends you directly to Tesla to do the authentication, but most people don't know that, or don't care enough to see that it really happens.

Let's not cloud the issue with poor implementations. Please tell me how a properly-implemented OAuth service offered by Tesla, and used by the Tesla API, would leave users' cars vulnerable to credential-sharing. Properly implemented OAuth capabilities would prevent me - as a car owner - from having to share my credentials with third parties that want to collect data or take actions on my behalf.

EDIT: I think I'm know where you're going. I do agree that it would not stop someone who stands up a bogus mobile app from asking for your username/password and using that to their advantage. That's possible anywhere, though, to include banking and commerce sites. I'm talking about cases where third party providers, say TeslaStats.example.com, want to collect and process data about your car, on your behalf. In that case, you wouldn't have to share your username/password with TeslaStats.example.com. I'm thinking of a case where the TeslaMS project is stood up as a service provider instead of a software project, collecting data on behalf of many owners and offering statistics to them without requiring the owners install node.js, mongodb, etc.

You have to assume that Tesla is going to implement OAuth in such a way that it achieves the intended behavior -- i.e., they will close off the original "/login" behavior such that passing your username/password no longer works, they will stand up an OAuth service that handles tokens properly, and they will publish the API such that it uses those tokens and authorizes use accordingly.

After all, if I published a web page called "FacebookStats.com" and promised to give you access to summary information about your FB posts, and I asked for your username/password -- there is nothing that defeats that stupidity if you hand me your credentials. There's not a design choice in the world that can fix that.

You can make it harder -- for example, OnStar requires the use of two-factor authentication (a 4-digit PIN) when you want to lock/unlock/start your car through its app. But if the user discloses that PIN too, there's nothing you can do.

The properly-implemented OAuth capability would make third-party apps secure when used correctly. Tesla could reinforce this by publishing the API, and associated notice to customers that no third party should ever ask for your MyTesla username/password.

There is no solution for social engineering / disclosing username/password to third parties (EDIT or fake applicaitons.

With that said, would you mind sharing your TMC username/password with me? I'll give you useful statistics on your TMC activity!

 

[nspollution]

Even if Tesla implemented OAuth. There is still the EXACT SAME SECURITY FLAW that you claim is eliminated.

No, it does not.

#1 With OAuth, you never give the third-party web site access to the low security, high sensitivity email/password pair. That web site never, ever sees it. It simply receives an application-specific token that's registered with the core API provider.

#2 The token can be used only for very specific operations needed by that app. For example, a graphing and monitoring app could be granted read-only rights.

#3 If a third-party site is compromised, OAuth enables you to revoke only that third-party site's token. You do not need to change your password, and you don't impact other third-parties that are interacting with your web site.

A third party asks for your credentials. You hand them over. Third party runs does whatever it wants. OAuth doesn't stop that. Look how many twitter accounts get hacked every day!

#1 The point of my article wasn't that OAuth stops third-party web sites from being hacked. It was that the current mechanism requires a) you to hand your user name/password over to the third-party and b) provides no control over what happens should that third-party get hacked

#2 A hell of a lot fewer accounts get hacked now (as a percentage) than before the implementation of OAuth.

 

[ElSupreme]

Let's not cloud the issue with poor implementations. Please tell me how a properly-implemented OAuth service offered by Tesla, and used by the Tesla API, would leave users' cars vulnerable to credential-sharing.

You have to assume that Tesla is going to implement OAuth in such a way that it achieves the intended behavior -- i.e., they will close off the original "/login" behavior such that passing your username/password no longer works, they will stand up an OAuth service that handles tokens properly, and they will publish the API such that it uses those tokens and authorizes use accordingly.

After all, if I published a web page called "FacebookStats.com" and promised to give you access to summary information about your FB posts, and I asked for your username/password -- there is nothing that defeats that stupidity if you hand me your credentials. There's not a design choice in the world that can fix that.

You can make it harder -- for example, OnStar requires the use of two-factor authentication (a 4-digit PIN) when you want to lock/unlock/start your car through its app. But if the user discloses that PIN too, there's nothing you can do.

The properly-implemented OAuth capability would make third-party apps secure when used correctly. Tesla could reinforce this by publishing the API, and associated notice to customers that no third party should ever ask for your MyTesla username/password.

There is no solution for social engineering / disclosing username/password to third parties.

With that said, would you mind sharing your TMC username/password with me? I'll give you useful statistics on your TMC activity!

What you are saying is basically my point.

nspollution is upset because 3rd party apps require you to enter your username and password to access the API. OAuth allows you to give Tesla your Username and password, and they give a token to the 3rd party app. Which protects you from the 3rd party. He wants to idiot proof the app ecosystem.

But most people have no idea how OAuth works. They don't look to make sure they are entering their information on a Tesla site, not a WindowsPhone App site. They just put in their username and password when asked.

OAuth allows app builders to build proper secure apps. I doesn't solve the problem of apps asking for your credentials and misusing them. And giving your credentials is the problem that has been identified.

OAuth only works for app developers that want to make a secure app, and people that are looking for a secure app and know how OAuth works. Most people have no idea how it works.

Devise any strategy you want. If I tell my wife my login and password, guess what. She has control of my car (well the sunroof, AC, horn, charge port, and lights)!

I am not saying what is happening now is secure, just that OAuth isn't the solution to the problem that has been explored.

 

[nspollution]

I don't grant your premise that every API is intended to be public, multipurpose, and requires third-party ecosystem level engineering. I would argue that very few practical IT architects would. Your opinion is your opinion, that I will concur with, but your positioning in the blog assumes that everyone believes in your ideology, when, in fact, you're hearing here that it is not the case from the majority of people who have commented.

First of all, it is a premise. You can call it an ideology, but for the purposes of this article, it's a premise. assumes that everyone [believes -> grants] your [ideology -> premise].

Second, in the forum to which I posted (an O'Reilly technology blog), I would venture the majority would tend towards the world view of an interconnected world of devices built around consumable APIs. That is certainly the feedback I am getting from that crowd.

Just by way of example, I don't believe that the API's used between Postfix, Amavis, and ClamAV on my mail server should have to be full-blown public API's with OAuth tokens. Your "premise" does, which is rather impractical at best.

No, it doesn't. I am specifically relating to a worldview based on the ubiquitous interconnectivity of devices base on RESTful principles. The Tesla falls into this category, the other things do not. Furthermore, even within the Tesla, there are characteristics that distinguish intra-component communications (they look more like a Postfix API) and external communications (which is what the REST API is, regardless of intention).

Again, I would point out that a responsible technology blogger would point out that Tesla's API is non-public, intended only for the mobile app right now, and that before the API is published that the authentication issue would need to be addressed.

I don't agree with that worldview. Why would I argue about it?

- - - Updated - - -

What you are saying is basically my point.

nspollution is upset because 3rd party apps require you to enter your username and password to access the API. OAuth allows you to give Tesla your Username and password, and they give a token to the 3rd party app. Which protects you from the 3rd party.

But most people have no idea how OAuth works. They don't look to make sure they are entering their information on a Tesla site, not a WindowsPhone App site.

OAuth allows app builders to build proper secure apps. I doesn't solve the problem of apps asking for your credentials and misusing them.

Devise any strategy you want. If I tell my wife my login and password, guess what. She has control of my car (well the sunroof, AC, horn, charge port, and lights)!

I am not saying what is happening now is secure, just that OAuth isn't the solution to the problem that has been explored.

You can't prevent all possible attacks, but you can take reasonable precautions to make sure they don't happen.

Tesla failed spectacularly here. There is a standard out there that would have been a reasonable precaution and they failed to follow it. As a result, the API is open to a wider variety of attacks than it would be had they taken reasonable precautions.