The problem we could solve (re github etc.)

[Phillip Hallam-Baker <[e-mail]>]

So we endlessly discuss problems we don't actually have much influence on.
Hope about authentication and authorization. Aren't we supposed to know
something about those?

Two IoT experiences today

1) Connecting to Ring doorbell on my phone

1) Cannot log into the App, because it thinks my password might have been
compromised. My doorbell sits outside my trusted perimeter and thus has the
same password as every other asset that I do not care about because it
isn't me who suffers the loss.

2) App directs me to reset password, sends a challenge message to my email.

3) I can't respond to the email because I don't have my email access on the
phone at the moment. So put the task off until I am at my desktop.

4) Log into Ring Web site, get fresh challenge,

5) Respond in my Gmail account

6) Try to log in to the Ring Web site, can't because I need a verification
code that can only come from a device running the app.

7) Give up because it is just too much hassle.

Second experience,

Log into my Nest account on the Web, get bounced to Google accounts to log
in. Can now view the status of my thermostat but not the status of my
doorbell because the whole point here is making people dependent on
subscription services.


Back in the Watson days, the IBM motto was 'Think!'. What seems to pass the
designers of these systems by is that absolutely the only reason to buy IoT
stuff is to make one's life easier. The Nest devices are going to have to
go because my wife is close to 'the Nest goes or I go' mode.

Looking at the Ring situation from a security point of view, it is of
course utterly absurd that they are relying on my gmail account to secure
their service but require four separate interactions just for one log in.
So compromise of the gmail account would utterly dominate anything they are
attempting to do but...


Lets face it, passwords aren't working and OAUTH is not the solution and
adding it into the mix most often just makes things worse.

Obviously, a transition to public key authentication can't happen overnight
but we could do it in stages:

1) Develop an infrastructure that makes it really easy to manage private
keys across multiple devices so that enabling a device to authenticate
itself as '@alice' or '@bob' is really easy.

2) Use the output of (1) to provide a public key based authentication
scheme that any social media or IoT or other service can use to replace
passwords. For important actions like financial transactions etc. we can
gate the action on provision of an additional factor (PIN, Biometric, etc.)
and for really important operations we can have confirmation.

3) Since the initial support for (2) will be near zero on day 1, also
develop a kick ass password manager that can be made ubiquitous, does not
require a subscription, copes with failures like lost devices etc. This
allows users to transition to using strong passwords that are different
everywhere.


Instead what we end up doing every single time is deciding that we can't
change the legacy infrastructure so we will do a botch job that has to work
round the constraints of the legacy infrastructure.

Oh and yes, I have specifications and running code. I am just writing the
shell for the host and the administration tool.