Ok, I've tried to stay out of this, but I have to respond to this particular comment. I ran the global research team at Symantec. I take no credit for my team's work. I simply oversaw them as they identified, responded to, and in some cases prevented, massive security problems impacting 100s of millions of users. I saw my fair share of what I would refer to as truly spectacular security failures. This isn't one of them. Not even close...
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Authentication flaws in the REST API (if you give 3rd party your private login info)
- Thread starter nspollution
- Start date
-
- Tags
- Model S User Interface
Ok, I've tried to stay out of this, but I have to respond to this particular comment. I ran the global research team at Symantec. I take no credit for my team's work. I simply oversaw them as they identified, responded to, and in some cases prevented, massive security problems impacting 100s of millions of users. I saw my fair share of what I would refer to as truly spectacular security failures. This isn't one of them. Not even close...
dirkhh
Middle-aged Member
Yes, but saying "there's room for improvement" really doesn't get you a lot of attention...
...if that kind of press attention is your cup of tea. It sure isn't mine. I tend to prefer the best facts, not the best stories.
The context you are quoting is not me calling it a spectacular security flaw. It's a spectacular flaw in software architecture.
I said it up stream, but I'll say it again here.
Why not just create sub-accounts, with particular username/password combinations you CAN hand out to 3rd party sites? This is the same as #1 above but without the OAuth tokenism.
Each sub-account can have various rights (same as #2).
If you want to revoke the subaccount, log into Tesla with the main account and do so. (same as #3).
I do this for Apple and Amazon App stores all the time, allowing 3rd party sites to log in and collect usage and sales data. I just set up sub-accounts with those rights only (one for each service I use). If the service gets compromised or I want to disallow them from now on, I just log in with my main account and change the password. Done and done.
I've honestly come to the conclusion that a certain portion of you are working hard to assign nefarious motives to me so that you can sleep at night feeling your beloved Tesla is perfect. I'm getting kind of tired of fighting that nonsense.
I'm not changing my article to suit your conclusions. If you want to disagree, write your own article.
- - - Updated - - -
Two reasons:
#1 Username/password should never be used in authentication. We use it by necessity for authenticating users because of flawed human memory. When you enable one piece of software to authenticate automatically with another, it is not subject to the constraints of human memory and thus is free to use something stronger.
#2 Whether it's a weak username/password or stronger app ID/token, there's already a standard for doing this. So why roll your own?
Having said that, even though I keep pushing OAuth in this context, this isn't about OAuth. Any authentication system that does this is fine. It's just that a) Tesla's doesn't and b) there's an existing standard which means the excuses for not doing it are very weak.
If they had done an authentication system that had strong app-specific, revocable credentials that they built themselves, there'd be no article.
I'm actually a huge OAuth critic. But mostly because it is abused for use cases in which other authentication is more appropriate. This just happens to be a textbook OAuth use case.
I'm not changing my article to suit your conclusions. If you want to disagree, write your own article.
- - - Updated - - -
Two reasons:
#1 Username/password should never be used in authentication. We use it by necessity for authenticating users because of flawed human memory. When you enable one piece of software to authenticate automatically with another, it is not subject to the constraints of human memory and thus is free to use something stronger.
#2 Whether it's a weak username/password or stronger app ID/token, there's already a standard for doing this. So why roll your own?
Having said that, even though I keep pushing OAuth in this context, this isn't about OAuth. Any authentication system that does this is fine. It's just that a) Tesla's doesn't and b) there's an existing standard which means the excuses for not doing it are very weak.
If they had done an authentication system that had strong app-specific, revocable credentials that they built themselves, there'd be no article.
I'm actually a huge OAuth critic. But mostly because it is abused for use cases in which other authentication is more appropriate. This just happens to be a textbook OAuth use case.
Update on Token Expiration
It seems people are getting mixed results on token expiration. My best guess is that there's some caching thing going on here.
I noted this in the article and its implications.
Basically, it means of the issues I have noted:
1. It cannot safely operate over any channel but a trusted SSL connection (minor)
2. It requires the sharing of the user's password with third-parties (major)
3. No mechanism exists for cataloging applications with active tokens (significant)
4. No mechanism exists for revoking the access of a compromised application (major)
5. The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)
#4 should be altered to be:
Only an inconsistent blunt-force mechanism exists for revoking access to a compromised application (moderate)
And actually, #5 should be updated to be:
5. The automated expiration of tokens in 3 months along with the blunt-force token revocation mechanism encourages applications to improperly store your email and password (significant)
I've updated the O'Reilly community piece for #4, but did not bother with #5, but that's all I control. I have notified the O'Reilly editors for the Programming piece.
It seems people are getting mixed results on token expiration. My best guess is that there's some caching thing going on here.
I noted this in the article and its implications.
Basically, it means of the issues I have noted:
1. It cannot safely operate over any channel but a trusted SSL connection (minor)
2. It requires the sharing of the user's password with third-parties (major)
3. No mechanism exists for cataloging applications with active tokens (significant)
4. No mechanism exists for revoking the access of a compromised application (major)
5. The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)
#4 should be altered to be:
Only an inconsistent blunt-force mechanism exists for revoking access to a compromised application (moderate)
And actually, #5 should be updated to be:
5. The automated expiration of tokens in 3 months along with the blunt-force token revocation mechanism encourages applications to improperly store your email and password (significant)
I've updated the O'Reilly community piece for #4, but did not bother with #5, but that's all I control. I have notified the O'Reilly editors for the Programming piece.
NigelM
Recovering Member
nspollution, I'm sure that you know that a great many folks reading these forums are developers and other technologists. However, you seem to be reacting to criticism much more like a high school kid than an established professional. You have an opinion on the way an API was implemented and that is all well and good, but calling for people to be fired is not an adult way to deliver criticism.
Defending your opinions is perfectly acceptable, but failing to correct misunderstanding of your original article leaves you dangerously open to liability given the complete lack of an explanation that users would have to provide credentials to an untrusted source. If *my* words were being used in such a ridiculously over-the-top manner in order to libel a major public company, I'd certainly want to be sure that the misunderstanding was corrected instead of spending hours defending myself on an online forum. As a technology professional and expert in APIs, I would think that you'd want to public to be properly informed instead of making wild claims in the press that will exist whenever anyone searches your name for decades. What the press is doing with your article isn't just harming Tesla's reputation, but it is also affecting your professional reputation. Quit bickering with people over philosophical points and spend a bit of time correcting the mistakes.
Defending your opinions is perfectly acceptable, but failing to correct misunderstanding of your original article leaves you dangerously open to liability given the complete lack of an explanation that users would have to provide credentials to an untrusted source. If *my* words were being used in such a ridiculously over-the-top manner in order to libel a major public company, I'd certainly want to be sure that the misunderstanding was corrected instead of spending hours defending myself on an online forum. As a technology professional and expert in APIs, I would think that you'd want to public to be properly informed instead of making wild claims in the press that will exist whenever anyone searches your name for decades. What the press is doing with your article isn't just harming Tesla's reputation, but it is also affecting your professional reputation. Quit bickering with people over philosophical points and spend a bit of time correcting the mistakes.
Not to revive a thread that everyone wants dead, but here's the promised follow-up article to the article that started it all:
The Myth of the Private API - Programming - O'Reilly Media
The Myth of the Private API - Programming - O'Reilly Media
You should specifically spell out that users voluntarily give out their private My Tesla username and password to third parties. The way it is written, it is not clear that is what is happening and the main reason why you consider it insecure.
Anyone else see the irony here?
Nsp is saying that in the Internet of Things, companies should be aware that people will discover, use, and abuse unpublished APIs in a manner that they were not originally intended, thus should be held accountable for this and plan for it.
On the other hand he doesnt seem to be aware that his original article, intended for technologists, is also part of that same Internet of Things and can be read, used, and abused by commentators and news outlets in a manner that it was not originally intended. Or he is aware, but doesn't not feel he should be held accountable for how his article is being misused and won't make the simple clarification that not handing your password out to third parties skirts the risks he claims.
If I wanted to write an article, I'd title it: The Myth of the Private Techblog Article
Nsp is saying that in the Internet of Things, companies should be aware that people will discover, use, and abuse unpublished APIs in a manner that they were not originally intended, thus should be held accountable for this and plan for it.
On the other hand he doesnt seem to be aware that his original article, intended for technologists, is also part of that same Internet of Things and can be read, used, and abused by commentators and news outlets in a manner that it was not originally intended. Or he is aware, but doesn't not feel he should be held accountable for how his article is being misused and won't make the simple clarification that not handing your password out to third parties skirts the risks he claims.
If I wanted to write an article, I'd title it: The Myth of the Private Techblog Article
Last edited:
dirkhh
Middle-aged Member
No, jomo25 is right on and you are way off. He applies your own logic to your own behavior.
Now you don't like this but that doesn't change the fact that he is, indeed, spot on. People are taking your initial article and are drawing all kinds of wild conclusions from it. And you absolutely refuse to deal with that in an appropriate manner.
The irony of all that should make your ears ring.
Actually, if you take that to its logical conclusion, no one should ever say anything because someone might misinterpret it. Every fact can be spun to meet a specific agenda. That's not a reason to avoid communication.
dirkhh
Middle-aged Member
And you are doing it again. You take a reasonable argument, ignore its merit, take it to an extreme that no one else even implied and decide that this proves your point.
You have zero credibility left.
And you should play dodge ball, because you love to avoid things.
FACT: Not one Model S whose owner has not divulged his/her password has been compromised by your so-called flaw. Not one.
Similar threads
