3 ms·

There are lots of ways to get access to this data, installing an app is a pretty convenient and common way to do so. Any app can be hacked with enough effort.

There are lots of ways to get access to this data, installing an app is a pretty convenient and common way to do so. Any app can be hacked with enough effort. The Tesla app provided absolutely no resistance, and technically no privilege escalation is required to steal the relevant data. Your screen reader app, or custom keyboard has the relevant access. >Promon engineers recommend that the Tesla app provide two-factor authentication, should avoid storing the OAuth token in cleartext, prevent easy access to its source code, and use a custom keyboard layout when entering passwords to fight against mobile keyloggers. We did not recommend this, however the OAuth token should not be in clear text.

bluesign 10y ago
you know that storing OAuth token in anyway (encrypted etc) doesnt change anything right? for screen readers and custom keyboards, thats why OS warns you with a really scary notice, that keyboard can read your passwords. I dont think you can read OAuth token without priviledge escalation btw.
throwaway7767 10y ago
> however the OAuth token should not be in clear text. How would you suggest to store it in a way that prevents someone with root access to the phone from reading it? Any encryption keys stored by the application would surely be just as easily readable by root, right?
hibbelig 10y ago
This blog post does contain those recommendations: https://promon.co/blog/tesla-cars-can-be-stolen-by-hacking-the-app/ https://promon.co/blog/tesla-cars-can-be-stolen-by-hacking-t... Near the bottom, it says: The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials. And: The app should be protected against reverse engineering.
- problems 10y ago
  > The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials. This doesn't really help, if the attacker already has root on the device they can simply hook the login or key entry function in the application. They can also just screenshot on tap when the app is launched (though that's the lame way). > The app should be protected against reverse engineering. There's no such thing, I hate when people say things like this. If you rely on protections against reverse engineering, you rely on half-measures. A determined reverser will always break your app. It might take minutes or days, but it'll always happen and they only need to break it once for it to be broken for everyone. Ultimately this is a phone security issue. Don't download and run untrustworthy code, doubly so if your ROM is out of date and vulnerable. As the immutable law of security says: If someone has root on your device, it's not your device anymore!
  - on_and_off 10y ago
    if the attacker has root on the device, he can do absolutely everything he wants with it. I don't think any app can do anything at that point.
on_and_off 10y ago
>and use a custom keyboard layout when entering passwords to fight against mobile keyloggers. mobile keylogger ? is that a thing ? AFAIK, the only way to access keyboard input on Android is to be the Active keyboard. Now that I think about it, maybe that accessibility services can too (not sure about that one). Both need the approval of the user. I have no doubt that some users click yes without reading the warnings though.

bluesign 10y ago

you know that storing OAuth token in anyway (encrypted etc) doesnt change anything right? for screen readers and custom keyboards, thats why OS warns you with a really scary notice, that keyboard can read your passwords. I dont think you can read OAuth token without priviledge escalation btw.

throwaway7767 10y ago

> however the OAuth token should not be in clear text. How would you suggest to store it in a way that prevents someone with root access to the phone from reading it? Any encryption keys stored by the application would surely be just as easily readable by root, right?

hibbelig 10y ago

This blog post does contain those recommendations: https://promon.co/blog/tesla-cars-can-be-stolen-by-hacking-the-app/ https://promon.co/blog/tesla-cars-can-be-stolen-by-hacking-t... Near the bottom, it says: The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials. And: The app should be protected against reverse engineering.

problems 10y ago
> The app should provide its own keyboard for entering the username and password. Otherwise, malicious third party keyboards can act as keyloggers to obtain the user’s credentials. This doesn't really help, if the attacker already has root on the device they can simply hook the login or key entry function in the application. They can also just screenshot on tap when the app is launched (though that's the lame way). > The app should be protected against reverse engineering. There's no such thing, I hate when people say things like this. If you rely on protections against reverse engineering, you rely on half-measures. A determined reverser will always break your app. It might take minutes or days, but it'll always happen and they only need to break it once for it to be broken for everyone. Ultimately this is a phone security issue. Don't download and run untrustworthy code, doubly so if your ROM is out of date and vulnerable. As the immutable law of security says: If someone has root on your device, it's not your device anymore!
- on_and_off 10y ago
  if the attacker has root on the device, he can do absolutely everything he wants with it. I don't think any app can do anything at that point.

on_and_off 10y ago

>and use a custom keyboard layout when entering passwords to fight against mobile keyloggers. mobile keylogger ? is that a thing ? AFAIK, the only way to access keyboard input on Android is to be the Active keyboard. Now that I think about it, maybe that accessibility services can too (not sure about that one). Both need the approval of the user. I have no doubt that some users click yes without reading the warnings though.