-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Thats a bold statement to make. As skn pointed out, oAuth is a better use than cookies. If using the Resource Owner grant of oAuth, yes, this isn't much different than the implementation they have with cookies. Users enter their username/password in an application (1st or 3rd party) and then exchange that for a "token". In Tesla's implementation, that is a cookie that you send to the server. In oAuth, that is an oAuth token. Either way, you send a tokenized identifier to the server that represents the user, the app and the server (API). However, what oAuth does do is protect the user in its other grant types (Implicit, AuthCode) from requiring the user to give its username/password to anyone other than Tesla. This is standard when 3rd parties are developing on your platform. The third party registers as an application in Tesla's API/Platform, then navigates users to an 'Authorization' page hosted by Tesla, where users only have to give their password to Tesla. From there, Tesla negotiates this permission and provides the 3rd party with a token (or an auth-code used later to get a token) to be used to access the account information on behalf of the user. When you boil it down, what we really want to protect is the user and the need for a user to give their password to anyone other than Tesla. To skn's point, this API doesn't look intended for 3rd party consumption, which is disappointing. However, this doesn't mean there won't be "in-dash" 3rd party apps that run natively on the device, just webapps.
I am surprised to find that Tesla's app doesn't "pin" to a root certificate to begin with. I am not upset about that, because then we wouldn't have discovered how to access this API, but eventually this will be a liability given that you can locate a car and unlock a car that might have valuables in it. Based on the design of the API, it looks like it was built to facilitate a need (their app) on a tight timeline. If they are truly looking to build a robust API that can be adopted by 3rd party apps for the purpose of extending the owners experience, they need to adapt oAuth and have a much more well though out API.
If anyone at Tesla is listening, I design these types of API's for a living and would be all about spearheading that initiative
After a point I kind of feel sorry for nspollution - Authentication flaws in the REST API (if you give 3rd party your private login info)
Pilot_51
Member
That is precisely why I said "blatant". SSL, or at least OpenSSL, is a very complicated beast that few people who understand the language can understand. Any way you look at it, open source has more eyes looking at it and it's a strong sign that the developer is honest (who would ever do something they know is malicious and show the proof to everyone?). I wouldn't trust a proprietary 3rd party application from someone I don't already trust with my passwords.
@skn, have you actually read about OAuth? It is no panacea. From the link you provided:
That's a little scary isn't it. So if I can acquire a token for your app I have unlimited access without any re-authentication until/unless the user notices and takes specific action to revoke the token. At least TMC's token do expire.
And from the former lead of the OAuth efforts:
That's a little scary isn't it. So if I can acquire a token for your app I have unlimited access without any re-authentication until/unless the user notices and takes specific action to revoke the token. At least TMC's token do expire.
And from the former lead of the OAuth efforts:
Yes, you did a good job of describing the differences. And you also explained how the benefits to OAuth would not provide any benefit that Tesla currently cares about. It does not increase security in any way for the designed use of the API.
If anyone at Tesla is listening, I design these types of API's for a living and would be all about spearheading that initiative
Yes me too, but I'm sure Tesla also has their own people who could do this and will use it (or something similar) if and when they want 3rd party applications to be able to use the API. For full disclosure, I'm also a professor of computer security.
I still think Tesla should care about this, not really from the oAuth side, but from the fact that their API was reverse engineered from their app. The app and the API do leave Tesla, the brand, vulnerable. Normally, an app with a REST API acts pretty much like a website and doesn't expose much more functionality than normally found on the actual website a user needs to log into. So the worst thing you can ever do is mess with a single account at a time, only if you know the credentials. However, Tesla's app goes beyond what a user can do on a website, so a compromised online account can not only lead you into some personal and financial data, but it also provides a programmatic access to a machine that Tesla built for a customer. The fact that people could reverse engineer the app and the API is not good for the brand of Tesla if someone does something bad with this access. If someone were to compromise their account databases, they could then essentially unlock everyones car. This is a liability that goes far beyond stealing money off someones credit card. Not only does it provide remote functionality to another persons property, it tracks where the current user actually is as well. The larger their user base grows, the more potential for fraud and damage to their brand.
I am assuming someone just did a simple man-in-the-middle attack to watch what the app was doing? Don't get me wrong, I love that we have this API - I just think eventually this is going to become a liability to them, rather than something they can just let go because its a bunch of nerds monitoring and playing with their cars remotely
- - - Updated - - -
If I acquire a cookie for your car, I gain unlimited access to your car for 3 months, and you have NO WAY to revoke that cookie. If you change your password, cookie still works. 3 months is just as arbitrary as 1 year, 5 years, or forever.
oAuth is a means of "authorization" not "authentication". And the TTL of an oAuth token is not infinite, it can be, but it is up to the implementation to set the TTL and whether its a one time use-period, or a refreshable period (longer term access). But like you said, this also gives the user the ability to revoke access - in the case of changing password, losing device, website compromised, etc. oAuth also allows for users to set the "scope" of what the app is allowed to have access to...TM's cookies don't do that, do they? TM's cookie implementation is basically exactly what you are describing as the downside of oAuth. The cookie is generated once, then used in an unlimited way until it expires.
The real use of oAuth here is to protect the users from having to give their username/password credentials to anyone other than Tesla in addition to whats possible in my comments above. I downloaded VisibleTesla, and I logged in, who's to say that the developer didn't ship my password over to their servers? Then what if I use that same username/password for my banking info. Big win for that developer
Tesla is trying to grow into a much larger user base, and with more users, comes more problems, more lawsuits, etc. In my opinion, something bad will happen with the remote access one day, not from Tesla's app, but from an "unofficial" third party app and then its going to be game over for us. The fact that Tesla lets things like VisibleTesla exists means they are either oblivious it exists (doubt it) or they un-officially condone it. So, I would rather see them do it right, give me the user a trusted place on their website that I can put in my credentials and authorize a 3rd party app - and revoke it when I want to.
I still think Tesla should care about this, not really from the oAuth side, but from the fact that their API was reverse engineered from their app. The app and the API do leave Tesla, the brand, vulnerable. Normally, an app with a REST API acts pretty much like a website and doesn't expose much more functionality than normally found on the actual website a user needs to log into. So the worst thing you can ever do is mess with a single account at a time, only if you know the credentials. However, Tesla's app goes beyond what a user can do on a website, so a compromised online account can not only lead you into some personal and financial data, but it also provides a programmatic access to a machine that Tesla built for a customer. The fact that people could reverse engineer the app and the API is not good for the brand of Tesla if someone does something bad with this access. If someone were to compromise their account databases, they could then essentially unlock everyones car. This is a liability that goes far beyond stealing money off someones credit card. Not only does it provide remote functionality to another persons property, it tracks where the current user actually is as well. The larger their user base grows, the more potential for fraud and damage to their brand.
I am assuming someone just did a simple man-in-the-middle attack to watch what the app was doing? Don't get me wrong, I love that we have this API - I just think eventually this is going to become a liability to them, rather than something they can just let go because its a bunch of nerds monitoring and playing with their cars remotely
Yes, I'm pretty sure I recall that the person who eventually posted the API info here used a MitM attack, but that's not the only way I know of to get at the API info (note that some commands are documented here that cannot be performed by the mobile apps).
You are correct in all of your statements, but they are hypothetical situations. If someone were to compromise their account database, *I* will hypothesize that the same person could probably compromise the system that can access everyone's car directly (might even be the same system), and not have to go back to their own computer to login and connect to the server to honk someone's horn. At least I hope Tesla is assuming that.
I don't see how that's clear at all. It might be if they had released a development SDK, but right now the risks are small and there is no developers' SDK, so it's not worth their while to fix. I wouldn't be at all surprised to find that when the SDK is released there would be some new security items to go along with it.
I can't disagree. Time will tell and hopefully we are safer.
In the meantime, I guess use 3rd apps at your own risk and almost never use closed source 3rd party apps.
Certainly setting a far longer and complex password is warranted. Mine is over 12 characters and includes mixed case and symbols. Since one rarely needs to enter it manually as both web browsers and the Tesla apps can save the passwords, it makes sense to set it to something difficult.
Further, Tesla should implement anti-guessing measures if they haven't already. A progressive lock out, even a relatively generous one will go a long way with 8+ characters. I think Tesla should require 12+ characters and think about implementing two factor authentication for access from new devices.
Further, Tesla should implement anti-guessing measures if they haven't already. A progressive lock out, even a relatively generous one will go a long way with 8+ characters. I think Tesla should require 12+ characters and think about implementing two factor authentication for access from new devices.
nspollution
Member
Flaw, not a Vulnerability
It is a flaw in the architecture. As I pointed out in the past and another has pointed out with further research, this is an architectural flaw that makes these kinds of hacks easier to carry out and more damaging when they are carried out.
But it's not a vulnerability.
It is a flaw in the architecture. As I pointed out in the past and another has pointed out with further research, this is an architectural flaw that makes these kinds of hacks easier to carry out and more damaging when they are carried out.
But it's not a vulnerability.
How about we wait to have this argument again until Tesla actually opens the API to third-party creators, at which point I'd guess that they'd use OAUTH because it's the bee's knees, the squirrel's churrels, the big kahuna's paluma, the fox's rocks, etc.?
I, too, am distressed that slow news days are resulting in these crazy articles. The ability to honk the horn when the car is not in drive is well-known, when you have the login and password. These security "researchers" (used loosely) are obviously of the belief that remote access to a car shouldn't be possible.
I will tell you one thing that I think should happen - Tesla should remove the ability to open/close/vent the pano roof via remote app while driving. I was driving down the road with the roof wide open, when it started to close... then vent... then close... then vent... then close.
A quick call to my wife to suggest the 18 month old find a better game to play on her iPhone fixed the problem. Basically, if the car is not in park, none of the remote access stuff should work, to include climate control, etc.
I, too, am distressed that slow news days are resulting in these crazy articles. The ability to honk the horn when the car is not in drive is well-known, when you have the login and password. These security "researchers" (used loosely) are obviously of the belief that remote access to a car shouldn't be possible.
I will tell you one thing that I think should happen - Tesla should remove the ability to open/close/vent the pano roof via remote app while driving. I was driving down the road with the roof wide open, when it started to close... then vent... then close... then vent... then close.
A quick call to my wife to suggest the 18 month old find a better game to play on her iPhone fixed the problem. Basically, if the car is not in park, none of the remote access stuff should work, to include climate control, etc.
Last edited:
That's hilarious. Your child was thinking, "Playing with Mom/Dad's car! This is the best game ever!"
Though to be fair, that's also approximately what I was thinking the first time I used the app.
Similar threads
