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

nspollution said:

I did a write-up on the Tesla REST API authentication model: https://plus.google.com/118015857958369316512/posts/URd647tAEsD

Click to expand...

Feedback: The "What's an API?" sidebar should include explaining what the acronym stands for.

nspollution said:

I did a write-up on the Tesla REST API authentication model: http://broadcast.oreilly.com/2013/08/authentication-flaws-in-the-tesla-model-s-rest-api.html

Note: moved this to my O'Reilly blog (no idea why I put it on G+)

Click to expand...

Nice write-up, and I agree that OAuth makes good sense for this.

However, given the current situation that the API is not public and all third party uses are non-authorised, presumably from Tesla's point of view, the third-party flaws don't affect them.

* It cannot safely operate over any channel but a trusted SSL connection (minor)

Both existing official Apps do.

* It requires the sharing of the user's password with third-parties (major)

There are no authorised third parties.

* No mechanism exists for cataloging applications with active tokens (significant)

I am sure it exists on the server side. It is interesting that they don't invalidate the tokens when the user changes their password.

* No mechanism exists for revoking the access of a compromised application (major)

Not really sure what internal mechanisms they have.

* The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)

Again, not sure how the Tesla Apps do it. Do they ask you to re-authenticate after 3 months, or store credentials?

I really hope that Tesla make a public version of this API, and they address the third-party Apps concerns when they do it. My concern is that the longer they delay, the more unauthorized apps and services appear. Those websites that ask you to enter your credentials are truly terrifying.

Authentication flaws in the REST API

just read this... and thought the members involved in the API could give their thoughts on below

Article states the following flaws -
This model suffers from the following flaws:

• It cannot safely operate over any channel but a trusted SSL connection (minor)
• It requires the sharing of the user's password with third-parties (major)
• No mechanism exists for cataloging applications with active tokens (significant)
• No mechanism exists for revoking the access of a compromised application (major)
• The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)

http://broadcast.oreilly.com/2013/08/authentication-flaws-in-the-tesla-model-s-rest-api.html

Sigh. This makes the same very basic mistake as the other post. Let me put it bluntly: This API is not an official API and is not to be used by third-parties.
It was reverse-engineered from the iOS/Android apps. It does not facilitate any access for third-parties, so using the user credentials is not a major security issue, and the lack of "applications with active tokens" is entirely by design.

If you hand your user credentials to any third-parties for accessing the API, you're likely in violation of whatever user policy Tesla has, and you're being plain reckless.

zeron said:

Sigh. This makes the same very basic mistake as the other post. Let me put it bluntly: This API is not an official API and is not to be used by third-parties.
It was reverse-engineered from the iOS/Android apps. It does not facilitate any access for third-parties, so using the user credentials is not a major security issue, and the lack of "applications with active tokens" is entirely by design.

If you hand your user credentials to any third-parties for accessing the API, you're likely in violation of whatever user policy Tesla has, and you're being plain reckless.

Click to expand...

Yet lots of people are doing just that (there are at least three 'services' that have solicited users here and that require you to hand over your credentials).

In all honesty, this is why I got involved in working on the teslams javascript project that allows people to do their own data collection and visualization - without handing credentials over to third parties.

(oh, and technically speaking, the Windows phone app is also a third party app that requires you to enter your credentials... I guess we can give the IOS and Android app a 'pass' as they are provided by Tesla...)

Model S REST API - Page 56
Look familiar?

The article was written by user nspollution on this forum. Nice commentary in the REST API thread. Great work you guys are doing! Hope Tesla will seek towards more cooperation with its user base rather than going protective.

nspollution said:

If the Tesla attitude is that third-parties should not be using the API, that's an even bigger failure than the security issues I present.

Click to expand...

Why? They have zero obligation to provide an API to third parties. This is NOT an API. It's a reverse engineered SPI. To treat it as a published API is just dead wrong.

gregincal said:

Why? They have zero obligation to provide an API to third parties. This is NOT an API. It's a reverse engineered SPI. To treat it as a published API is just dead wrong.

Click to expand...

Correct. We should be complaining instead about the lack of an official SDK like they have talked about for years now and not delivered on.

Yes, as others have said, there is no public Tesla API. What would be useful to evaluate is any exposures on the server-side, as used by the mobile apps (and assumingly by Tesla engineering). We have some ability to do that *because of* our investigation into using the internal API without permission.

It cannot operate safely over any channel but a trusted SSL connection

Click to expand...

This is not a flaw. It is a good thing. This prevents the stealing of credentials by 3rd parties (other than the NSA)

It requires the sharing of the user's password with third-parties

Click to expand...

It requires no such thing. The mobile apps store the credentials on the local store of the phone/tablet.

No mechanism exists for cataloging applications with active tokens

Click to expand...

As stated above, this is by design and is in no way a significant flaw.

No mechanism exists for revoking the access of a compromised application

Click to expand...

This is not true. Certainly the cookie can be invalidated on the server side. It's even possible that changing the password might do that automatically, but I have not tested it. In any case, access can be revoked manually.

The automated expiration of tokens in 3 months encourages applications to improperly store your email and password.

Click to expand...

Well, you can't have it both ways.

Of particular interest to me in the blog (for obvious reasons), was:

You want to leverage a tool on a web site with some useful functionality. You enter your email/password. They willfully and incorrectly store that information and are subsequently compromised (or worse, they use it themselves)

Click to expand...

The only reason this is possible is because of the reverse engineering of the internal API. I believe there are two such publicized websites (mine being one of them). Every time I mention it, I make it clear that you would have to trust me in order to use it, and although I claim to be very trustworthy, I don't recommend that anyone use it. (Having said that, 50 distinct people have used it even though I've only mentioned it on this site).

I do not store the email/password of anyone who uses it. Some people who read that blog might incorrectly assume that there is some requirement to do so (the "incorrectly" statement notwithstanding). There is no reason to store the username and password. I assume that the other site doesn't either.

- - - Updated - - -

I think there is one REAL security flaw:

There is no artificial delay added in getting credential failures. It is susceptible to a brute force attack to get someone's password.

It seems like I have ruffled some feathers, but the reason for my post was because I saw this on the Forbes website with a pretty bold title " Newly Discovered Flaw May Open The Tesla Model S To Potential Attack From Hackers "

http://www.forbes.com/sites/reuvenc...sla-model-s-to-potential-attack-from-hackers/

Zas said:

It seems like I have ruffled some feathers, but the reason for my post was because I saw this on the Forbes website with a pretty bold title " Newly Discovered Flaw May Open The Tesla Model S To Potential Attack From Hackers "

http://www.forbes.com/sites/reuvenc...sla-model-s-to-potential-attack-from-hackers/

Click to expand...

And THIS is the problem with discussing concerns with the reverse engineered API (or SPI) in a public forum. "journalists" (and I use that term rather broadly here) are looking desperately to find "newsworthy" items they can blow out of proportion.
It's a sad statement about the crap that is Forbes these days, but it's something to keep in mind when posting here :-(

Can someone who understands the facts here write a rebuttal in the comments of that Forbes article or contact the author? Might not help but worth a try. Thanks.

nspollution said:

If they wanted the network protocol to be truly private, they did it wrong.

This is simply an undocumented API. An ecosystem is growing around it (as it always does) around APIs. This is a good thing.

They should be smart about that and design for that reality.

Click to expand...

But the point is that what you point out as "security flaws" are really "unsuitability for alternate uses". They are not security flaws for the intended purpose, i.e. a trusted app accessing the car. You can suggest things that make the API more useful for other scenarios, but in my opinion classifying them as security flaws is misleading.