An anonymous reader writes
"New Tesla owner and Executive DIrector of Cloud Computing at Dell, George Reese, brings the Tesla Model S REST API authentication into question. 'The authentication protocol in the Tesla REST API is flawed. Worse, it's flawed in a way that makes no sense. Tesla ignored most conventions around API authentication and wrote their own. As much as I talk about the downsides to OAuth (a standard for authenticating consumers of REST APIs—Twitter uses it), this scenario is one that screams for its use.' While not likely to compromise the safety of the vehicle, he does go on to say, 'I can target a site that provides value-added services to Tesla owners and force them to use a lot more electricity than is necessary and shorten their battery lives dramatically. I can also honk their horns, flash their lights, and open and close the sunroof. While none of this is catastrophic, it can certainly be surprising and distracting while someone is driving.'"
Re:First World Priorites
By AaronW
•
2013-Aug-27 15:58
• Score: 4, Informative
• Thread
There is a setting in the car where you can disable remote access. It's trivial to set.
Re:Major fail for Tesla
By DuckDodgers
•
2013-Aug-27 15:58
• Score: 4, Insightful
• Thread
Even for companies that primarily write software, it's easy to design something that looks secure to you but in fact is trivial to defeat. WEP wireless security is inherently flawed. PPTP VPNs from Microsoft are inherently flawed, though not as badly as WEP, and Microsoft has deprecated the entire protocol. WPS wireless easy setup is flawed. The AES encryption used by Megaupload in their re-launch earlier this year was not implemented properly, and thus is useless.
The history of computing is littered with flawed attempts at designing new security protocols. As far as I can tell, the best practice is to adopt an existing open source technology that is well proven. If you're trying to do something new, you probably need to spend an unholy fortune on multiple independent audits of the system, as well as inviting people on security mailing lists to examine it, and possibly offering a bounty for discovered flaws.
Re:You might be right.
By dgatwood
•
2013-Aug-27 16:01
• Score: 4, Interesting
• Thread
John Q. Private is currently at mile marker 23 on highway 2, proceeding at 65 mph in an easterly direction, with 100 miles of range remaining.
Say I am John Q. Private. Can you give me a scenario where I might care that someone has this information?
When the speed limit is 55.
Alternatively, when someone correlates driving patterns with murders and determines that you were parked in the parking lots of restaurants that were within walking distance of three unsolved murders. Can you prove you were eating? The whole time?
Yes, I can think of a lot of scenarios where you might care.
Seems Trollish
By sl4shd0rk
•
2013-Aug-27 16:05
• Score: 5, Insightful
• Thread
Tesla is a big target in the crosshairs of the automotive industry right now so I'm very skeptical. Tesla is doing what no other company has been able to do in the US and that seems to be a problem with everyone from dealers to falsified reviews in The New York Times. Let's do without the TFA drama have a look at the the egregious attack vectors listed:
1) You want to leverage a tool on a website with some useful functionality. You enter your email/password. They willfully and incorrectly store that information and are subsequently compromised (or worse, they use it themselves).
This is a really broad claim. What's more, if you haven't logged in over an SSL connection then... well, you're kind of a dumbass.
2) An attacker gains access to a website's database of authenticated tokens. It has free access to all of that siteâ(TM)s cars up to 3 months with no ability for the owners to do anything about it.
This is no less dubious that so many online services that I couldn't begin to count. The risk of compromise is an accepted one and hopefully mitigated. No fair faulting them without seeing how they would handle said compromise.
In a nutshell, TFA is going to need to find more substantial basis for panic than this. Sheesh.
OAuth for Apps? Seriously?
By Luthair
•
2013-Aug-27 16:41
• Score: 4, Interesting
• Thread
The article is mostly FUD. To start, OAuth is not a User->System authentication system, its a three party authentication system. For OAuth to work as intended the three parties involved need secure communication channels between the pairs (e.g. user to api, 3rd party to api, and user to 3rd party). This leads to the fact that his first two complaints about the Tesla service, are also inherently present in OAuth when implemented in a non-web app:
* Entering login information into any application inherently provides it to the application's author
* SSL is required between the 3rd party and the API service, otherwise eavesdroppers are able to obtain the API token, secret and user token
The final two flaws are really the same issue and are not part of authentication; however it is important that users are able to revoke access that they've provided to third parties. Missing that ability is certainly a problem but it is not a flaw with authentication.
While there are better methods for authentication that ought to be used by Tesla for their API (e.g. a long one time token the user enters, a QR code scanned, etc.), OAuth is not a better form of authentication for desktop or mobile application.