[Ovmsdev] Moving to a production cycle

[Greg D.]

Hi  Tom, all,

Ideally, sure, we could have a custom passphrase for each module, and
have that written into flash and printed on the back of the module
housing or on a printed card that comes in the box.  If that can
reasonably be provided in the manufacturing process flow, that would be
great.

But, I think, since the OVMS module will be a rather rare thing to see
in the wild, that having a default wifi WPA2 passphrase will prevent all
but the most devious and knowledgeable of passersby from getting into
the module and messing around before its owner does.  The passphrase -
same for all modules - would only be on in a printed card that comes
with the module, so as to not be discoverable online.  I think that
would be quite sufficient for this case, and would make recovery back to
factory defaults a lot easier since there's nothing that has to be
protected.  And, we still avoid more fuse burning, which I think is a
good thing.

The idea of having a 30 minute AP mode disable if not configured would
be fine.  Overkill in my view, but if you think it's necessary, go for it.

Greg


Tom Parker wrote:
> On 25/02/18 11:24, Greg D. wrote:
>> Agree, WiFi's MAC is not useful as a passphrase or password, but I don't
>> think that we need to go to blowing fuses to solve this.
>>
>> Michael, you are absolutely right that we shouldn't leave an open wifi
>> hotspot sitting there; it's an invitation for abuse.  But if we have a
>> static passphrase pre-set, and there is nothing one can do with the
>> module in that state - plugged in but not configured - I think that the
>> window for that abuse is going to be vanishingly small.
>
> I think the concern here is someone plugging it in but never
> configuring it. The OVMS invites anyone passing to take control of it,
> which given it will trivially control the car, is something we should
> be careful with. For example, if you plug in and then forget about it,
> someone could come along and connect to the wifi and perform the
> initial configuration using the helpful web configuration wizard. Once
> they've configured the module, at least for some cars, they can simply
> use it to unlock the car.
>
> This scenario doesn't really require a targeted attack, as it's just
> stealing the vehicle or it's content, not trying cause the car to
> crash by loading malicious firmware. It doesn't require any skill as
> it's just using the standard OVMS features.
>
> Perhaps the module should give up if it doesn't get configured within
> say 30 minutes and shut off the access point and go to sleep.
> Alternatively we could put a big warning on the box "configure module
> as soon as possible"? Or both. The warning on it's own seems like a
> cop-out given we can limit the exposure with a timeout.
>
>> Since wifi can be either a client or an AP, not both, anyone using wifi
>> for management can't use it as a client, since there is no easy way to
>> move it back to being an AP.  Ok, I suppose an SMS command could turn on
>> AP mode...  Is that the intent?
>
> I've made some ESP8266 based data loggers that were both access point
> and station connected to another network at the same time. This wasn't
> intentional so I didn't spend long exploring how well it worked before
> turning off the access point.
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev