Analysis of Google's 2-Step Verification

Analysis of Google’s 2-step VerificationResearch Paper

Michiel Appelman – [email protected] Scheelen – [email protected]

May 29, 2012

AbstractGoogle offers its users a 2-step verification loginsystem which adds an additional layer of security,by asking for a verification code in combinationwith the username and password. This verifica-tion code has to be either generated on the user’ssmartphone with a special application, or sent tothe smartphone by voice call or SMS. For legacyapplications, Google provides Application SpecificPasswords that provide direct access to their ser-vices without needing a verification code. This pa-per will look if this verification system actually addsmore security, not give the user a false sense of itand definitely not weakening it.

1 IntroductionIn September 2010 Google introduced 2-step verifi-cation for their Google Apps users[1]. Enabling thisfeature would require corporate users to provide anextra verification code after logging in. This codecould be retrieved through an SMS text messageor voice message or through a token generator ona smartphone. After testing for some time Googleenabled it for all their users in February 2011[2].Users taking part in this experiment will have tofollow the same procedure to login to their account.Google’s 2-step verification requires something youhave (your smartphone) and something you know(your password) in order to get access to your ac-counts.

The token verification codes are generated on thesmartphone of the user using a time-based algo-rithm. These kind of tokens are not uncommon inthe security world, RSA has produced tamper resis-tant devices generating tokens for years now. Thefact that they are generated on the user’s smart-phone (really an untrusted devices) makes it easierfor attackers to retrieve the input necessary to comeup with the same tokens for a user.

The application that performs this token gener-

ation for the Google Services is called GoogleAuthenticator[3]. It is an open source project thatis available for Android, iOS and BlackBerry de-vices, as well as a Pluggable Authentication Mod-ule (PAM). The application generates one-timetime-based tokens using open standards, includ-ing the HMAC-Based One-time Password (HOTP)algorithm[4] and the Time-based One-time Pass-word (TOTP) algorithm[5]. The generated tokenis 6 digits in length and is valid for a 30 secondtimeframe.

When a user has enabled Google’s 2-step verifica-tion, his login process will be expanded with an ex-tra layer of security. First, the user still has to enterhis username and password as per usual, howeverhe will then be prompted to enter the 6-digit tokenthat has been generated for him on his smartphoneor sent to him through text message or voice call.

Before the application can generate tokens, it hasto be linked to the users’ Google account using oneof two possible methods. The link can be made ei-ther using a Quick Response (QR) code which iscreated by Google in the browser and has to bescanned by the device, or by using a secret key pro-vided by Google. Once the account is linked to thedevice, the Google Authenticator application canthen generate a token which is valid for 30 seconds,after that timeframe, a new token is generated timeand time again.

Besides these verification codes, Google suppliesthe user with Application Specific Passwords(ASPs). These passwords are generated by theGoogle 2-step system and used for third-party ap-plications for which you aren’t able to enter a ver-ification code, eg. a Post Office Protocol (POP)or Internet Message Access Protocol (IMAP) mailclient, the YouTube app on a smartphone or a chatclient. These ASPs can be generated only throughthe browser in the Google Account settings by theaccounts’ user. By changing the login procedureto the Google services, it is likely that this feature

1

could weaken the system[6].

Research Question

Because of these new types of security used on con-sumer products and the sense of security they giveto the users we have come to ask the question:

What security weaknesses can be found inthe Google 2-step verification system?

To answer this question, a multitude of angles haveto be researched: the smartphone application, theASPs, vulnerability to phishing attacks and othervectors that might surface during the research.

2 The 2-step processThis chapter discusses the process of the 2-step ver-ification system, from enabling to actually using it.

2.1 Enabling

The user wanting to use the 2-step verification pro-cess has to explicitly enable it on their Google ac-count page. This will spawn a setup wizard askingif he wants to receive the verification code througha text message or a voice call, or by generating thecode using an application on his smartphone.

2.1.1 Text message or voice call

This method enables users with a standard cellu-lar phone to receive verification codes from Google.They will have to enter their cellphone or landlinenumber and choose whether to receive a text mes-sages or voice call with a code which has to be en-tered to verify access to that phone. After success-fully entering this code, the verification system canbe enabled.

2.1.2 Mobile Application

Google has developed an Open Source verificationcode generator for three mobile platforms: Ap-ple’s iOS, its own Android Mobile Operating Sys-tem (OS) and the BlackBerry OS by Research inMotion (RIM)[7]. When a user chooses to use oneof these applications, the wizard proceeds to give alink where to download the application for the ap-propriate OS and presents the user with a so called‘secret’, which the application needs to generate theright codes. The code can be entered by scanning aQR-code (iOS and Android only) or by entering itmanually. When the application is configured cor-rectly, it will generate a code that is valid for 30seconds and the user is asked to enter this code toverify the set up.

2.2 Verifying

