<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I forgot to answer one question:<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">Maybe we can also provide a similar option for the Hologram registration, or at least some way to hand over the ICCID for registration.</div></div></blockquote></div></div></div></blockquote><div class=""><br class=""></div>Hologram has an API. Authentication is either by API key or username+password (from <a href="http://hologram.io" class="">hologram.io</a>). So, we could ask for the hologram  credentials and then request to activate the SIM:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><span style="color: rgb(88, 71, 115); font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 14px; font-variant-ligatures: normal; orphans: 2; widows: 2; background-color: rgb(250, 250, 252);" class="">POST <a href="https://dashboard.hologram.io/api/1/links/cellular/bulkclaim" class="">https://dashboard.hologram.io/api/1/links/cellular/bulkclaim</a><br class=""><br class="">(the data is JSON containing things like the SIM ICCID, plan, zone, orgid (from user account), etc)</span></div></blockquote><div class=""><div><br class=""></div><div>For example, to retrieve your own account information:</div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div>$ curl --verbose GET '<a href="https://dashboard.hologram.io/api/1/users/me" class="">https://dashboard.hologram.io/api/1/users/me</a>' -u <emailaddress>:<password></div></div><div><br class=""></div><div>or, using an API key:</div><div><br class=""></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">$ curl --verbose GET '<a href="https://dashboard.hologram.io/api/1/users/me" class="">https://dashboard.hologram.io/api/1/users/me</a>' -u apikey:<apikey></span></div></blockquote><div class=""><div><br class=""></div><div>I don’t see any API to create a hologram account.</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 17 Feb 2020, at 3:04 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I guess about 50% of new user support requests are related to not understanding ’server password’, with the other 50% being vehicle ID registration and modification.<div class=""><br class=""></div><div class="">From a user’s point of view, they are very aware of web service usernames and passwords. They know how to register for an account, and are used to it. They know that when they get an App, they put in the corresponding website credentials and it simply works.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On auth: I think #1 will not help that much. #2 is an option. Most needed is a way to bypass the need to register user & vehicle on the server first. After filling in the module ID & password, there should be an option to create a new server + vehicle account and retreive the credentials simply by clicking a button (as outlined previously: <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182" class="">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182</a>).</div></blockquote><br class=""></div><div class="">We have a to be careful, because many users have more than one vehicle on their account (at least on my server). I think from the user interface point of view it should be server username/email and password. We may implement it differently under the hood, but keep it as simple as possible for the user. Note that v3 MQTT works off username+password as well.</div><div class=""><br class=""></div><div class="">An API so that this could be done from the server / app makes good sense. Not too hard to do (in a standard way, with plugins for different backend servers). Something like:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Which server would you like to use?</li><li class="">Do you already have an account?</li><ul class=""><li class="">Yes: Enter username and password, then validate</li><li class="">No: Provide a form to register a new account, then create</li></ul><li class="">What ID would you like to use for this vehicle?</li></ul></div><div class=""><br class=""></div><div class="">I too would like to do away with pre-registered vehicle IDs, and was thinking about ways around this last week. The way I see this working is:</div><div class=""><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">When the module logs on with a particular user+password and vehicle ID, if the vehicle record doesn’t exist we can simply add it. This is similar to the way MQTT does it.</li><li class="">For the Apps, we can provide an API to enumerate the available vehicle IDs for user selection. I also like your suggestion for a QR code on the module for quick App setup.</li><li class="">The server can continue to show the registered vehicles on each account.</li><li class="">However, there is one issue here in that for v2 the vehicle ID must be unique on that server. For MQTT, it only needs to be unique for each user.</li><li class="">We should change the database structure, and ovms_server.pl code, to add owner ID as a key field (along with Vehicle ID), to address this. The change is not too complex.</li></ul></div></div><div class=""><br class=""></div><div class="">I did spend some time reviewing the v2 protocol, and it seems easy to add another protocol scheme. Our current scheme 0x30 is for RC4 encryption based on the server password. We can add say 0x40 for just plaintext within SSL. The MP-C and MP-A methods currently pass the encryption scheme, followed by some secure tokens and the vehicle ID for authentication. The 0x40 scheme can simply be passed the desired vehicle ID, plus the server username/email and password (or authentication token).</div><div class=""><br class=""></div><div class="">The other thing to think about is the password itself. If we simply use server username/email and password, then it becomes an issue if the password is changed. Suddenly, three different systems break. The module in particular is worrying (as a password change on the server would break the module). So perhaps best to use tokens, and have a way for a module/app to request a persistent token. We could present that on the server as authorised apps/modules, and provide a facility to cancel (delete) a token. That is a lot more secure as the user can easily see what is authorised. My suggestion is that authentication works based on:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Either server username OR server eMail address</li><li class="">Either server password OR authentication token</li></ul></div><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0);" class="">Whatever we do, the concentration should be on v3 MQTT protocol. We need to eventually migrate the Apps to that, as it is the future. The other option is to forget about supporting this in v2, and concentrate solely on v3 MQTT. Get this new arrangement working with v3, upgrade the Apps to support it, and then migrate to that.</span></div><div class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></div><div class="">Regards, Mark.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 16 Feb 2020, at 8:04 PM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div class="">
    Deployed on my server as well.<br class="">
    <br class="">
    I've also added enabling TLS by default to the setup wizard, so new
    users by default will have strong encryption.<br class="">
    <br class="">
    The V2 connection performance is much better than with
    HTTP.Request(), even the initial connect is done within ~3 seconds
    normally. TX/RX afterwards has no significant delay.<br class="">
    <br class="">
    On auth: I think #1 will not help that much. #2 is an option. Most
    needed is a way to bypass the need to register user & vehicle on
    the server first. After filling in the module ID & password,
    there should be an option to create a new server + vehicle account
    and retreive the credentials simply by clicking a button (as
    outlined previously: <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182" class="">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/182</a>).<br class="">
    <br class="">
    Maybe we can also provide a similar option for the Hologram
    registration, or at least some way to hand over the ICCID for
    registration.<br class="">
    <br class="">
    Filling in credentials manually must still be possible of course,
    but the standard case of a new user would be simplified as far as
    possible.<br class="">
    <br class="">
    OAuth could simplify the App connection, but not substantially -- it
    would only allow to skip entering the password. A better option here
    would be to display the full App credentials as a QR code during the
    setup (and on the server page), so the user just needs to scan that
    to configure the App.<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Am 11.02.20 um 07:27 schrieb Mark
      Webb-Johnson:<br class="">
    </div>
    <blockquote type="cite" cite="mid:B0E2840C-DF9C-410C-8C28-55A2A43C46F7@webb-johnson.net" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
      <div class=""><br class="">
      </div>
      I looked into #6 (iOS App) and #5 (OVMS Server) and switching to
      use SSL is trivial in both.
      <div class=""><br class="">
      </div>
      <div class="">The commit for the server side is already done and
        pushed. Running as tcp/6870 on <a href="http://www.openvehicles.com/" class="" moz-do-not-send="true">www.openvehicles.com</a> server.
        Perhaps @michael can do the same on his (so the servers are at
        least ready for this)?</div>
      <div class=""><br class="">
      </div>
      <div class="">But before doing the iOS App, I think we should
        discuss the bigger issue of authentication and passwords. Once
        we SSL encrypt (and authenticate the server), we no longer need
        to use the password for encryption (although we do need to use
        something for authentication). Looking at a recent intro video
        for OVMS reminded me of how many passwords we current have:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ul class="MailOutline">
          <li class="">Website user account and password</li>
          <li class="">Vehicle ID</li>
          <li class="">Server password</li>
          <li class="">Module password</li>
          <li class="">Hologram account + password</li>
        </ul>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">I think we must have website user account and
        password. Some identifier for the vehicle is also probably
        necessary (so we can have more than one vehicle per account). If
        we use the website user+password for authentication, we don’t
        need the server password (which is the one that causes the most
        confusion). The module password perhaps needs to stay for local
        admin. Same for hologram (unless we offer packages with credits
        purchased under <a href="http://openvehicles.com/" class="" moz-do-not-send="true">openvehicles.com</a> or the server -
        which is something I have been reluctant to do).</div>
      <div class=""><br class="">
      </div>
      <div class="">We can remove the requirement for server password in
        one of two ways:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">Simply extend/replace the MP-C / MP-A calls to
            have an authentication mechanism passing the website user,
            website password, and vehicle ID. The server would then
            validate the user and password provided, and ensure that the
            provided Vehicle ID matches a registered vehicle for that
            user. No more ’server password’. This is close to what the
            mqtt v3 protocol does already (except it doesn’t need the
            vehicleid as everyone’s namespace is kept separate).<br class="">
            <br class="">
          </li>
          <li class="">Move to an authentication token system. Have some
            API (HTTP or within the v2 protocol) to authenticate website
            user+password and return a token (stored persistently in a
            database). Subsequent API calls can simply pass that token
            to authenticate themselves. A page on the website (similar
            to our current vehicles page) could show the authenticated
            tokens (apps/cars) and allow them to be cleared. There are
            various standard mechanisms for this, and it is considered
            better suited to API style usages with third party apps.</li>
        </ol>
      </div>
      <div class=""><br class="">
        <div class="">There is also the whole OAUTH thing we could just move to
          (probably in combination with option 2).</div>
        <div class=""><br class="">
        </div>
        <div class="">What do people think?</div>
        <div class=""><br class="">
        </div>
        <div class="">Regards, Mark.</div>
        <div class=""><br class="">
          <blockquote type="cite" class="">
            <div class="">On 10 Feb 2020, at 11:24 AM, Mark Webb-Johnson
              <<a href="mailto:mark@webb-johnson.net" class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8" class="">
              <div style="word-wrap: break-word; -webkit-nbsp-mode:
                space; line-break: after-white-space;" class="">
                <div class=""><br class="">
                </div>
                <div class="">Given that we use the mongoose library for
                  most of our stuff, adding SSL support should not be
                  hard. This would finally bring strong encryption and
                  server side authentication. Given the number of
                  attacks now on IoT devices that would not be a bad
                  thing.</div>
                <div class=""><br class="">
                </div>
                <div class="">I think what we need is:</div>
                <div class=""><br class="">
                </div>
                <div class="">
                  <ol class="MailOutline">
                    <li class="">A set of helper functions to make it
                      easier for components to use SSL. Build on top of
                      mongoose.<br class="">
                      <br class="">
                    </li>
                    <li class="">A way to manage a list of trusted
                      Certificate Authorities, including adding to the
                      trusted list via:<br class="">
                    </li>
                    <ul class="">
                      <li class=""><span style="caret-color: rgb(0, 0,
                          0);" class="">Components providing Certificate
                          Authorities in firmware.</span></li>
                      <li class=""><span style="caret-color: rgb(0, 0,
                          0);" class="">Certificate Authorities in
                          configuration.<br class="">
                          <br class="">
                        </span></li>
                    </ul>
                    <li class="">Extensions to ovms_server_v2 to support
                      an SSL connection option.<br class="">
                      <br class="">
                    </li>
                    <li class="">Extensions to ovms_server_v3 to support
                      an SSL connection option.<br class="">
                      <br class="">
                    </li>
                    <li class="">Extensions to the Ovms Server v2 code
                      to support an SSL connection listener.<br class="">
                      <br class="">
                    </li>
                    <li class="">Extensions to the iOS App to support an
                      SSL connection option.<br class="">
                      <br class="">
                    </li>
                    <li class=""><span style="caret-color: rgb(0, 0,
                        0);" class="">Extensions to the Android App to
                        support an SSL connection option.</span><br class="">
                      <br class="">
                    </li>
                    <li class="">Migration of any components already
                      supporting SSL to this new standardised approach.<br class="">
                      <br class="">
                    </li>
                    <li class="">Then we can open up the discussion of
                      the whole thing of passwords. We have far too many
                      of these at the moment (user account+password,
                      vehicle ID, server password, module password,
                      hologram account+password, etc). Once we have an
                      encrypted connection, we don’t need to use the
                      password for encryption, but merely for
                      authentication. That simplifies things, as we can
                      perhaps just use the user account+password for
                      most things (giving access to all vehicles
                      registered under that user account - in a similar
                      way to MQTT does it already for ovms_server_v3).</li>
                  </ol>
                </div>
                <div class=""><br class="">
                </div>
                <div class="">I will take on the majority of this
                  project. I can do #1, #2, #3, #4, #5, and #6).</div>
                <div class=""><br class="">
                </div>
                <div class="">If anyone has any feedback on
                  requirements, please let me know.</div>
                <div class=""><br class="">
                </div>
                <div class="">Regards, Mark.</div>
                <div class=""><br class="">
                </div>
              </div>
              _______________________________________________<br class="">
              OvmsDev mailing list<br class="">
              <a href="mailto:OvmsDev@lists.openvehicles.com" class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br class="">
              <a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class="">
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
      <br class="">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br class="">
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </div>

_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>