Recently, Google announced that they will be adding another authentication factor to their login process for their online services. They indicate they will start with Google Apps and then expand into other services. Their blog post indicates the initial focus is on commercial users of Google cloud products. Google also states it will be offering this enhanced security to individual users but doesn’t go so far as to indicate exactly which or any roadmap of when services will be enabled.
I’m very interested to follow how Google has chosen to technically implement this additional authentication factor solution. It looks like they are leveraging an out-of-band distributed one-time password to make up the additional factor. Although I have yet to see the end user experience firsthand, the blog post above and image below would indicate one would have to register a cell phone number capable of receiving SMS text messages or a phone number that can receive an automated voice call.
It appears to be part of Google’s approach that once registered for their new authentication solution, when logging in on an “untrusted” computer, after the user successfully enters their password, they would be challenged for a one-time password sent as a text message to their cell phone or an automated voice call to their previously identified phone number. Upon successfully entering that one-time password within the timeframe Google determines it is valid, the user would then be granted access to their Google application.
How Does Google “Trust” a Computer?
The concept of identifying a specific computer as “trusted” was introduced back in around 2004/05 by companies like PassMark subsequently acquired by RSA subsequently acquired by EMC. The PassMark technical approach was to programmatic-ally capture data (HTTP “header fields”) that all web browsers and clients provide to web servers in order for the web server to determine the best way to return content back to that web browser or client. Information such as the client’s IP address, operating system version, browser version, with additional details via browser plug-ins such as Adobe’s Flash provides even more client specific information. The data that PassMark selected was propriety, but given the fixed number of data elements passed from client to web server, one could speculate on a finite number of possible variables to include.
The data elements were combined into an encrypted string stored as a browser disk based “cookie” that upon return to the web site, the web server would be presented with that previously encrypted cookie and verified to be the “same trusted computer”. If the decrypted cookie data didn’t match enough of the data presented by the browser making the current request, the computer could be considered “untrusted”.
Note: There a significantly more steps to make this a more secure process. I’ve only provided an extremely simplistic example for conceptual understanding.
Attackers Focus on “Trusted” Computer?
Unfortunately, no security solution is completely foolproof. As more details surface about how Google technically implements their solution, one possible weak link will be the “trusted computer” solution. If a fraudster can get the “cookie” or find a means to make their computer “trusted”, then the whole additional authentication factor could be bypassed.
I’ll be very interested to observe the security discussion on this as it inevitably unfolds as Google shares more details.