After the 2-step verification system has been en-abled, the user signing in on the browser will stillneed to enter their Google username and password.If this is successful the system will present the userwith an additional step in the form of an input boxasking for their verification code. At this point, ifthe user has chosen to receive the code using a textmessage this code will be sent to the provided num-ber, or in the case of a voice message, the providednumber will be called and it will read out the code.

If the user has chosen to use one of the mobile ap-plications, he will need to use the application togenerate the code and enter it while it is still valid.For this to work, it is essential that the date andtime on the cellphone are more or less synchronizedwith the Google servers. Fortunately, the defaultsettings on the supported platforms allow the de-vice to be synchronized by the Network Time Pro-tocol (NTP) over the network.

2.2.1 Backup Codes

Of course the situation can arise when a user has(temporarily) lost his phone. In this case Googleenables the user to print a small list of backupcodes beforehand. It is recommended that thissmall piece of paper is kept somewhere close to you,like a wallet. This recommendation is based onthe idea that you will always have them with you,should you need them. On the other hand the wal-let is also a safe place to store the paper becausethe user will notice more quickly when he has lostit and can take appropriate action by disabling thecodes.

2.3 Legacy Applications

The drawback of this new login procedure is thatthird-party applications, like e-mail clients, are notable to present the user with a dialogue to providea verification code. Google has solved this by dis-abling login to these legacy services with the normalpassword. To login to one of these services, the userfirst has to create an ASP. This is a randomly gen-erated code of 16 lower-case characters that is usedfor a specific service. Google asks the user to pro-vide the name of the service for which he is going touse the ASP. This name only functions as a labeland in theory can also be used for any other legacyapplication. The ASP is displayed only once andis intended to be entered immediately into the ap-plication for which it is used. Some of the servicesrequiring these ASPs are[8]:

1. POP, IMAP and SMTP mail protocols

2

2. Microsoft ActiveSync clients

3. Jabber (Google Talk)

4. Sync for Google Chrome

5. Calendar clients

6. YouTube clients on iOS

It is also important to note that these ASPs cannot be used to log in to the web browser interfaceof any Google service. When one of the ASPs hasbeen compromised, the user can login to the web-interface and revoke access of that passwords.

3 ExperimentsTo test the strength of the 2-step verification sys-tem, we are going to explore all the new differentsystems that Google has offered in order to loginto their services once 2-step verification is enabled.Our goal is to find a weakness in one of the new sys-tems or in their implementation. Also, since a lotof applications on smartphones don’t support the2-step verification process yet, we are going to in-vestigate which issues are present when moving thesecurity of your accounts into the hands of yoursmartphone.

3.1 Secret code on smartphones

Essential in the new 2-step verification process isthe generation of time-based tokens on the smart-phone of the user. This kind of verification is notnew and has been used by RSA Inc. on their Se-cureID token generators. These small devices aredesigned to be tamper-resistant to protect the datastored on it, even wiping all storage when it detectsthat it is being opened. Google has implementedthe same kind of functionality in their Google Au-thenticator application for three different smart-phone platforms. Interestingly, these devices arenowhere near tamper-resistant and this might ex-pose a vulnerability.

The secret entered during the enabling process ofthe system has to be stored on the devices. Wewill take a look at how secure this storage is, andhow we can extract the secret from it. This couldenable an attacker to generate the same codes on adifferent device.

3.2 Application Specific Passwords

As explained in Section 2.3, the ASPs are intro-duced to bridge the gap between third-party ap-plications that don’t support 2-step verification yet

and accounts that require 2-step verification. Thepasswords consist of 16 lowercase characters whichis fairly simple in appearance. If a pattern or weak-ness in the ASPs can be found, it would leavemany third-party applications vulnerable to brute-forcing. We will investigate the strength of the gen-erated ASPs and also look closely at the dangers ofhaving multiple passwords for the same account.

The fact that every application which relies on aservice that Google offers and that doesn’t support2-step verification can get its own ASP, means thatthe intricate security of Google’s 2-step verificationsystem relies on how third-party applications andplatforms handle your passwords. The scope of thisresearch focusses on the possible weakness that isintroduced by shifting this responsibility to mobiledevices, which is why the three supported mobileoperating systems are going to be investigated.

The idea of the ASPs is that one is generated foreach application which requires one. However, ithas to be noted that the ASP is not linked to thatspecific application and can thus be used as a pass-word for multiple services. The reason why Googleencourages multiple ASPs is because they can berevoked by the user, when they think a service hasbeen compromised. For our research this meansthat if we are able to find one ASP, we will haveaccess to every Google service that is accessible bya third-party application.

3.3 Backup codes

Section 2.2.1 explains why backup codes are of im-portance to the working of Google’s 2-step verifica-tion process. We are going to look into how thesecodes are generated, their strength and, similarlyto the ASPs, their entropy.

4 Results

4.1 Recover secret token from smartphone

We created our own Google account, wagthy@gmail(We Are Going To Hack You) on which all the ex-periments are done.

4.1.1 QR code

The QR code is generated by Google and embedsa One-Time Password Authentication (OTPAuth)link with the users’ email account and the secret,as illustrated in Figure 1 and Listing 1.

When we decode the QR code’s information, we getthe following link as output:

3

Figure 1: QR code generated by Google

otpauth://totp/[email protected]?secret=yc42tocu3xmjgd7q

Listing 1: OTPAuth URL

The same secret key is shown in the browser if themanual entry method is chosen. This key is gen-erated one time and can not be retrieved throughthe browser once the authentication process is com-pleted. Unless the attacker can scan the barcodewhile its displayed on the victim’s screen or copythe secret directly, there should be no way to getthe secret again.

However, we are going to investigate if the secretcan be retrieved from the smartphone devices andif the security of this system is in any way weak-ened by relying on the smartphones for an addi-tional layer of security.

4.1.2 Android

Once the [email protected] account was added tothe Google Authenticator application, we could tryand find the secret key in the Android file system.

The experiment was done on a rooted Android 4.0.4device. Since Android uses SQLite databases per-sistently to save information like metadata and evenpasswords, we are going to look for any databasefiles that could possibly have the secret key inside.

The Android flavour of our test device stores itsapplications and data in the /data/data folder.In there, we found the Google Authenticator datafolder (\data\data\com.google.android.apps.authenticator2) which contained a databasesfolder. The databases folder includes 4 databases:

• webview.db

• webviewCookiesChromium.db

• webviewCookiesChromiumPrivate.db

• databases

The webview.db was used as default in AndroidGingerbread 2.3.7 and below by applications tosave the user credentials in. Today, some applica-tions (Dropbox for example) still use this databaseto store the plaintext password and user creden-tials, however most new applications use OAuthtokens to interact with web services, making thewebview.db database legacy. For the Google Au-thenticator application, this database is empty.

The webviewCookiesChromium.db andwebviewCookiesChromiumPrivate.db databasesare used to store cookies and are less interestingfor us and for this application (they’re also empty).

The last database we found is conveniently calleddatabases and actually contained data. We wereable to query the database for its schemas and dis-covered a table accounts, querying this table gavethe following results:

sqlite > select * from accounts;1|[email protected]|yc42tocu3xmjgd7q|0|0|0

Listing 2: Databases database output

As shown in Listing 2, the account e-mail addressand the secret are simply stored in plain text onthe device. If an attacker manages to gain accessto the device, the secret can be retrieved relativelyfast and simple.

4.1.3 Apple iOS

To get access to the lower level of the iPhone filesys-tem, the device needs to be jailbroken in advance.Jailbreaking is the process of getting rid of some ofthe limitations imposed by Apple on their mobiledevices. The device we tested was jailbroken oniOS version 5.0.1 and so we were able to gain rootprivileges.

Using these privileges we were able to take a lookat the contents of the Google Authenticator appli-cation storage. Unlike the Android application, wewere not able to find the secret within the datastructure. The next place to look at this time isthe iPhone Keychain. The keychain is a passwordmanagement system developed by Apple to storethe passwords for various applications in a ‘secure’manner. To take a look at the contents of the key-chain we need to use a command line applicationcalled keychain_dump[9]. Secure Shell (SSH) needsto be enabled on the jailbroken device to get accessto a usable command prompt. When this is avail-able the three commands in Listing 3 are enoughto retrieve the contents of the iPhone keychain.

4

# wget http://iphone -dataprotection.googlecode.com/files/keychain_dump

# chmod a+x keychain_dump# ./keychain_dumpWriting 118 passwords to genp.plistWriting 41 internet passwords to inet.plistWriting 7 certificates to cert.plistWriting 11 keys to keys.plist

Listing 3: Commands to access keychain

The genp.plist file contains the data used by theGoogle Authenticator application in XML format.Listing 4 displays a section of this file with the rel-evant data. Here we can find a basic descriptorconsisting of the account name, some Base64 en-coded data and a ‘protection class’ defining thatthis secret is only available when the device is un-locked with the user’s passcode. This last setting isof importance because the aforementioned methodto retrieve the contents of the iOS keychain will notbe able to read the entries belonging to this protec-tion class without the passcode.

<dict><key>acct</key><string >[email protected]</string ><key>data</key><data>wLmpuFTd2JMP8A==</data><key>gena</key><data>b3RwYXV0aDovL3RvdHAvd2FndGh5QGdtYWlsLmNvbT8==

</data><key>protection_class</key><string >WhenUnlocked </string >

</dict>

Listing 4: iOS Keychain Data

The Base64 encoded data contained in the genakey contains some generic data. In this case,it decodes to ASCII and reveals the first partof the OTPAuth URL used in the QR code:otpauth://totp/[email protected]?. The datafield contains 80-bits of data representing the se-cret which was encoded in Base32 in the OTPAuthURL. This encoding improves readability becauseit only includes the lower-case alphanumeric char-acters and does not use the 1, 8, 9 and zero numericcharacters which in some cases could be mistakenfor alphanumeric characters.[10] Base32 is also usedin the URL to encode the data in a ‘web-safe’ way,meaning it does not contain the forward slash (/)and plus (+) characters which are valid URL di-viders. The Perl script in Listing 5 was used tocheck whether both values represented the samedata. This is indeed the case and thus we can con-clude that the secret has been successfully retrievedfrom the iOS device.

#!/usr/bin/perl -wuse MIME::Base32 qw( RFC ); # Use [A-Z,2-7]use MIME::Base64;

$dec32 = MIME::Base32::decode("YC42TOCU3XMJGD7Q");

$dec64 = MIME::Base64::decode("wLmpuFTd2JMP8A==");

if ($dec32 = $dec64) {print "Yep ,␣they’re␣equal\n";

}else {print "Different␣values ,␣sorry..\n";

}

Listing 5: Comparison of Base32 and Base64 values

Mobile Application

The application installed on the device to generatethe codes is fairly basic. It has a couple of fea-tures: a) adding an identity and secret by QR code,b) adding an identity and secret by manual text in-put, c) generating HOTP[4] or TOTP[5] tokens forthe configured identities. The source code for thedifferent applications is available on Google Code[7]and confirms the simplicity of the implementation.The code generation is completely based on theRFCs which aren’t really complicated either. Togive an idea of the simplicity the function to gen-erate the TOTP is given in Equation 1 where K isthe secret and T is the current Unix time dividedby 30 and rounded down to an integer.

TOTP (K,T ) = Truncate(HMAC-SHA-1(K,T )) (1)

Using a truncate function to shorten the HMAChash[11] the TOTP function reduces the 160-bithash to a 6-digit token. Fondling with the al-gorithm would yield negative results because theGoogle authentication server must run the samealgorithm to verify that the tokens match. Thesource reveals no other potential vulnerabilities.This holds true for all Google Authenticator mo-bile applications on other platforms.

4.1.4 BlackBerry OS

The Google Authenticator application forBlackBerry is limited by the fact that it cannot store new identities and secrets by scanningthe QR code but the user has to type it inmanually. Other functionalities are the same.

Retrieving the token generator secret from the de-vice is more difficult than the other two platforms.There doesn’t exist a ‘jailbreaking/rooting’ processfor the OS to get low-level access. We tried backing

5

up the device to a PC using the desktop software,but this backup consist only of messages, contactsand call-logs. It did not contain any passwords.A more low-level backup can be made by execut-ing the bbdump command from the desktop softwareprogram folder. This command-line program makesa backup of the filesystem designed for developers.Running it, puts the device in a non-responsivestate and takes 10-15 minutes. The resulting fileunfortunately is encrypted and we weren’t able todecrypt and extract the secret from it, pursuing thedecryption of the file would also lie far outside thescope of this project.

All new BlackBerry devices contain a special kindof storage called the ‘Persistent Storage’. This spe-cial area in the phone is persist between rebootsand resets and allows app writers to store login in-formation. The writer can wrap this information ina special ‘Controlled Access’ class to further limitthe access to the password.

Using the source code provided by Google we wereable to find out where exactly the secret was storedand this might allow us to extract it using a ma-licious application. The code displayed in List-ing 9 on Page 12 shows how the application requiresto be signed using a private code-singing key pro-vided by RIM. It writes preferences to the device’s‘PersistentStore’[12] with a controlled access[13] toonly allow applications signed using the same keyto read the information. This means that in or-der for us to retrieve the secret we would need tosign our own malicious code using Google’s privatecode-signing key.

4.2 Application Specific Passwords

4.2.1 ASP strength

The ASPs are constructed from 16 lower case let-ters. A simple calculation[2] shows that no lessthan 43 sextillion combinations are possible withthese letters, making the ASPs probably more se-cure than any standard user’s password.

2616 = 43, 608, 742, 899, 428, 900, 000, 000 (2)

Because of the ample amount of possibilities, we de-cided to investigate the entropy of these passwordsand see if there is a pattern to be found that wouldimprove the chances of brute-forcing an ASP. To dothis, we needed a large amount of ASPs to run thetest on.

We created a script that uses the stored cookie fromthe login session and uses curl1 with a for-loop to

1cURL - http://sourceforge.net/projects/curl/

create 500 ASPs and save them to a file. Googleallows a maximum of 500 ASPs so we created an-other script to automatically remove the generatedpasswords once they were all copied.

A total of 2000 passwords were created and the en-tropy was calculated as shown in appendix A. Theresults clearly show that the ASPs which are gen-erated are completely random. Graph 2 illustratesour findings.

4.3 Retrieving ASPs on Android

Google provides a full-fledged integration of its ser-vices on Android devices, it completely controlsthe development of the operating system allowingfor the default installed applications to perfectlyadhere to the Application Programming Interface(API) standards that are set by them.

