The problem we could solve (re github etc.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux