Account Recovery should be the main authentication flow!

I’ve been thinking about “what’s next” in the world of wide-scale consumer authentication systems.
We hear a loud proclamations for death to passwords, when what we all really want is just death to intrusive, poorly designed, stop-gap logon systems.
So how should “better” be defined in this space?
Here’s one proposal that might change our expectations for the “who are you” experience: Treat every user authentication and identification event as an account recovery.
We often see asymmetric authentication designs: the front/main channel is smooth-ish and a well designed experience; careful design is used to avoid antagonizing the user; we get long periods between logons that are protected (we assume) by aggressive anti-fraud and anti-hacker detection and response systems in the background.
But when it comes to account recovery, we as users get the full range of inconvenient, painful, probably less secure options: secret questions; one-time links by email; SMS clues; code sheets and so on.
Why can’t the authentication providers give us a few strong multi-factor, physical authentication credentials (devices, tokens or cards) when they enrol us?
Then design the system to use those authentication credentials for any logon event – no ‘weaker’ flows that subvert the strength of the primary flow.
The consumer would be instructed to lock one of those physical credentials in a safe or a bank safe deposit box – to be retrieved in case of emergency to re-establish connection to their online accounts. But the flow would be basically identical to the main flow – so no user re-training required.
Given the anecdotes of high account recovery costs, wouldn’t it be cost effective to establish such a system?
Too simple? Devil’s in the details I suppose.
And the capabilities gap between professional authentication providers and closed, proprietary security systems.

New cloudy horizons

Getting going with a new adventure – Cloud Computing interoperability and federation standards. Goes with the theme of learning new things and pushing the brain-case into a new configuration.

Two full days of meetings coming up, setting up a plan, schedule and scope for building a cloud computing testbed to explore new stuff. I’m the project manager for an IEEE initiative.

Having been to a few cloud conferences so far this year, I’m learning that the view that the “cloud” is all about moving enterprise data centres into virtual locations is naive. Yes, virtualization is front and centre. But the hardware, how things are physically wired up, the virtualization software configuration, the data centre location on the planet, and other factors directly impact what the paying customer a) is able to ask for and b) receives. Compute and Storage resources are tailored for specific requirements. ‘Big Data’ analytics require certain configurations, Software as a Service needs others.

The commonality appears to be massively distributed resources. Keeping a very large application set in sync is massively difficult. Cloud providers do not give customers instrumentation or visibility into the virtual-physical interface. Rolling out uniform code to non-uniform hardware must be a nightmare to troubleshoot. But it is necessary.

In any case, I’m working with a team that is looking at how cloud service providers could federate and interoperate in the background – sharing resources to meet demand without customers having to handle the complexity of multi-provider resources.

Every day is a new adventure. It’s the best thing about diving into new waters. Stay tuned.