As of Android 4.0, Ice Cream Sandwich, Google in-tegrates OAuth 2.0[14] for authentication and au-thorization of its services. OAuth 2.0 is a proto-col that allows a developer to integrate its appli-cation with Google’s OAuth 2.0 endpoints. Theapplication has to register with Google, redirect abrowser to a URL, parse a token from the response,and send the token to the Google API it wishes toaccess[15]. The result of the user authenticationsequence is an OAuth 2.0 access token.

When a Google account has 2-step verification en-abled and wants to register with an Android device,the Android device will first go through the samesteps as usual: request for a username and pass-word. However, after correct input of these param-eters the user is redirected to a browser page whichrequires the 6-digit verification code to be entered.Only when also the verification code is correct, willthe device by synced to the user account.

This means two things; first off, the Android ap-plications that provide access to Google servicesare both fully integrated and implement the OAuth2.0 protocol for authorization and authenticationto the services. This results in the fact that gen-erally, ASPs are not necessary when using an An-droid device. Secondly, the only thing that is savedon the Android device are the authorization tokenswhich are granted for every Google service applica-tion used on the device.

Even though ASPs are not needed for access to theGoogle services, they are replaced by authorizationtokens, or AuthTokens. Of course, the main dif-ference is that the AuthTokens are generated au-tomatically by Google’s OAuth 2.0 AuthorizationServer, whereas the ASPs require manual genera-tion and input.

6

However, their basic principle remains the same: astored string of characters which are used to autho-rize with API endpoints. Because the AuthTokensare not bound to any session or device specific in-formation, we realize that an adversary can use theAuthTokens to access any personal data which ismade available through the service API.

Similarly to the way we went about to find thesecret in Section 4.1.2, we investigated our An-droid system searching for where the AuthTokensare stored on the device.

We found that the database that contains all theAuthTokens is called accounts.db and is stored in/data/system. This database contains all AuthTo-kens for every Google account and Google servicethat is set up on the device. The output of a sim-ple query on the authtokens database provides uswith the complete list of AuthTokens (results aretruncated for clarity):

sqlite > select * from accounts;6|[email protected]|com.google|1/7

gLPlj0Il4uR9...sqlite > select * from authtokens;77|6|androidmarket|

DQAAAMsAAAAaOj2YpICoQsd89aS5...83|6|mail|DQAAAMgAAADuyIsbLHxlZ......

Listing 6: AuthTokens on Android

These tokens will only expire when the user changeshis password, or when they are revoked manually.This means that they can be copied and used byadversaries in secret on any other Android devicefor accessing the Google services, completely cir-cumventing the 2-step verification process.

Lastly, it is of course possible that an Android userwishes to use a third-party application to accesshis Google services (Trillian for multi-chat clients,MailDroid for alternative mailing, etc...). In thiscase, an ASP has to be generated for the appli-cation and the storage of this password relies com-pletely on the application developers. Research intowhether or not this is done is out of scope for thispaper. However, developers are encouraged to ad-here to Google’s Auth mechanism standards [16].

4.3.1 Retrieving ASPs on iOS

Storage of the Application Specific Passwords oniOS happens the same way as described in Sec-tion 4.1.3 and thus the same process for retrievingthem can be applied. As long as the device is jail-broken, unlocked and the user has SSH access toit, the keychain and its contents can easily be re-trieved. Note that we don’t even need the specific

IMAP ASP but can also use the ASP which hasbeen entered to use the YouTube application on thedevice, as any ASP can be used for all legacy appli-cations. Also, getting access to one of the ASPs ofthe user might not allow the attacker to completelytake over the account, but if the mail-account is alsoused as a primary account for other websites, theattacker might use the password reset function usu-ally provided by web services. It is of importancethat a user immediately revokes the correspondingASP as soon as signs of this start to appear or adevice has been lost.

4.3.2 Retrieving ASPs on BlackBerry OS

BlackBerry also uses the ‘Persistent Storage’ tostore the other types of passwords on the system.This means we face the same problems trying toretrieve them. The explanation of this storage andthe difficulties of retrieve them is given in Sec-tion 4.1.4.

4.4 Backup Codes

The backup codes are generated by the user to en-able them to login when he has (temporarily) lostpossession of his phone. The print-out contains 10codes with 8 numeric characters on a small pieceof paper. The codes can be checked, printed orrevoked using the 2-step verification web interface.Checking the codes allows the user to see how manyof the codes have already been used, implying thatevery code can only be used once. Revocation ofthe codes is achieved by simply generating a set ofnew codes, rendering the old codes useless.

To test the entropy of the backup codes, we used asmall curl script to extract 220 codes. Using thesame procedure as used in Section 4.2.1 the entropyof these codes was determined as shown in List-ing 8. Figure 3 on page 12 shows that this experi-ment yielded a positive result, clearly the codes aregenerated completely random. Of course it couldbe argued that there really is no ‘completely ran-dom’ sequence but this discussion lies far beyondthe scope of this project.

