Forums

Join The Community
RegisterLogin

Flaws in REST API Authentication

I wrote up a critique of the authentication model in the Tesla REST API: https://plus.google.com/118015857958369316512/posts/URd647tAEsD

The troll hunters will hate it, I'm sure.

@omar
"re: documentation: I would hope so :) By "undocumented", I meant released to 3rd parties."
Fair enough.

"So, APIs are not inherently pubic or private."
Sure, we can agree on that. It is really public or private access to whatever API.

"network controls get compromised"
Absolutely, I was just giving a quick example. That's why security is tiered. Use HTTPS, use security groups, use ACL's, validate incoming content, use basic auth to API's you want to keep private/unmolested, etc, etc.

However at this point, my biggest concern would be BigOil hiring bot-nets to DDOS the Tesla portal. ;-)

@chrisdl I really don't think it's productive to characterize anyone as a troll or not troll. I certainly didn't mean to single you out, but your response made me look back at your post:

I don't know which computing planet you come from or what type of programming experience you have, but that statement is so wrong that it made me cringe. Your credibility just sunk by 3.

I'm still not judging you personally or your knowledge of the subject. What I would say is that how you phrased your post may have been a bit emphatic concerning @GReese's ability to analyze this issue.

This discussion is turning more into a who said what than any productive analysis of what might be exposed. It's very likely that by this point, Tesla understands this is an issue and is taking steps to change things.

I should say, I agree with you that you can't stop user stupidity. Social engineering is the lowest hanging fruit for hacking. That's why every time someone asks me to create an account, give them some magic cookie (another account credential, SSN, DL, etc.) I stop an think about it. There are some I simply won't provide period. Others I decide on a case-by-case basis based on my evaluation of what my downside exposure is if the operator of the site is a bad actor or if it gets hacked. In many/most cases I decide not to provide the information.

But that's just me. This isn't worthy of "the big news item." What it is worthy of is some good thought at Tesla to evaluate whether they believe it's a development priority and if it's a security risk in ways we may not understand.

But if I ever characterize anyone as a troll or in any other unflattering way, please call me out on it. In advance, I'm sorry, that's never my intention.

I should say that this forum doesn't format {blockquote} tags (curlies used to allow me to insert the tag easily) as I'd hoped. The quoted paragraph in my above post is the second one.

@GResse - I'm sure you're tinker with the API long enough to come up with potential issue IF the owners signs away his security freely.

There's a Dilbert strip that describe this exact situation:

Dogberg: Hello, welcome to Dogberq tech support.
User: Hi, my computer is not working.

Dogberg: Can you restart the PC?
User: I pressed the power switch but there's no responses.

Dogberg: Is the PC plugged in to the wall socket?
User: Is that what the black wire with three pong supposed to go?

Dogberg: Please pack your entire PC with all packaging back to us.
User: Why?

Dogberg: Some people are too stupid to use a computer...

sxross
No no, sorry, I didn't mean to say that you said I was a troll or anything like that. Neither am I even remotely implying that GReese would be one. Peace!

But someone who says that private APIs don't exist, especially someone who writes about APIs for a living, makes me cringe. It still does. I don't care if it is the famous George Reese or the applicant which I'm doing a job interview with, they deserve their credibility to be deducted by 3. (I hope it's clear that that was a humorous remark and that the "credibility commission" is just a figment of my imagination and doesn't really exist.)

But what do I know, I'm just a guy who creates APIs for a living. Maybe I should write about them more.

If this API is not for third party or public use, why does any of this matter?

It mostly only matters because this erroneous FUD article is now starting to turn up in mainstream media.

@NKYTA

Agreed - although, these days, they would probably just use Amazon to cause mischief: http://readwrite.com/2010/11/15/how-to-crack-passwords-in-the#awesm=~ofg...

O

Hello there, my name is GReese. I'm an expert on amusement parks and their various crowd control and safety devices. I'm used to applying the principles I've learned about mass crowd control to every place of business that serves the public, because if it works for a large amusement park, it must be the only way to do things for any sized establishment.

I see that you've built a small espresso stand here for a few passionate customers. As you must know, since people will be visiting your small coffee stand, you need effective crowd control measures. I'm appalled you don't have a ticket booth and multiple separate turnstiles for entry. This seems like a massive security risk to me. I'm sure you know that if you don't have a ticket booth separate from your coffee stand, it will be possible for ANYONE to simply walk up to your coffee stand and order coffee. And since you don't have a separate ticket booth, it might be possible for someone to look over a paying customer's shoulder and note down his coffee order. What will you do when someone discovers another customers coffee order? Huh?

You might be a small coffee stand now, but what's going to happen when you franchise? You really should have built a separate ticket booth when you had the chance. There's no way you'll be able to expand and build one later. Everyone knows that it's impossible to add or change the way a coffee stand operates once it's open. You should have delayed opening your coffee shop until you had a dedicated ticket booth. It's very common for us in the amusement park industry.

Without a ticket booth and trained box office cashiers, there's no way you can guarantee that the person that pays for the coffee will be the person that drinks the coffee. Imagine that! Every amusement park I've ever been to has a dedicated ticket booth to protect against severe risks like this. Since it's the only effective way for amusement parks that serve thousands of people every day, it must also be the right solution for your small coffee stand here. I'm shocked and appalled you haven't built a large line queuing system with safety barriers and wheelchair ramps in front of your little coffee stand. In my business, it's the only way things get done.

What's that you say? You're just a simple coffee stand, providing a desired product to customers willing to walk right up to your storefront? That you've poured your entire net worth into just buying this little stand, because there's no one else around providing this delicious espresso? That none of your paying customers have complained or had their coffee order stolen, and in fact, they rather like your product?

Hmph, I didn't come here to talk about you, I came here to notify you of your severe lack of safety considerations. I'm going to report your little coffee stand here to the department of amusement park health and safety. I'm sure they'll have some strong words for your shocking lack of a ticket booth and effective crowd control measures.

@chrisdl

OAuth requires you to be logged into the vendor web site in order to authorize applications. It does not require you to enter you credentials into any third-party web site and definitely not as part of any API user authentication process.

I vote we let this thread die. Nothing being said is adding anything new and will not convince anyone who doesn't already agree with you.

@O
True. But note "ranging in length from one to six characters"...

When is the last time you used a six character password?
I get mad when I can't use 20 chars.

This isn't worthy of "the big news item." What it is worthy of is some good thought at Tesla to evaluate whether they believe it's a development priority and if it's a security risk in ways we may not understand.

No, it's not.

I'd rather have a car with an API having this flaw than a car with no API.

That's why those of you suggesting that this is a non-issue because the API is "private" scare the shit out of me. It's an ostrich-oriented defense and it destroys a huge potential source of value in the Tesla Model S.

Again, my commentary really about the Internet of Things with Tesla as an example. Pick a dozen other "things" that have become connected and they likely have similar flaws. Anyone who has read my API book knows I am more about the crusade to improve APIs than a critic of any specific API.

@Mathew98 Some people are too stupid to use a computer

That's an ignorant and dangerous attitude.

It mostly only matters because this erroneous FUD article is now starting to turn up in mainstream media.

FUD? You've got to be kidding me.

@Greese - Missionaries have a much better track record of converting people than crusaders.

@GReese - The skid from Dilbert comic strip is not new. It's been out there for several years now.

I was a programmer in another lifetime and I now deal with "programmers" on a daily basis. Some programmers are too stupid to keep their jobs. This is in addition to some users who are not fit to use any electronic devices.

That is not to say that the general public do not use their common sense in dealing with sensitive information.

I don't think there are too many people willing to give up their bank cards and their PIN # to their doorman for the sake of convenience.

If there are people that do trust their doorman more than the safe deposit box, then they deserve to have their bank accounts wiped out.

That's just my 0.02. Apparent yours has been replicated by pathetic journalist who don't do their homework.

@mrspaghetti Missionaries have a much better track record of converting people than crusaders.

I've been doing a pretty job the last few years :)

