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

[nspollution]

I did not call them security flaws. I called them authentication flaws. They are authentication flaws. Specifically, they are flaws in the architecture of the authentication system.

There is no sane justification on this earth for designing an API authentication system this way. None. It's a flaw.

 

[Discoducky]

I am the original author and the "it's not a public/published API" is an idiotic defense.

I am a Tesla owner and an expert in REST API design. These are flaws whether or not Tesla "intended" the API to be public or not. People identify and build ecosystems around APIs. It happens all the time. It's an important value of the Tesla that this can happen.

What if you want your home automation software integrated with your Tesla?

The world is becoming more API-driven, and we need to be smarter about the way we design and consume APIs.

So I'm curious why you have not posted a single time to the Model S REST API thread until *after* you wrote your article?

 

[gmontem]

So I'm curious why you have not posted a single time to the Model S REST API thread until *after* you wrote your article?

Makes for a tasty article or two that may yield page views, $$$, etc.

Sent from my RM-877_nam_att_205 using Board Express

 

[gregincal]

I did not call them security flaws. I called them authentication flaws. They are authentication flaws. Specifically, they are flaws in the architecture of the authentication system.

There is no sane justification on this earth for designing an API authentication system this way. None. It's a flaw.

Well, it's straightforward and easy and does the job, so that's a justification. I've certainly done similar things when I've designed a point to point protocol over SSL. Why introduce complexity if it's not needed? I would still call them limitations in the authentication system. No matter what Tesla does with their API, I can put up a website that asks people to enter their Tesla credentials, and if they are stupid enough to do so then they are equally as hacked.

 

[markwj]

I am the original author and the "it's not a public/published API" is an idiotic defense.

The public/private API defense is very valid.

If someone takes something, uses it for a purpose other than originally intended, and then flaws are found in the new use, those flaws do not necessarily impact the original purpose. Using a razor blade as floss to clean your teeth is unsafe, but that is not a flaw in the design of razor blades.

Another comparison: the iPhone 2G unofficial SDK. Should Apple be held responsible for flaws in the way people used that SDK before they finally released an official SDK?

In the case of this API, Tesla's use of it is for their iPhone and Android Apps to control their own cars, not for third party websites, apps or services. At some point, Tesla may release an API/SDK for third party use, and if at such time this authentication mechanism was still used that would be a problem.

The stated 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)

Are primarily related to third-party Apps, not Tesla's own Apps. As Tesla did not intend for this API to be publicly used by third parties, it is harsh to castigate them for this. When used for its intended purpose, I don't see the issue.

Now, there might be some flaws with the Tesla approach. Most notably that a SSL MITM attack can steal credentials (as with many such protocols), but in Tesla's case it appears that changing the password does not invalidate the already issued tokens.

But, none of the above five stated flaws affect users using Tesla's product in the authorized and supported ways.

 

[gregincal]

Basically, if the article had been "if designed better, Tesla's protocol could have been so much more useful" instead of "authentication flaws expose owners to attack vectors" I don't think people here would have had a problem with it.

 

[nspollution]

So I'm curious why you have not posted a single time to the Model S REST API thread until *after* you wrote your article?

Except I have. D'oh!

- - - Updated - - -

Makes for a tasty article or two that may yield page views, $$$, etc.

There is no monetary benefit. What prompted me to write up the article was actually a question someone asked in this forum.

Oh ****, you guys are just talking with both feet in your mouth.

- - - Updated - - -

The public/private API defense is very valid.

If someone takes something, uses it for a purpose other than originally intended, and then flaws are found in the new use, those flaws do not necessarily impact the original purpose. Using a razor blade as floss to clean your teeth is unsafe, but that is not a flaw in the design of razor blades.

No, the private API defense is not valid. That's the whole point of this "Internet of Things" discussion. Things are connected and have APIs that get used. If you design something in a crappy fashion and then use the defense "oh, it's private", that's like saying "I don't need a lock on my front door, it's a private front door."

People will leverage APIs. Any responsible API designer should take this into account.

There might be some merit to the argument if the Tesla API approach were the right approach for a private API, but it's not. The right approach for this API, private or not, is the same: use OAuth.

This is a flaw.

- - - Updated - - -

Basically, if the article had been "if designed better, Tesla's protocol could have been so much more useful" instead of "authentication flaws expose owners to attack vectors" I don't think people here would have had a problem with it.

Except my title is correct and yours is wrong.

In my professional opinion as an expert in API design, it's an architectural flaw.

 

[nspollution]

No matter what Tesla does with their API, I can put up a website that asks people to enter their Tesla credentials, and if they are stupid enough to do so then they are equally as hacked.

But it's not stupid. If that's the only mechanism available to gain access to valuable functionality, then it's not a stupid thing. It's stupid that Tesla has such a setup.

That's the world we lived in before Twitter adopted OAuth. People were entering their credentials into all kinds of third-party apps because that was the only way to get access to valuable functionality. It turns out some of those third-parties could get hacked and expose those credentials. And thus Twitter went to OAuth.

At least Twitter had an excuse as OAuth wasn't widely adopted at the time.

Tesla has no such excuse.

 

[Discoducky]

Except I have. D'oh!

- - - Updated - - -

A few minutes does not count and let's be realistic...What is your intention?

 

[nspollution]

A few minutes does not count and let's be realistic...What is your intention?

I've been engaged off and on, depending on how the thread has gone, for 3-4 months.

My intention? Well, as noted earlier, it was a detailed followup to a question in a thread in this forum yesterday. On a larger note, I do this ALL THE TIME for other APIs. Ask people in the AWS, OpenStack, vCloud, Hue, CloudStack, ... communities.