5 AnalysisThe smartphones have to store the secret to gen-erate the TOTP-codes locally in order to be ableto generate the verification codes, even when thereis no network connectivity. Because the secret isdisplayed only once after it is generated by Google,we researched weaknesses in the smartphones. OnAndroid the secret was stored in plain text en-coded with Base32 in the application’s own data

7

structure. On iOS the secret was stored in a bitmore secure manner by using the system’s keychaindatabase. Although this database can easily be ex-tracted on a jailbroken phone, it is still necessaryfor the user to first unlock it using the passcode.

On the other hand, when the iOS keychain databaseis extracted the attacker will also have possessionof all ASPs that the user has used and stored onthe phone. On the Android device ASPs are rarelyused because of the tight integration with the 2-step verification system. The user verifies himselfonce on first synchronization and after that the de-vice uses the AuthToken provided by the system tologin. This means that if the verification is done ona different phone, the TOTP-secret, nor the ASPswill be present on the phone.

The BlackBerry OS does store all user credentialsbut does so in a very secure manner. We were un-able to retrieve the secret or the ASPs from thedevice.

5.1 Mobile Application

We have investigated the Google Authenticator ap-plication by looking at its source code, which ispublicly available[3], and looking at the way theHOTP and TOTP algorithms have been imple-mented. The application is created with simplicityin mind.

The verification code generation algorithms havebeen implemented according to their RFC specifi-cations and the algorithms are dead simple, whichimproves their resilience to failure.

Tampering with the source code and manipulatingthe verification code generation algorithms wouldbe a futile approach since the verification codes thatare generated with the Google Authenticator ap-plication have to match with the ones created onGoogle’s servers. On the server side, the same al-gorithms are used as on the Google Authenticatorapplication and the verification codes are depen-dent on the time synchronization using the NTPprotocol. If the application on the user side wouldbe tampered with, these codes would not be thesame and logging in would fail. This is why wedidn’t attempt to hack the application itself, butrather use it as it is and try to exploit a possibleweakness with the secret code that is used to gen-erate the verification codes.

5.2 Authorization Tokens

As discussed earlier in this chapter, Android, be-cause of the full-fledged integration of the Google

services in the operating system, ASPs are gener-ally not used. Instead, Google uses the OAuth 2.0authorization and authentication protocol to au-thorize users with the Google services. In this sce-nario, the ASPs make way for individual AuthTo-kens that are generated automatically on the serverside for each Google service and are stored locallyon the device. Their function is fairly comparableto that of ASPs though; they’re a string of alphanu-merical characters that are checked by the GoogleAuthServer and if correct, access to the service end-point is granted. We reasoned that if an adversarywould get access to an Android device and if hewould be able to obtain the AuthTokens, he couldlogin to any Google service for which an AuthTokenis found, with any Android smartphone.

We tried to obtain these AuthTokens from our de-vice in a similar way as we did with the secretkey. Finding the local storage of the AuthTokensas done in Section 4.3 was very straightforward andhas shown that it is easy and fast to obtain thesetokens. Not only can the AuthTokens from theGoogle services be found, but also the main ac-count token that is used to authenticate and syncthe account with the phone. In theory, replicatingthese tokens on a different Android device wouldwork just as well as replicating ASPs and full ac-cess to the Google services would be achieved. Theonly requirement is, that the OAuth protocol ver-sion is the same on both the devices, as stated inthe RFC[14], OAuth 2.0 is not backwards compat-ible with OAuth 1.0 and thus tokens from version2.0 would not work with 1.0.

5.3 Bypassing CAPTCHAs

To log in using one of the backup codes, the userwill have to enter his username and password on theGoogle Account login-page and when asked to pro-vide the system with a verification code, enter oneof the backup codes. The user can provide threecodes in error before he has to solve a CAPTCHAto prove not to be a brute-force script. Althoughthis might sound like decent protection, the codesremain static indefinitely and could be cracked us-ing a custom written CAPTCHA-solver or a groupof workers solving them. For example, if 1,000workers will solve 1 CAPTCHA every 10 seconds,they would have tried all 100,000,000 possibilitieswithin 12 days. This might not sound realistic butwith sites like Death by Captcha2 asking only $1.39for 1,000 solved CAPTCHAs this is not unlikely tohappen.

2http://www.deathbycaptcha.com

8

6 Conclusion

Google’s 2-step verification system has been createdto provide its users with an additional layer of secu-rity. In order to test the strength of this relativelynew system, we have investigated a multitude ofangles trying to find a weakness that is presentedwhen using this system instead of the usual loginprocedure.

Google introduced several new concepts in order toallow for their users to have access to the Googleservices, these include Application Specific Pass-words, backup codes and the 6-digit verificationcode. The actual implementation of these conceptsare believed to be good.

