Concerns about Tesla API Token process

[mandoskippy]

Ok, disclosure: I am a paranoid security guy. It's what I do.


So I was reviewing my options to pull my data from my Model S. No offense to all the hard work of those who have put together websites to or binary apps to pull data (just provide them a username and password!) but for me, this option will not work. Too paranoid. Keys to the kingdom so to speak.

So I went to figure out how the API works so I can pull my own data. One thing I noticed, is I have to get an API token prior to making API calls, but I wanted to know how this worked, so I looked at a few options. It appears that to obtain a token you must provide a
OWNERAPI_CLIENT_ID and
OWNERAPI_CLIENT_SECRET as well as your username and password to get the API token you can use.

What are those values?

teslatoken, a python package at eric1980/teslatoken uses a value stored in https://pastebin.com/raw/YiLPDggh

This page: Tesla Model S JSON API · Apiary also references the pastebin post.
[JSON] "OWNERAPI_CLIENT_ID": "81527cff06843c8634fdc09e8ac0abefb46ac849f38fe1e431c2ef2 - Pastebin.com

teslajs actually hard codes it (in a very hidden/obfucated way at this line:

mseminatore/TeslaJS


So, what is this?

Where is it derived?

Is it the token that the app sends out from a phone and someone just MITMed the request to obtain it? Did they reverse engineer the tesla app to get it?

Is the pastebin post the same token as the one in teslajs? (I didn't reverse them yet)?

I see the pastebin post is from Jan 2017. How often does this change?

Is the token the same in everyone's Tesla App?

To the previous question: If these tokens are both the same, and the same as the Tesla app, then reusing them to obtain API tokens seems to be marginally fine. If now however, what is being identified on the back end? Like, if a bunch of use the same pastebin secret to obtain our API keys, are our cars somehow linked in a way that could cause a security issue later?

Do we have a way to revoke an API token? (This is sorta important).

I am not trying to be a naysayer, I want my data, I just like to understand all the things involved before jumping in. I'd be really interested in anyone's thoughts on this!

John

 

[mandoskippy]

Ok, follow-up:

I reversed the teslajs id and secret to compare to the pastebin one:

Tesla JS ID: e4a9949fcfa04068f59abb5a658f2bac0a3428e4652315490b659d5ab3f35a9e

Tesla JS Secret: c75f14bbadc8bee3a7594412c31416f8300256d7668ea7e6e7f06727bfb9d220


Pastebin ID: 81527cff06843c8634fdc09e8ac0abefb46ac849f38fe1e431c2ef2106796384

Pastebin Secret: c7257eb71a564034f9419ee651c7d0e5f7aa6bfbd18bafb5c5c033b093bb2fa3



So it looks like there are two separate ID/Secrets in use here... this actually makes me more nervous because we are essentially sharing our API requests... WHAT IF there is an yet undocumented where every owner of a ID/SECRET combo can login to view the provisioned API ID/Secrets? I.e. what if we are essentially providing valid creds to our cars because of the model that is setup here?

 

[MartinPF]

OWNERAPI_CLIENT_ID and
OWNERAPI_CLIENT_SECRET as well as your username and password to get the API token you can use.

What are those values?

The whole thing seems to be based off oauth; client id and client secret are derived from the ios/android apps either by reverse engineering or network intercept (after modifying the app to remove certificate pinning).
the values are shared among all users/instances of the app. There may have beed a change of these values some years back, but it's been stable/unchanged for more than a year now.

An interesting aspect probably due to reuse of oauth toolkits/libs is that the api issues refresh tokens that allow token renewal/extension without reentering username/password. This functionality actualy works even though the official apps don't use it.

 

[timdorr]

Is it the token that the app sends out from a phone and someone just MITMed the request to obtain it? Did they reverse engineer the tesla app to get it?

Yes, that's how I obtained the original ID and secret. They're stored in plain text in the apps (iOS and Android), which is fine. It's an identifier to the receiver (Tesla's API) as to what app is requesting an access token. It's called an OAuth 2.0 Password Grant: Password Grant - OAuth 2.0 Servers

The reason the client ID/secret has changed over time is Tesla has rotated the keys between major releases of the app. They have not yet revoked the previous keys, but it's possible they may in the future, so staying on the latest is always best. I believe I have the latest linked to on my docs, but I can update if I'm behind.

Point is, this stuff comes directly from Tesla. It's good of you to question it and not apply blind trust. But I can vouch for the authenticity, if that helps establish trust.

 

[animorph]

You should be able to revoke a token by changing your Tesla password.

 

[mandoskippy]

Hey @timdorr thanks for letting us know where you got that. I think that was one of my major issues in understanding where that authentication came from and what was it tied to.

@animorph Have we verified that a provisioned token loses access when the password is changed? I don't want to assume that, but it may be something I check here as I get into my app.

Thanks for the replies all. Honestly, I wish Tesla would allow us to login to a portal and manage the token provisioned for our cars. That would help me understand things and feel better, but I think the answers thus far should be be sufficient.


John

 

[brianman]

...

I've had a logger running since 2013 (mostly, a few times it went offline to update for Tesla-side changes). Thanks for your work and the work of others in the area that were the basis for my C# logging app (which runs in an Azure VM and pushes data to OneDrive).

 

[chispas]

@animorph Have we verified that a provisioned token loses access when the password is changed? I don't want to assume that, but it may be something I check here as I get into my app.
John

Yup, I have verified that changing your passwords invalidates all the auth and refresh tokens.

 

[emmz0r]

That secret is just a general API key that apps use, so you can revoke the entire app. There's nothing scary or strange about this.
So if you're a "paranoid security guy" and "this is what you do", you should already know this!

 

[mandoskippy]

@emmz0r
As a paranoid security guy, I know that the token provided in various packages is used to provision lots of tokens. When you consider how each "app" is provisioned that would be groups of users associated with specific General API keys. This could make the App owner have quite a bit of power over the provisioned tokens. Part of my question was understanding how the provided keys used for apps were obtained. Were they provisioned to individuals or were they just the key that was in the Tesla mobile app that every one uses?

When I saw that there were multiple general keys out in the wild, this concerned even more as a paranoid security guy... what if they were more individualistic, and there was a way for a General API key to have power over groups of users? What if that key was more than just the general key used for the Tesla App? Consider the admin for an AWS corporate account. The Admin has a key, they can provision more keys. But they also have power over all the keys they provision. It was NOT clear how the original keys were obtained, @timdorr clarified this for me, that it was indeed pulled from the Tesla App, that is what I needed. I don't make assumptions that something is not scary or strange, this what a good security professional does.

 

[bahree]

I understand where you are coming from in the sense of token generation. Being a security nut myself I wasn't comfortable using any online tool and wrote my own windows version.

Mostly for my own use and mostly being a geek wanted to play with the APIs. You can see it and download it from the link below. And I do get the irony until I open source this, it's some random dude on the internet.

Windows Tesla Auth Token Generator

You can always use the curl script too.

And in regards to the two IDs, those are part of Oaurh and used in conjunction with yours creds to authenticate. I just wished Tesla made this more formal for us to play with.

 

[mandoskippy]

I understand where you are coming from in the sense of token generation. Being a security nut myself I wasn't comfortable using any online tool and wrote my own windows version.

Mostly for my own use and mostly being a geek wanted to play with the APIs. You can see it and download it from the link below. And I do get the irony until I open source this, it's some random dude on the internet.

Windows Tesla Auth Token Generator

You can always use the curl script too.

And in regards to the two IDs, those are part of Oaurh and used in conjunction with yours creds to authenticate. I just wished Tesla made this more formal for us to play with.

Exactly. Because of the lack formality around how the General API keys are provisioned, I had concerns. My main concerns being "where do these come from, who owns them, and what happens if I provision a token with my credentials with them" @timdorr answered that by saying they are the keys used in the Tesla mobile app. I have more trust in that now (Thanks Tim!)

 

[emmz0r]

@emmz0r
As a paranoid security guy, I know that the token provided in various packages is used to provision lots of tokens. When you consider how each "app" is provisioned that would be groups of users associated with specific General API keys. This could make the App owner have quite a bit of power over the provisioned tokens. Part of my question was understanding how the provided keys used for apps were obtained. Were they provisioned to individuals or were they just the key that was in the Tesla mobile app that every one uses?

When I saw that there were multiple general keys out in the wild, this concerned even more as a paranoid security guy... what if they were more individualistic, and there was a way for a General API key to have power over groups of users? What if that key was more than just the general key used for the Tesla App? Consider the admin for an AWS corporate account. The Admin has a key, they can provision more keys. But they also have power over all the keys they provision. It was NOT clear how the original keys were obtained, @timdorr clarified this for me, that it was indeed pulled from the Tesla App, that is what I needed. I don't make assumptions that something is not scary or strange, this what a good security professional does.

I think the keys your see are extracted from apps that are from Tesla themselves - or companies having official access to the API.

If someone were to mess with the keys, it would be Tesla themselves. In short - the keys you see are probably extracted from reverse engineered apps, as the API is. So using the key always runs the risk of suddenly being revoked at the owner's whim. The tokens generated from this is likely not affected by the API key. The API secret key is to just have access to the API itself. Anything else such as using that key as a part of generating tokens would be nuts!

On another note:
I would never trust a 3rd party app using the unofficial API accepting your password even if they promise to just relay it to Tesla API. They could STILL take it .

 

[mandoskippy]

I think the keys your see are extracted from apps that are from Tesla themselves - or companies having official access to the API.

If someone were to mess with the keys, it would be Tesla themselves. In short - the keys you see are probably extracted from reverse engineered apps, as the API is. So using the key always runs the risk of suddenly being revoked at the owner's whim. The tokens generated from this is likely not affected by the API key. The API secret key is to just have access to the API itself. Anything else such as using that key as a part of generating tokens would be nuts!

On another note:
I would never trust a 3rd party app using the unofficial API accepting your password even if they promise to just relay it to Tesla API. They could STILL take it .

I think the key for me in my initial post was not knowing where these keys came from. @timdorr, one of the people extracting the key, confirmed this first hand. That's what I needed to feel better about things. What I can't do, being a paranoid security guy, is handle a lot of statements that revolve around "I think", "probably extracted", "likely not affected". Those statements lead to assumptions by coders (in this case me) about the security of things. Tim confirmed that he extracted the key from the app, were I an over the top security guy, I'd extract it myself, I am paranoid, but I can also gauge risk based on Tim's contributions and actions on the board. So I am comfortable with it.

"The API secret key is to just have access to the API itself." This statement is scary to me. We DO NOT know why Tesla has the API Key requirement to generate keys. You may think you know, but since the API is not a formal thing, we can't just assume. My original questions were valid in that if there was a key for every user to generate keys, it could be like the AWS model where a master key generated and controlled all down stream keys. I didn't know that, Tim did, and educated me We still at this point, don't know why the API Secret is used, some good assumptions may be different app versions and revoking old application's (that may have vulnerabilities in them) ability to grant keys.

in a perfect world, Tesla SHOULD allow us to to register on their site to get those keys individually, but I digress, we don't know why it's setup this way, and Tesla is under no obligation at this point to tell us or change it. But when it's the security of my car, and potentially others who may use my code when I share it, I won't make assumptions and I will dig into every point

 

[emmz0r]

"The API secret key is to just have access to the API itself." This statement is scary to me. We DO NOT know why Tesla has the API Key requirement to generate keys.

I agree, "Assumption is the mother of all ****ups", but that's the normal way to do it. Use the original keys from the tesla app itself if it works. If not, then you are taking a risk of course.

in a perfect world, Tesla SHOULD allow us to to register on their site to get those keys individually, but I digress, we don't know why it's setup this way, and Tesla is under no obligation at this point to tell us or change it. But when it's the security of my car, and potentially others who may use my code when I share it, I won't make assumptions and I will dig into every point

I agree that anyone that register should be able to get a api key / secret for their own apps. Should be easy to do for them!

 

[RTPEV]

Okay, I think I need to jump in here too...I'm not a security expert, but I do have limited experience writing apps for services like Facebook.

In that model, a 3rd party app must first register their app with the service. By doing so, they are given an API key and a secret key. The API key can be used on the client side to allow the client to effectively pass along their authentication to the 3rd party app. The 3rd party app (running on its own server, and using the secret key) takes commands and requests data from the main system. The main system itself monitors and restricts access to whatever data the client/user has authorized (by granting separate permissions on an app-by-app basis). The user can view and immediately revoke permission to any 3rd party apps using a dashboard in the main application. The user never passes their login credentials to the 3rd party app, nor do they generate a token. They simply try to log into the 3rd party app, which then negotiates with the main application to either get pre-granted access or prompt the user to grant that access. I think this is the secure solution that we want.

But that doesn't appear to be what we have.

Instead, we are basically using the iOS/Android app's API key AND secret key to pose as the app. Now granted, the tokens do expire after 45 days or whatever...and they have somewhat limited access to vehicle functions. Now this is fine if we want to write our own apps and have a play around with the data ourselves, but when we hand over our token to a third party app, isn't this the equivalent of handing them our phone with the Tesla app open, ableit with the token expiration limitation?

Yes, I realize we can change our password if we want to revoke our tokens, but that doesn't really give us the ability to revoke the token for a single app, right? And if a 3rd party service that is storing your token gets hacked, or decides to do something nefarious, there is no good way to block just that app. We have to do a broadside change password and then re-issue tokens to all apps except the one that got hacked/misused the token.

Granted, unless there is a 3rd party developer interface to the Tesla backend where different apps can register and get their own keys and let users like us manage permissions, this may be our only choice. But unless I am missing something, I would only consider it marginally more secure than just sharing your password with 3rd party apps. Am I wrong here?

 

[pinball_player]

Having written oAuth2 protocol requests for the last two years, I have some expertise on this.

There are two types of Token generation. The first is direct grant in which you send your credentials (username, password) and the credentials for the service you are accessing on the service (The service username and password). If the username /passwords are both correct, you will get a token directly. This is what Tesla is using.

The second type is more complicated.
1. The user clicks a link on the website that needs access (W1)
2. The user is redirected to a web page on the identity provider's website (W2)
3. The user fills in the username, password on that website (W2)
4. The identity provider redirects back to the website (W1) with a code
5. The website (W1) sends the code plus the username, password of the service on W2 to W2
6. W2 sends back an access token to the W1 server.

The second method is preferred for a couple of reasons:
1. The W1 website does not know the username/password of the user
2. The Only website that can request tokens is one who knows service credentials
3. The W2 website can issue new access tokens with a valid refresh token.
4. The token is not know outside the W1 internals.

The disadvantage is that #2 does not work for automated logins since it cannot work that way.

The second way is how logging into facebook onto other websites works.

 

[RTPEV]

Having written oAuth2 protocol requests for the last two years, I have some expertise on this.

There are two types of Token generation. The first is direct grant in which you send your credentials (username, password) and the credentials for the service you are accessing on the service (The service username and password). If the username /passwords are both correct, you will get a token directly. This is what Tesla is using.

The second type is more complicated.
1. The user clicks a link on the website that needs access (W1)
2. The user is redirected to a web page on the identity provider's website (W2)
3. The user fills in the username, password on that website (W2)
4. The identity provider redirects back to the website (W1) with a code
5. The website (W1) sends the code plus the username, password of the service on W2 to W2
6. W2 sends back an access token to the W1 server.

I think you described this far more succinctly than I did. Thanks.

I do suspect there may be a typo in there though...in your description of #2, #5 says that W1 sends the code plus username/password to W2. I don't think it sends the user's username/password, but rather it sends the code plus a "secret key" to identify the W1 service (and this secret key should never be made public, otherwise it would allow a nefarious service to impersonate W1).

The disadvantage is that #2 does not work for automated logins since it cannot work that way.

I'm not sure I understand this statement. Can you elaborate?

If the token issued to W1 by W2 lasts for a certain period of time, then isn't that sufficient for at least that time period? And if a renewal token is provided, that can be used to extend the time period. This would be for an automated service like TeslaFi that just runs in the background. For a more traditional web based service, in step #2 where the user is redirected to W2, the login there could be automated, no?

 

[pinball_player]

In Step #5, it sends the username/password for the service (not the person's logging in username/password). This username/password is the long string of characters that is discussed at the top of the this thread. The reason for the service credentials is so that the issuing service knows that it is actually the correct calling website. There are two sets of credentials. The user's username/password, and the service's username/password. It is a service and secret key, which is the same as a username/password.

The second method works for when a user is logging into a server. An automated system is not going to follow the second method.

But the second method is used in the case where a user logs in once, then uses a refresh token to get a new access token when the access token expires. We have used the second method and store the refresh token for continuing access to the resource.

The access token timeout is usually very short. The refresh token timeout is much longer. Some services keep pushing the refresh token timeout into the future the same amount. Others set the refresh token lifespan to a fixed time. This means that the first time you get an access/refresh token, the refresh could be good for 6 months. If you refresh a month from now, the refresh token will only be good for 5 months.

 

[RTPEV]

In Step #5, it sends the username/password for the service (not the person's logging in username/password). This username/password is the long string of characters that is discussed at the top of the this thread. The reason for the service credentials is so that the issuing service knows that it is actually the correct calling website. There are two sets of credentials. The user's username/password, and the service's username/password. It is a service and secret key, which is the same as a username/password.

Gotcha. We're on the same page. I just don't call that a username/password, but rather use the terms key and secret key. But we are talking about the same thing.

I think we would agree (although correct me if I'm wrong), that the way most (all?) 3rd party Tesla apps are working today, by using the "option 1" approach, is only marginally more secure than just providing the 3rd party app your username/password in the first place, because even if you generate your own token and hand it over to the 3rd party app, you are generating a token while impersonating the Tesla smartphone app, and the 3rd party application similarly impersonates the Tesla app, all of which is possible because the app's secret key was not kept secret.

Which is a bit disappointing and I'm wondering if it's creating a false sense of security in the community at large. It would be preferable if Tesla embraced the 3rd party community and provided a way to register apps and distribute key/secret key or username/password to those apps. Honestly they probably even have all the infrastructure in place, they just need to expose it.[/quote][/QUOTE]