Every single day. I even wrote a book on the subject. You can get it on Amazon.

No, I did not do this to sell books. I sell the book for $5/copy and give away 10% to charity. No goosing of book sales is going to matter in any way to me.

 

[Electroman]

How is this different from mint.com asking for my credentials for my bank?

Is Bank of America also stupid ?

 

[hans]

How is this different from mint.com asking for my credentials for my bank?

Technically no, different but I trust Intuit with a lot of my personal information. Others, not so much.

Is Bank of America also stupid ?

Now that is a loaded question. Not going there (on this thread) ;-)

 

[nspollution]

Technically no, different but I trust Intuit with a lot of my personal information. Others, not so much.



Now that is a loaded question. Not going there (on this thread) ;-)

#1 Mint.com was a start-up once-upon-a-time. A lot of people trusted it with their banking credentials long before Intuit acquired them.

#2 Yes, Bank of America is stupid. In general, banks are among the least secure online systems.

Mint.com is actually a perfect example of the point I am trying to make. And so are the countless frequent flyer point tracking sites. And may other similar online systems that have grown up around half-assed API ecosystems.

 

[brianman]

The public/private API defense is very valid.

If someone takes something, uses it for a purpose other than originally intended, and then flaws are found in the new use, those flaws do not necessarily impact the original purpose. Using a razor blade as floss to clean your teeth is unsafe, but that is not a flaw in the design of razor blades.

Agreed.

"I leave my house key in my driveway with a yellow sticky attached to it so that I can find it easily. House keys should be redesigned for better security."

 

[markwj]

No, the private API defense is not valid. That's the whole point of this "Internet of Things" discussion. Things are connected and have APIs that get used. If you design something in a crappy fashion and then use the defense "oh, it's private", that's like saying "I don't need a lock on my front door, it's a private front door."

People will leverage APIs. Any responsible API designer should take this into account.

There might be some merit to the argument if the Tesla API approach were the right approach for a private API, but it's not. The right approach for this API, private or not, is the same: use OAuth.

This is a flaw.

What is the flaw for Tesla in the use of this API by their Apps to their servers? How is that exploitable?

The flaws you mention appear only if the API is used by third party services, and are primarily concerned with the exploit of the third party services.

The API as we see it has been reverse-engineered by MITM attacking the SSL comms between the apps and the server. This is clearly not what Tesla intends for this API. If Tesla intended it to be public and used by third party apps, they would have published it and would support developers using it. If they had done that, I would agree with you. However, at the moment, third party use of this API is a hack, and the flaws identified only relate to third party hacks using that hack.

Maybe I can illustrate by just concentrating on one 'flaw':
* It cannot safely operate over any channel but a trusted SSL connection (minor)
The Tesla Apps use SSL to talk to the Tesla servers. So, how is this a flaw in the API (which is explicitly designed to work within a protected SSL channel)? It only becomes a flaw when the API is used in a way not intended (outside a protected SSL channel).

Regarding the argument of the right approach, sure OAuth is a _better_ approach for this (private or public). However, that doesn't mean that the current approach (or API) is flawed for its intended use (Tesla Apps to Tesla Servers) - which is what was stated and what was picked up by Forbes (and presumably, soon, others).

I say again: if you use a razor blade to floss your teeth, that is neither a flaw in the design of the razor blade nor the fault of the manufacturer.

 

[woof]

Tesla could allow subuser accounts (username/passwords) per VIN, and allow each username to have different permissions associated. So user "A" can do everything the master can do, user "B" can only "read" (no changing of anything on the car), and user "C" can read, but not see the location or speed data, etc. This mitigates the "give password to 3rd party" arguments as that password is only for a subuser account, which the master user can revoke at anytime, and limits what the subuser can do.

 

[markwj]

This discussion of authentication flaws has brought up (reminded me of) one security issue in the system as designed by, and intended to be used by, Tesla:

1. Owner logs in to iPhone App.
2. Thief steals iPhone.
3. Owner goes to My Tesla and changes his password.
4. Thief still has access to the Tesla vehicle for up to 3 months.

Can anyone confirm if this is indeed the case? Does changing the password on the My Tesla site invalidate the authentication tokens previously issued?

 

[juventuss]

This discussion of authentication flaws has brought up (reminded me of) one security issue in the system as designed by, and intended to be used by, Tesla:

1. Owner logs in to iPhone App.
2. Thief steals iPhone.
3. Owner goes to My Tesla and changes his password.
4. Thief still has access to the Tesla vehicle for up to 3 months.

Can anyone confirm if this is indeed the case? Does changing the password on the My Tesla site invalidate the authentication tokens previously issued?

Couldn't owner remote erase said iPhone within hours of noticing theft ?

 

[markwj]

Couldn't owner remote erase said iPhone within hours of noticing theft ?

Only if they have find-my-iphone and remote wipe enabled. But, in general if the Thief has physical access to the iPhone, he 'owns' it.

Or, for simplicity s/iPhone/Android/ in my question.

 

[dirkhh]

This discussion of authentication flaws has brought up (reminded me of) one security issue in the system as designed by, and intended to be used by, Tesla:

1. Owner logs in to iPhone App.
2. Thief steals iPhone.
3. Owner goes to My Tesla and changes his password.
4. Thief still has access to the Tesla vehicle for up to 3 months.

Can anyone confirm if this is indeed the case? Does changing the password on the My Tesla site invalidate the authentication tokens previously issued?

In my experience the tokens expire much quicker. The teslams framework refreshes them several times a day.
In another thread user testing showed that after the user changes the password even with the cookie in place you can not renew the API token without entering the new password as well.