The TOTP generated verification codes based ona synchronized time between a mobile device andthe Google servers provides a robust system that isnot prone to attacks. The same can be concludedfrom the concept of ASPs, which, because of theirlarge amount of possibilities and high randomness,are very secure passwords. Even though third-partyapplications often don’t employ CAPTCHAs, com-mon attacks such as brute-forcing or a dictionaryattack would not be feasible.

The backup codes that Google provides are decentin protection but because of the fact that thesecodes are indefinitely the same, an attacker couldwrite a custom CAPTCHA-solver to circumventthem and brute-force the 100,000,000 possibilities.Or even hire a company to do so.

Lastly, we looked at what possible security weak-nesses were introduced by shifting the responsibilityof a token generator to a mobile device. Each of thepreviously mentioned concepts have a role to playon the mobile devices.

We found that there is an issue with storing creden-tials in plain text on Android devices. Retrievingboth the secret needed for linking the user accountwith the Google Authenticator application and theAuthTokens can be done by performing a simpleSQL query on the right databases. If an attackergets physical access to an Android phone, obtainingthis information can be done fairly fast and simple.

The iOS application doesn’t use its own databaseto store the user information but takes advantageof the iOS keychain. This is a special database pro-vided by the system allowing programmers to limitthe access to their sensitive information. Unfor-tunately the contents of the database can be easilyobtained as long as the device can be jailbroken andis unlocked using the user’s passcode. The secret isstored in the keychain database in Base64.

The RIM BlackBerry OS has provided the program-mer with a secure way to store user credentials. Theuse of its Persistent Storage using a Controlled Ac-cess wrapper allows only applications signed withthe Google Authenticator code-signing key to re-trieve the secret from that storage. As this pri-vate key is only owned by Google it would be veryhard to get to that sensitive information. There-for BlackBerry has proven to be the least insecureplatform to store this data.

We calculated that a total of ∼43 sextillion possi-bilities are possible with the use of the 16 lower-case letters of the ASPs, far better than any stan-dard password used by users nowadays[17]. Therandomness of the ASPs proved adequate, with noletters being used distinctively more than others.The combination of the large amount of passwordpossibilities and the randomness of the generatedpasswords make these ASPs very secure, resultingin the fact that attacks such as brute-forcing, guess-ing, or dictionary attacks on the passwords are veryineffective.

Having the secret from the Google Authenticatorapplication would only be useful if the attacker hasthe user’s password as well, because that step ofauthentication would still have to be made. But,the AuthTokens and ASPs that can be obtainedfrom the Android and iOS devices can provide anattacker with access to the victim’s Google serviceswithout the victim ever knowing this, completelycircumventing the 2-step verification mechanism.

This leads us to conclude that the entire 2-stepverification implemented by Google is a very se-cure and robust additional layer of security. With-out the Google 2-step verification system enabled,an attacker would only require the user’s passwordand will have complete access to the data. Whenthe system is enabled by the user, in addition tothe password, the attacker would also need to havea) the user’s token within a 30 second interval, orb) the secret to generate a code himself, or c) oneof the backup-codes. When the attacker gets accessto one of the user’s ASPs, he will also have accessto a lot of services supported by the ASPs, but willnot be able to totally take over the Google account.Furthermore, the user can also revoke any and allof the ASPs to disable access from those passwords.

7 Further ResearchBecause we only had access to one rooted Android4.0 device, we were not able to try the replicationattack of the AuthTokens. With a second device,tests can be run to try and insert the database val-ues from one device into the other and recreating a

9

Google account from the ground up, through SQL.In theory, we believe that it is possible to gain ac-cess to all the Google services the hacked accounthas access to when the same AuthTokens are usedon a different device.

8 AcronymsAPI Application Programming Interface

ASCII American Standard Code forInformation Interchange

ASP Application Specific Password

CAPTCHA Completely Automated Public Turingtest to tell Computers and HumansApart

HMAC Hash-based Message AuthenticationCode

HOTP HMAC-Based One-time Password

IMAP Internet Message Access Protocol

NTP Network Time Protocol

OS Operating System

OTPAuth One-Time Password Authentication

PAM Pluggable Authentication Module

POP Post Office Protocol

QR Quick Response

RFC Request For Comments

RIM Research in Motion

SMTP Simple Mail Transfer Protocol

SSH Secure Shell

TOTP Time-based One-time Password

XML eXtensible Markup Language

10

A Application Specific Passwords Entropy checkjack@Jack:~$ cat asps -resolved.txt | sed ’s/./&\n/g’ | grep -v ^$ | sort | uniq -c |

sort -n1167 m1176 k1176 y1181 d1185 q1190 p1192 c1198 a1198 o1202 f1203 h1204 x1206 w1211 v1213 s1214 b1220 g1231 e1233 n1236 r1238 j1244 t1247 z1248 l1252 i1255 u

