Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

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

This site may earn commission on affiliate links.
If you are such a brilliant REST API architect, please RTFA and explain it to us all for him.

I already have explained the difference between a public REST API and a closed API - that just happens to use REST-like syntax. I already explained how it's similar to how my mail transport interacts with the virus scanner, or the IMAP server - that it isn't intended to be open. I already explained that I'd happily upvote every one of your posts IF Tesla had said it was an open API to be used for third parties to provide capabilities to your car. But it's not.

I don't see anyone supporting your position here. If you choose to believe that's because TMC has no one critical of Tesla, perhaps you'd better read that last paragraph again, where I say that you have a supportable position and I'd add to your position if and only if Tesla advertises this as an open API.

Tesla's API just doesn't fit your religion, and that's ok. You have a right to believe every API should be an open API that uses OAUTH. That's okay, in my early days of IT architecture I used to believe everything should be 100% modular and should use very expensive integration capabilites; that compilers shouldn't have loop unrolling or use inline code. Someone might use that snippet of code one day and keeping it modular is the only way, etc., etc.

I don't believe that anymore. I've moved on. And I can admit that I was wrong back then, that there are places for single-use code, closed API's, and narrow optimizations. Moreover, in my daytime job, I am responsible for application integration services and API's, and the budget I'm responsible for doesn't leave room for such overly complex architectures.

Absent anything new, I'm moving on, and you have near-zero credibility in my eyes.
 
Houses do have this flaw. But they aren't REST APIs, so the rules that apply to them are different.

Furthermore, there are no commonly accepted ways of dealing with the problem, as there are with REST APIs.

It's only a flaw if its reasonable for you to have done otherwise.

In the workplace, you are, in fact, expected to address this issue. If a company hands out physical keys to all of its employees, it's not simply considered a flaw, it's considered negligent and in violation of most commonly accepted physical security practices.

- - - Updated - - -

Wrong. There are solutions, even for your house. Just not ones that you feel necessary or worth the trouble or expense. And that's the point. A design decision is a decision based on a reading of the requirements. You have applied YOUR requirements of what Tesla should be supplying. Tesla had their agenda. And they made decisions that met their cost/reasonableness/target purpose requirements. Will they leave the API as it is today? Probably not. Will they implement a different security mechanism in the future? Perhaps. If their requirements and objectives change. Saying there are implicit requirements is your opinion, which in my estimation requires a sizable leap in logic.

That you dont accept the same logic standard you hold Tesla to for yourself lowered to nil the level of credibility you had, in my opinion. Enjoy your 15 minutes. I won't be adding a 16th. Later.
 
Wrong. There are solutions, even for your house. Just not ones that you feel necessary or worth the trouble or expense. And that's the point.

I know there are solutions for houses. I am having one put into my new home. The issue is exactly that they are very costly for a home to implement, and thus taking those precautions is not common place nor considered "reasonable".

With respect to APIs, implementing processes to protect them in this manner is not only NOT COSTLY, but it is considered normal and reasonable to design them with this in mind.

The same goes for keyfobs in office buildings.
 
Time out everyone.

1. Some of the stuff in here has gotten close to snippiness; here's a fair warning that it'll end up over there if that continues.
2. Just for the record, I amended the thread title first time around on 8/23 as the original title was inflammatory and no-one objected. Moderators try to keep things in an even keel and to maintain clarity; so, we do change and update titles from time to time. Feel free to discuss this if you wish, but do it in the Site Feedback section.

Now breath deep and count to ten slowly while Bonnie finds us another squirrel video. :)
 
Houses do have this flaw. But they aren't REST APIs, so the rules that apply to them are different.

Furthermore, there are no commonly accepted ways of dealing with the problem, as there are with REST APIs.

It's only a flaw if its reasonable for you to have done otherwise.

In the workplace, you are, in fact, expected to address this issue. If a company hands out physical keys to all of its employees, it's not simply considered a flaw, it's considered negligent and in violation of most commonly accepted physical security practices.

- - - Updated - - -



Given that you changed the title of this thread to reflect your agenda, forgive me if I don't see this request as being made in good faith.

Way to dodge the question. I was asking on good faith. You seem to be very selective in your responses and dodge questions like this frequently. If this is a flaw in the 'Internet of Things' then it is hardly unique to Tesla.
 
Let me put this in really simple terms:

If you build a non-SOAP web services API, authentication should only ever occur via application-specific credentials that may be revoked on a case-by-case basis.

Anything else is a flaw in your authentication design.

It's that simple.
You're welcome to that opinion, but you might want to state this upfront as one of your assumptions when writing an article build on such assumptions. Journalistic integrity demands it.
Actually, I did state it in the article. But, no, it's not considered an opinion. It's considered a basic information security control that's part of most standards.
Authentication Flaws in the Tesla Model S REST API - O'Reilly Broadcast

The following terms do not appear anywhere in the oreilly article:
  • SOAP
  • application-specific
  • credentials

Nor do they show up in the plus.google.com posting.

So, no, you didn't state that in the article.


While there are bugs in my browser, but I'm pretty confident "No matches found" when searching for those terms in your article isn't one of them.
 
Let me put this in really simple terms:

If you build a non-SOAP web services API, authentication should only ever occur via application-specific credentials that may be revoked on a case-by-case basis.

Anything else is a flaw in your authentication design.

It's that simple.

What makes you think that the session cookies aren't able to be revoked on a case-by-case basis? Or do you mean something more specific than what you said?
 
This is a unique feature of this forum that any moderator with an agenda can alter the title of a thread to reflect something in opposition to the original poster. Generally, the title IS the creation of the original poster.
I have never visited a forum where a moderator was NOT able to edit content of any post as desired. Of course, the best forums are very open about said changes, and TMC is one of the best ones around in this regard from what I've seen. The forums that aren't so good? They generally don't generate the same quality of content and discussion.