To quickly lay the groundwork: Traditional two-factor authentication relies on two elements during a login procedure, you have to present "something you know" and "something you have". A convenient and cost effective approach has been to use a password as the "know" element and a user's mobile phone as the "have" element, by e.g. sending a one time password (OTP) by SMS when the user is logging into a website. You've then verified that the person logging in knows the user's password and also possesses the user's cell phone. This increases confidence that the correct person is logging in.
Websites can leverage the benefits of two-factor authentication with mobile phones to reduce risk associated with virus infected PC's and password compromises. Google has a great explanation of the feature in their blog. However, Google is far from alone in launching this security measure, in fact there are online banks who have had such login procedures in place for several years. Just for the record.
Where it goes wrong
We've already seen malicious Android apps — if you steal a Google account you could silently install an application to steal SMSs on the mobile phone. Google has made the "something you know" element the key to gain control over the "something you have" element, reducing the authentication scheme to a traditional single password scheme. As Google, for now, primarily lets users log in with a static password they did not shoot themselves in the foot with the new store. It's everyone else relying on two-factor authentication with mobile phones who lost something here. Suddenly the security of an Android phone is dependent on the security of a Google account, which in turn reduces security for everyone else to single-factor authentication. In short, if a Trojan steals your banking password, it might as well steal your Google account and install malicious software on your Android phone to steal your banking SMSs.
But does Google realize what they've done? An online newspaper who picked up the story, quotes a Google representative saying that
...this theoretical attack presupposes a compromised Google account...Compromised Google accounts are far from theoretical. Off-the-shelf Trojans, such as the Zeus/Zbot, can easily be set up to steal Google account passwords. If we look at where Zeus is heading, it's apparent that Google's automatic application installation constitutes a massive security risk. New Zeus variants try to infect online banking customers' mobile phones, in order to steal their authorization codes received by SMS. With Google's new store, there's no need to trick the user into installing a mobile Trojan. The Trojan can easily steal the user's Google account and install the application silently. It is reasonable to assume that this approach will make it a lot easier for the Zeus mobile attack to scale, as today's approach depends on a manual step — requiring the user to confirm the installation of mobile malware.
But can it be done? It seems that the android-smspopup project covers the functionality needed. I also guess Google has documented the permission system well enough to start stealing SMS messages. Google needs to rethink the app store installation strategy, so as to not instantly kill Android phones as "security" devices.
How to fix it
Google should consider some design changes to their application installation procedure. An important countermeasure is mentioned on the Naked Security blog, a dialog should be shown on the device before application installation proceeds. I might add, it is utmost important that the dialog shows key information about the application, especially the permissions granted. It should also clearly state that installation should be denied unless the user herself triggered it from the store.
Another countermeasure is mentioned too, a strong password. For the Trojan scenario I've discussed here, the strength of your password is irrelevant. A Trojan will read a strong password just as easily as a weak password as you type it in.
To further raise the bar for automated installs of Andorid malware, they could consider using their two-factor authentication procedure (mentioned on their blog) to trigger application installation from the store. At least, they should keep this as a countermeasure in their toolbox so they can swiftly enable it if faced with a serious attack.