Listing 7: ASP entropy calculation

Figure 2: Graph of ASP entropy

0

1

2

3

4

a b c d e f g h i j k l m n o p q r s t u v w x y z

Perc

enta

ge o

f usa

ge

Characters

11

B Backup codes entropy checkjack@Jack:~/OTP$ cat bcodes1 | sed ’s/./&\n/g’ | grep -v ^$ | sort | uniq -c | sort -n

154 6161 7165 2168 1173 3173 5175 9185 0198 4199 8

Listing 8: Backup codes entropy calculation

1 2 3 4 5 6 7 8 9 100

2

4

6

8

10

12

Backup codes randomness

Numbers used

Pe

rce

nta

ge

of u

sag

e

Figure 3: Graph of backup codes entropy

C BlackBerry source codeprivate static final long PERSISTENT_STORE_KEY = 0x9f1343901e600bf7L;[..]static {

sPersistentObject = PersistentStore.getPersistentObject(PERSISTENT_STORE_KEY);sPreferences = (Hashtable) sPersistentObject.getContents ();if (sPreferences == null) {

sPreferences = new Hashtable ();}// Use an instance of a class owned by this application// to easily get the appropriate CodeSigningKey:Object appObject = new FieldUtils ();

// Get the public code signing keyCodeSigningKey codeSigningKey = CodeSigningKey.get(appObject);if (codeSigningKey == null) {

throw new SecurityException("Code␣not␣protected␣by␣a␣signing␣key");}

// Ensure that the code has been signed with the corresponding private keyint moduleHandle = CodeModuleManager.getModuleHandleForObject(appObject);if (!ControlledAccess.verifyCodeModuleSignature(moduleHandle , codeSigningKey)) {

String signerId = codeSigningKey.getSignerId ();throw new SecurityException("Code␣not␣signed␣by␣" + signerId + "␣key");

}

Object contents = sPreferences;

// Only allow signed applications to access user datacontents = new ControlledAccess(contents , codeSigningKey);

sPersistentObject.setContents(contents);sPersistentObject.commit ();

}

Listing 9: BlackBerry Secret Storage from AccountDb.java

12

D Bibliography

[1] Eran Feigenbaum, “A more secure cloud for millions of Google Apps users,” September 2010. http://googleenterprise.blogspot.com/2010/09/more-secure-cloud-for-millions-of.html.

[2] Nishit Shah, “Advanced sign-in security for your Google account,” February 2011. http://googleblog.blogspot.com/2011/02/advanced-sign-in-security-for-your.html.

[3] Google Inc., “Google Authenticator project,” April 2012. http://code.google.com/p/google-authenticator/.

[4] D. M’Raihi and M. Bellare and F. Hoornaert and D. Naccache and O. Ranen, “RF4226 – HOTP:An HMAC-Based One-Time Password Algorithm,” December 2005. http://www.ietf.org/rfc/rfc4226.txt.

[5] D. M’Raihi and S. Machani and M. Pei and J. Rydell, “RFC6328 – TOTP: Time-Based One-TimePassword Algorithm,” May 2011. https://tools.ietf.org/html/rfc6238.

[6] Stephen Rees-Carter, “Google application-specific passwords lowered my se-curity,” February 2011. http://stephen.rees-carter.net/2011/02/google-application-specific-passwords-lowered-my-security/.

[7] Google, “Google Authenticator on Google Code.” https://code.google.com/p/google-authenticator/.

[8] Google, “Signing in using Application-Specific Passwords.” https://support.google.com/accounts/bin/answer.py?hl=en&answer=185833.

[9] Jean-Baptiste Bédrune and Jean Sigwald, “iPhone data protection tools on Google Code,” April2012. https://code.google.com/p/iphone-dataprotection/.

[10] Ed S. Josefsson, “RFC3548 – The Base16, Base32, and Base64 Data Encodings.” https://tools.ietf.org/html/rfc3548.

[11] H. Krawczyk and M. Bellare and R. Canetti, “RFC2104 – HMAC: Keyed-Hashing for MessageAuthentication,” February 1997. https://tools.ietf.org/html/rfc2104.

[12] Research in Motion, “BlackBerry API Reference: Class PersistentObject.” http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/PersistentObject.html.

[13] Research in Motion, “BlackBerry API Reference: Class ControlledAccess.” http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/ControlledAccess.html.

[14] D. Recordon and D. Hardt, “The OAuth 2.0 Authorization Framework.” http://tools.ietf.org/html/draft-ietf-oauth-v2-22.

[15] Google, “Using OAuth 2.0 to Access Google APIs.” https://developers.google.com/accounts/docs/OAuth2.

[16] Google, “Choosing an Auth Mechanism.” https://developers.google.com/accounts/docs/GettingStarted.

[17] Matteo Dell’Amico and Pietro Michiardi and Yves Roudier, “Password Strength: An EmpericalAnalysis,” March 2010.

13