The keys-to-the-kingdom/Authentication-in-depth

Posted by:

admin 14 years, 8 months ago

The New York Times has an article with new details about the Google attack.  The key take-aways:

1.  The attackers took Google's SSO code, Gaia.

2.  The attackers "were able to gain control of a software repository used by the development team"

3. The attack started with one employee in China. While it is not stated, it sure sounds like the attackers got the user's Google work credentials:

By clicking on a link and connecting to a “poisoned” Web site, the employee inadvertently permitted the intruders to gain access to his (or her) personal computer and then to the computers of a critical group of software developers at Google’s headquarters in Mountain View, Calif. Ultimately, the intruders were able to gain control of a software repository used by the development team.

I'm assuming that Google uses the Gaia/SSO system internally.  If so, it might have been extremely easy for the attackers.  The article describes the attack as a "lightening raid taking less than two days".  It does seem to indicate that the internal use of Gaia made stealing Gaia quite simple. 

Using single sign-on creates this key-to-the-kingdom risk.  The solution is to require additional authentication for services that need extra protection. In fact, the first thing that you should do when designing a SSO roll-out is to decide what you do now want included!  However, what's to stop users from just using the same password?  What you really want is to bring two-factor authentication into the mix. 

Traditionally, I have said that if you roll out SSO, you should roll out two-factor authentication at the same time to protect the keys to the kingdom.  Based on these revelations I have two new proposals:  1.  Use a static password for SSO, but add two-factor authentication for key systems (in this case, Google code repository.  2.  Use two cryptographically distinct methods of authentication for SSO and key systems.

An example of the latter using WiKID would be to use the Locked PC tokens for SSO.  This helps assure that the user is on the corporate PC and provides some key-stroke logger protections.  Then use a wireless-token client only for key systems, further thwarting loggers and hopefully triggering some alarms when intruders attack!  While this requires users to have appropriate wireless devices, that's certainly not a problem for Google.  I happen to know of a two-factor solution that supports Android and has built-in support for Google's SSO already.

• Tags:
• Authentication Attacks,
• Information Security,
• Two Factor Authentication

• ← Best Practices
• Article on CSO: Two-factor authentication through Windows Server 2008 Net Policy Server →