[Ovmsdev] Merging in Twizy and Volt/Ampera work

Sun Nov 18 21:04:13 HKT 2012

Michael,

I'll have to think about this. Not so easy, and it has security implications.

I am aware that caller ID can be faked, but not too worried about it for anything other than the PASS command.

To be successful, the 'hacker' must know your register mobile number (to fake), as well as the number of your car module. If he then fakes your caller id (registered phone) to send a GPS message to the car module, the car module will reply with GPS position of your car to YOU (not him). Faking the sender's caller id doesn't mean he gets messages intended for you.

The main issue is the PASS command. If he does know both telephone numbers, he can fake your registered phone to change the password. Then, he can send messages directly, and get replies. That is a possible issue, and the only protection is that _both_ numbers must be known. Also note that YOU will get a message saying the password has been changed, so you will know about it. The only solution is to make the PASS command require the old as well as new password, but then he is in trouble if he ever forgets the old password.

Slightly concerning also is he can mess with your params, but for each of these YOU will receive an SMS message back showing you the new parameters the hacker has set.

Let me think about it.

Regards, Mark.

P.S. v2.1.1 now running in my car. Looking good.

On 18 Nov, 2012, at 8:51 PM, Michael Balzer <dexter at expeedo.de> wrote:

> Mark,
> 
> I haven't understood completely yet why there could be confusion on the command parameters.
> 
> For example, "PASS" now is in mode 2. If it's called as "PASS <newpw>", net_sms_checkpassarg() would not touch the args. If it's called "PASS <oldpw> <newpw>", net_sms_checkpassarg() will authorize the call and remove <newpw> from the args -- for the PASS handler, everything looks the same. "PASS <oldpw>" would result in clearing the module password, but a check for a non empty <newpw> makes sense there anyway.
> 
> Is there a case where the first argument could be identical to the module password? And couldn't we just tell the users they need to choose a secure password (i.e. not one identical to the module or server name)?
> 
> I also think it's important for us to remember considering all commands in auth modes "2" and "3" as insecure, as they can be called from anyone just by faking the caller id. I guess that's not a real problem yet, but it could become one. For example, my DEBUG command now outputs the current GPS position, so someone trying to spy me out could easily track me using that output.
> 
> ...*lol*, there're already even web services available for caller id faking: http://calleridfaker.com/
> 
> => It would be nice for a handler to know the auth level of the call. So my DEBUG handler could output GPS position only if it's been called with the module password.
> 
> This could be done by changing the net_sms_checkauth() result to a char reflecting the auth level reached, i.e. 0=auth failure, 1=caller id, 2=password, and passing that through to the handlers.
> 
> Regards,
> Michael
> 
> 
> Am 18.11.2012 09:21, schrieb Mark Webb-Johnson:
>> The auth modes directly map to the three ways of doing it in the old code. Just standardised them and implemented in one place to save space, and reduce the amount of work needed to be done in the handlers.
>> 
>> Some commands can ONLY work with a password (things like REGISTER used to change the registered phone - which can obviously not work with a caller id).
>> 
>> Some commands can work with EITHER a password OR a registered phone (things like STAT).
>> 
>> Other commands can ONLY work with a registered phone (normally commands used to set settings like SERVER, MODULE, etc - where the presence of a password could be confused with the parameter itself).
>> 
>> Regards, Mark
>> 
>> On 18 Nov, 2012, at 6:08 AM, Michael Balzer <dexter at expeedo.de> wrote:
>> 
>>> Am 17.11.2012 19:20, schrieb Michael Balzer:
>>>> Thinking about auth... maybe I'm missing something, but why is there a need for the three auth modes? Couldn't it just be mode 3 for every command?
>>> Ok, thinking about it a bit more (I'm getting old...), a caller id obviously can be faked, so mode 1 definitely makes sense.
>>> 
>>> But it still looks like mode 2 is included in mode 3...?
>>> 
>>> Michael
>>> 
>>> -- 
>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>> 
>>> <dexter.vcf>_______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> 
> <dexter.vcf>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev