Gmail and Google Apps account hijacking has been the linchpin of a number of high-profile targeted attacks, starting with the Aurora attacks of 2009, right up until last week’s attack against the Twitter account belonging to the satirical Onion news site.
Granted we’re talking about two very different levels of severity between stealing data from the defense industrial base and sending out a few politically motivated hoax Tweets, but the thirst for legitimate credentials among state-sponsored hackers, cybercriminals and hacktivists won’t abate any time soon.
The chase, along with the general inadequacy of passwords, has forced Google for one to aggressively pursue a new direction for authentication into its online services. The company this week announced a new long-term plan for strong authentication, one that builds off a similar initiative in 2008 that led to the current implementations of two-factor authentication for Gmail and risk-based login challenges in order to determine if requests for access are indeed from the intended user.
Going forward, Google hopes to put strong authentication in place when endpoints such as laptops, tablets or smartphones are first configured and have the device act as an authenticator. It also explained a number of other measures it would like to see implemented in the relatively near future. Clearly, smart phones have changed the dynamic of authentication for Google.
“With mobile devices like Android the usability is even further improved because you only login to the device once at the OS level and it works across all the apps on the device instead of having to go through a multi-step login flow for each application,” said Eric Sachs, a product manager with the Google security team. “However to improve the usability of this approach, one of our goals will be to have a consistent concept of identity between the OS, applications, and websites accessed from the browser on the device.”
Google has also thrown its support behind the ChannelID open standard, which aims to secure the cookie on the device that certifies the user has signed in to a service. The concept puts up a barrier for man in the browser attacks that attempt to sniff and steal cookies as they’re passed to the browser. This tighter connection between cookies and encryption keys as proposed in the standard and currently in place in the Chrome browser is another priority initiative for Google going forward.
“In essence, the browser self-provisions an anonymous public-private key pair for each web domain it needs to talk to via SSL. The web domain can use the consistent SSL public key Channel ID presented by the client device to tie into cookies that it issues to the client device,” Sachs said. “But once the cookies are ‘tied’ in this manner, they are no longer reusable bearer tokens. The web server will only accept them as part of a connection that has been digitally signed with the same ChannelID. ChannelID significantly reduces the risk associated with leaked reusable bearer tokens.”
At the start of its initial five-year plan, Sachs said Google did not anticipate the use of smartphones as authenticators. But with apps providing one-time passwords, for example, Sachs said Google is experimenting with apps that display notifications about risky behavior and alert the user to approve an action within an app before moving forward. This would remove from the equation hackers who might have remote access to an app from gaining access.
“That type of ‘login approval’ approach has another interesting security aspect. While risk-based and strict two-factor login challenges do improve the security of a sign-in flow, they still have the potential to be broken through phishing attacks that trick a user into providing an OTP,” Sachs said. “But the ‘login approval’ approach makes phishing much harder and thus provides the potential to provide even stronger protection than Google’s two-factor offering.”
Google said it also is re-thinking how to unlock devices so that passcodes are no longer necessary, and involve the use of fingerprint scanners, Near Field Communication between devices, or proximity readers. These same concepts could be applied, Google said, where the OS would intervene when a risky behavior appears in the browser and request the user to approve it via a fingerprint check, for example. Google acknowledges this could require changes to APIs and how the OS and browser communicate.
“Once again, the time may be right given the ubiquity of personal devices such as mobiles and tablets,” Sachs said. “Further, the notion of a ‘local authentication’ to the device is becoming an accepted and expected part of the user experience.”
