Welcome Guest. | Log In | Register | Membership Benefits

Google Could Drive Mobile Two-Factor Authentication Model

New Google Apps offering could overcome previous barriers to multifactor authentication

Sep 21, 2010 | 03:04 PM | 

By Ericka Chickowski, Contributing Writer

Google's announcement this week that it will offer two-factor authentication for Google Apps is an encouraging sign for the state of multifactor authentication in the cloud -- particularly using the mobile form factor, which some believe could overcome some of the challenges that have plagued multifactor deployments in the past.

The search engine giant's new two-factor approach sends a verification code via SMS message or mobile app to augment the traditional username and password sign-in. It's immediately available to premiere Google Apps customers and will be rolled out to standard users in the coming months, said Eran Feigenbaum, director of security for Google Apps, in a statement.

"When enabled by an administrator, it requires two means of identification to sign in to a Google Apps account, something you know: a password, and something you have: a mobile phone. It doesn't require any special tokens or devices," Feigenbaum said. "After entering your password, a verification code is sent to your mobile phone via SMS, voice calls, or generated on an application you can install on your Android, BlackBerry or iPhone device."

Google developed the two-factor authentication on an open standard to enable future integration with other vendors' authentication technology. "We are also open-sourcing our mobile authentication app so that companies can customize it as they see fit," Feigenbaum said.

Julian Lovelock, director of product management for ActivIdentity, says Google's two-factor authentication solution is good news for those who have been championing multifactor authentication. In particular, the mobile form factor it chose is indicative that organizations might be ready to transcend the major issue that has held back the progress of multifactor solutions for some time: the need to physically carry around tokens for each application that employs more than one factor of authentication.

End users tend to carry around mobile devices anyway, so they needn't have a keychain full of tokens to log in anymore. This could be huge for cloud applications, in particular, Lovelock says. "As you use more applications through the cloud, each one of those applications requires you to carry a separate physical device, that becomes a blocker," he says. "Mobile is a very neat way of resolving that because you can carry many different credentials for different cloud-based services on the same physical devices."

While using mobile devices to offer another factor of authentication is hardly new, it could finally be catching on as a result of changed user habits during the past year or so.

"I looked at mobile about two years ago, and at that time I reached the conclusion that it wasn't really viable because SMS texting didn't really have the same penetration in the U.S. as it does today," Lovelock says. "But if you look at it now, it's a very different story. There's a generation coming through that has grown up on texting, so [their] receiving SMS is second nature, and people are downloading apps onto their phones all the time."

However, some security experts wonder if mobile really is the best answer for a service like Google Apps, which requires continual logins throughout the day.

"How many people are going to want to take an SMS message every time they want to log into their e-mail?" says Phil Lieberman, founder of Lieberman Software. "It's impractical for e-mail, which is something you're accessing all day long. And any security that is inconvenient will generally not be used and discarded."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS












Featured Webcasts
Featured Whitepapers
Featured Reports
Bugs
ENTERPRISE VULNERABILITIES
Vulnerability:ssl-vpn end-point interrogator/installer activex control
Published:2010-11-03
Severity:High
Description:Stack-based buffer overflow in SonicWALL SSL-VPN End-Point Interrogator/Installer ActiveX control (Aventail.EPInstaller) before 10.5.2 and 10.0.5 hotfix 3 allows remote attackers to execute arbitrary code via long (1) CabURL and (2) Location arguments to the Install3rdPartyComponent method.
Vulnerability:gvim
Published:2010-11-03
Severity:High
Description:Untrusted search path vulnerability in VIM Development Group GVim before 7.3.034, and possibly other versions before 7.3.46, allows local users, and possibly remote attackers, to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse User32.dll or other DLL that is located in the same folder as a .TXT file. NOTE: some of these details are obtained from third party information.
Vulnerability:cforms
Published:2010-11-03
Severity:Medium
Description:Multiple cross-site scripting (XSS) vulnerabilities in wp-content/plugins/cforms/lib_ajax.php in cforms WordPress plugin 11.5 allow remote attackers to inject arbitrary web script or HTML via the (1) rs and (2) rsargs[] parameters.
Vulnerability:links, wsn links, wsn links
Published:2010-11-03
Severity:High
Description:Multiple SQL injection vulnerabilities in search.php in WSN Links 5.0.x before 5.0.81, 5.1.x before 5.1.51, and 6.0.x before 6.0.1 allow remote attackers to execute arbitrary SQL commands via the (1) namecondition or (2) namesearch parameter.
Vulnerability:deluxebb
Published:2010-11-03
Severity:Medium
Description:SQL injection vulnerability in misc.php in DeluxeBB 1.3, and possibly earlier, when magic_quotes_gpc is disabled, allows remote attackers to execute arbitrary SQL commands via the xthedateformat parameter in a register action, a different vector than CVE-2005-2989, CVE-2006-2503, and CVE-2009-1033.