Yes, as others have said, there is no public Tesla API. What would be useful to evaluate is any exposures on the server-side, as used by the mobile apps (and assumingly by Tesla engineering). We have some ability to do that *because of* our investigation into using the internal API without permission.
It cannot operate safely over any channel but a trusted SSL connection
This is not a flaw. It is a good thing. This prevents the stealing of credentials by 3rd parties (other than the NSA)
It requires the sharing of the user's password with third-parties
It requires no such thing. The mobile apps store the credentials on the local store of the phone/tablet.
No mechanism exists for cataloging applications with active tokens
As stated above, this is by design and is in no way a significant flaw.
No mechanism exists for revoking the access of a compromised application
This is not true. Certainly the cookie can be invalidated on the server side. It's even possible that changing the password might do that automatically, but I have not tested it. In any case, access can be revoked manually.
The automated expiration of tokens in 3 months encourages applications to improperly store your email and password.
Well, you can't have it both ways.
Of particular interest to me in the blog (for obvious reasons), was:
You want to leverage a tool on a web site 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)
The only reason this is possible is because of the reverse engineering of the internal API. I believe there are two such publicized websites (mine being one of them). Every time I mention it, I make it clear that you would have to trust me in order to use it, and although I claim to be very trustworthy, I don't recommend that anyone use it. (Having said that, 50 distinct people have used it even though I've only mentioned it on this site).
I do not store the email/password of anyone who uses it. Some people who read that blog might incorrectly assume that there is some requirement to do so (the "incorrectly" statement notwithstanding). There is no reason to store the username and password. I assume that the other site doesn't either.
- - - Updated - - -
I think there is one REAL security flaw:
There is no artificial delay added in getting credential failures. It is susceptible to a brute force attack to get someone's password.