Google unveiled on Wednesday a five-year roadmap for stronger consumer authentication tagging smartphones, long-life tokens, and futurist schemes to harden access controls while striking an unapologetic tone toward users who resist the change.
The plan will ultimately change Google's login system by breaking today's pattern that has end-users signing in over and over. In its place, Google will install strong authentication on a device such as a smartphone when it is setup.
A complex authentication code will replace the password and allow the device to identify itself, its user, participate in complex authentication flows, and recognize usage patterns that signal attacks.
"We will change sign-in to a once-per-device action and make it higher friction, not lower friction, for all users," said Eric Sachs, group product manager for identity at Google. "We don't mind making it painful for users to sign into their device if they only have to do it once."
Sachs, speaking at the IIW (Internet Identity Workshop) Conference in Mountain View, California, said that Google won't shy away from making transitions difficult on end-users in order to have better security in the long run.
Sachs said that Google will require all end-users to have two-factor authentication enabled. Today, Google and other websites offer it as an option.
Sachs said that Google will put research and development into specific areas, with the goal of altering today's authentication and authorization patterns. Those areas include authentication at setup, moving beyond the use of so-called bearer tokens that give access to whomever presents them, tapping into smarter hardware, and devising new methods for bootstrapping, device unlocking, and confirmations for "risky actions".
He did not say what Google was budgeting in terms of investment to develop the strategy.
In 2008, Google made a similar five-year authentication plan. The biggest areas of gain were risk-based login challenges, strict two-factor challenges, OpenID style login, and use of the OAuth authentication/authorization protocol so apps outside the browser did not have to ask for passwords.
Google and other vendors have made progress in these areas, and work continues.
Since 2008, Sachs said Google learned that account recovery was its Achilles' heel, that it was hard to get vendors to adopt OAuth, that OpenID migration was taxing, and most important, that "bad guys had evolved to more sophisticated attacks".
Sachs said the ugly truth is that there is a consistent identity for mobile applications, but not for browsers and websites.
Google said that the new five-year plan corrects one particular course it mis-judged in 2008.
"Five years ago, this level of smartphone adoption was not predicted," said Sachs. "We did not see that coming."
As a major part of the new plan, Sachs said that Google will weave smartphones and smart apps through a series of new authentication methods and back-end infrastructure changes.
He said Google likes the mobile model where applications are available once the user accesses the device.
"We plan to take our learnings from Android OS and apply it to Chrome, as well as taking lessons from how identity works for Android apps and apply it to web apps," according to the document outlining Google's plans.
Sachs said the ugly truth is that there is a consistent identity for mobile applications, but not for browsers and websites. "We need more plumbing, " he said.
He used an example of a "God-level OAuth token" that a smartphone could have at the operating system level to be used for authentication actions in the browser. "There is a lot of work to do here," he said.
Google will use smartphones and smart apps installed on devices to support one-time passcodes (OTP), portable OTPs, and new fangled schemes that can challenge users, such as presenting a map so users can verify the location they are logging in from.
Today, there are smart apps that generate OTPs even when a mobile phone does not have connectivity. Ultimately, Google hopes to require logins be performed where the proof of the second factor is much harder, if not impossible, to phish than OTPs.
Google also plans to develop methods that will accommodate users who don't have their phone. One example is where the user can access online a list of their devices that are connected to an account, and answer challenges there.
These sorts of schemes get around one problem with two-factor authentication (2FA), where one user on a shared account can't sign-in because they don't have the device receiving the verification code.
Google's plan relies heavily on smarter hardware, and will tap that hardware to try and make unauthorized access via social engineering, such as phishing, more difficult.
Sachs used the example of a web-based online banking application prompting the user to open up a smartphone version of the same app to click a confirmation button for a transaction, and to validate the authenticity of the web-based site.
Google will explore using technologies such as biometrics and Near Field Communication that lets users identify themselves, and allow one device to verify a new account on a second device. The bootstrapping of the device could go from Android to Chrome or Android to Android devices.
"We would prefer for a user to authorize a new device by having an existing device talk to it via a cryptographic protocol that cannot be phished," Google said in its strategy document.
Sachs said support of non-Google devices is being worked on via Google's participation in the Fast Identity Online (FIDO) Alliance, where it has teamed with hardware security token vendor Yubico on developing a new strong authentication protocol called Universal Second Factor (U2F).
Google said that in the future, it will request this method be used when consumers add an account to a new device. Google joined FIDO in late April.
Google will also explore how users unlock a device connected to their accounts, and how a user "confirms" they are indeed the ones performing "risky actions" on devices connected to their accounts.
Google will also work on back-end infrastructure, specifically public/private key pairs and server cookies stamped with a public key as defined in the IETF's ChannelID draft proposal.
Google does similar things today with its Chrome platform.
"In the future, it is our goal to allow early adopters to require the use of tokens 'tied' to public/private keypairs for any access to your account (from both apps and browsers)," Google wrote in its strategy document.
The ChannelID proposal focuses on how to protect the cookie on the device that proves the user previously signed in and reduces the risk associated with leaked reusable bearer tokens.
Also, Google plans to use more trusted platform modules (TPMs) and OAuth tokens on devices, and in the future, deprecate bearer tokens, which basically gives access to the presenter without challenge.