Isn't it funny that one of the largest, longest running threads on the TMC forums is on the REST API, yet the biggest fanboy attack on me is that the API is private and doesn't matter?

I don't suppose anyone sees the contradiction in that?

Okay I am appreciative of OP's insights and him sharing them with us for free. But I have to say bcorob's post made me laugh audibly and made me feel better about driving around in a MS that might get hacked... +1bcorob

Apparent yours has been replicated by pathetic journalist who don't do their homework.

Reuven is many things, but he's not a pathetic journalist who doesn't do his homework. He fully understands what I wrote. He definitely presented it in more sensationalist form than I would have done, but he didn't lie about what I wrote.

@GReese
But as you say, OAuth requires you to login to the vendor website. And how does that login authentication go then? An HTTP POST over SSL? So actually the same type of AuthC as now used in the API.

Don't get me wrong. OAuth is great if you support 3rd party access. And it indeed would prevent people from potentially entering their passwords too easily into a 3rd party web site to access un-approved tools.
If a user gives their credentials to someone, it doesn't matter if they're used for OAuth or for AuthC directly in the API. The perpetrator still has full access.

What AuthC method would you recommend for an online REST API?

There's a HUGE WORLD of difference between entering your credentials into the Tesla Motors web site (something you have to do all the time) and having to give them to a third party.

This is why Twitter had to re-do their authentication a few years back because of all the hacking leveraging the requirement to enter your user name/password with third parties.

A HUGE WORLD of difference.

And, with OAuth, you can selectively revoke credentials for specific applications if one of the third-party tools you use is hacked.

For system-to-system authentication, I recommend request signing. But that's for another time.

FUD? You've got to be kidding me.

The technical details underlying your article were in themselves interesting, but that has long since been completely overshadowed by the spin you chose to put on the article. The story you decided to go with was, your Model S's security is compromised. Which is patently false: as you note yourself in the article the security is only compromised if the owner compromises it himself by giving out his password. But that is a minute detail the general non-programmer reader will not pick up, all he will see is "ohmygod they can hack my car".

The way you could have gone with this that might have been rather more fruitful would have been to point out that third-party access is a desirable feature and propose that Tesla make such and such minor adjustments to enable third-party use. But that is the story you chose not to go with, and it is now instead the FUD spin that is hitting mainstream media.

Which to my mind, albeit somewhat depending on your underlying motivations, was a wasted opportunity.

@GReese:

@Mathew98 Some people are too stupid to use a computer

That's an ignorant and dangerous attitude.

Dang... And here I go thinking that it was a joke. I clearly take things to lightly here.

How can you claim that there exists a flaw in an API about which there is no published information and an API that Tesla has not even sanctioned to be used by anyone else? In order to claim such a flaw, would you not have to reverse engineer Tesla's mobile app to find out what it uses to access Tesla's servers and the vehicle? That sounds like hacking to me.

@GReese
Man... It's difficult to get a straight answer.

Let me deduct it:
Q: What AuthC method would you recommend for an online REST API?
A: OAuth for person-to-system (even if no 3rd party access is allowed)

your Model S's security is compromised

I never said any such thing.

How can you claim that there exists a flaw in an API about which there is no published information and an API that Tesla has not even sanctioned to be used by anyone else?

You are confusing "flaw" with "vulnerability". There is no vulnerability. There is an architectural flaw.

Regardless of the intent of the API, the architecture behind its authentication is flawed. No one should do authentication this way. Ever.

@chrisdl
Man... It's difficult to get a straight answer.

I really don't understand what you are asking.

What AuthC method would I recommend? I don't know what the hell you are talking about. Are you using a non-standard abbreviation for AuthN?

I interpreted the question to be how I would do authentication in a REST API. My response is that if you are representing a user to a system (which is different than system-to-system), then the API should follow the OAuth standard.

I don't know of any other way to interpret your question.

@chrisdl

If you are talking about authorizing the app by the user as part of OAuth, the mode of authentication by the vendor web site is specific to its problem domain. In the case of Tesla, email address/password is fine. But I'd like a second factor in there.


X Deutschland Site Besuchen