Analysis of Googles 2-step Verication

Research Paper
Michiel Appelman [email protected] Yannick Scheelen [email protected] May 29, 2012 Abstract
ation for the Google Services is called Google Authenticator[3]. It is an open source project that is available for Android, iOS and BlackBerry devices, as well as a Pluggable Authentication Module (PAM). The application generates one-time time-based tokens using open standards, including the HMAC-Based One-time Password (HOTP) algorithm[4] and the Time-based One-time Password (TOTP) algorithm[5]. The generated token is 6 digits in length and is valid for a 30 second timeframe.

Google oers its users a 2-step verication login system which adds an additional layer of security, by asking for a verication code in combination with the username and password. This verication code has to be either generated on the users smartphone with a special application, or sent to the smartphone by voice call or SMS. For legacy applications, Google provides Application Specic Passwords that provide direct access to their services without needing a verication code. This paper will look if this verication system actually adds When a user has enabled Googles 2-step vericamore security, not give the user a false sense of it tion, his login process will be expanded with an extra layer of security. First, the user still has to enter and denitely not weakening it. his username and password as per usual, however he will then be prompted to enter the 6-digit token 1 Introduction that has been generated for him on his smartphone In September 2010 Google introduced 2-step veri- or sent to him through text message or voice call. cation for their Google Apps users[1]. Enabling this Before the application can generate tokens, it has feature would require corporate users to provide an to be linked to the users Google account using one extra verication code after logging in. This code of two possible methods. The link can be made eicould be retrieved through an SMS text message ther using a Quick Response (QR) code which is or voice message or through a token generator on created by Google in the browser and has to be a smartphone. After testing for some time Google scanned by the device, or by using a secret key proenabled it for all their users in February 2011[2]. vided by Google. Once the account is linked to the Users taking part in this experiment will have to device, the Google Authenticator application can follow the same procedure to login to their account. then generate a token which is valid for 30 seconds, Googles 2-step verication requires something you after that timeframe, a new token is generated time have (your smartphone) and something you know and time again. (your password) in order to get access to your acBesides these verication codes, Google supplies counts. the user with Application Specic Passwords The token verication codes are generated on the (ASPs). These passwords are generated by the smartphone of the user using a time-based algoGoogle 2-step system and used for third-party aprithm. These kind of tokens are not uncommon in plications for which you arent able to enter a verthe security world, RSA has produced tamper resisication code, eg. a Post Oce Protocol (POP) tant devices generating tokens for years now. The or Internet Message Access Protocol (IMAP) mail fact that they are generated on the users smartclient, the YouTube app on a smartphone or a chat phone (really an untrusted devices) makes it easier client. These ASPs can be generated only through for attackers to retrieve the input necessary to come the browser in the Google Account settings by the up with the same tokens for a user. accounts user. By changing the login procedure The application that performs this token gener- to the Google services, it is likely that this feature 1

could weaken the system[6]. Research Question

2.2

Verifying

After the 2-step verication system has been enabled, the user signing in on the browser will still Because of these new types of security used on con- need to enter their Google username and password. sumer products and the sense of security they give If this is successful the system will present the user with an additional step in the form of an input box to the users we have come to ask the question: asking for their verication code. At this point, if the user has chosen to receive the code using a text What security weaknesses can be found in message this code will be sent to the provided numthe Google 2-step verication system? ber, or in the case of a voice message, the provided To answer this question, a multitude of angles have number will be called and it will read out the code. to be researched: the smartphone application, the If the user has chosen to use one of the mobile apASPs, vulnerability to phishing attacks and other plications, he will need to use the application to vectors that might surface during the research. generate the code and enter it while it is still valid. For this to work, it is essential that the date and 2 The 2-step process time on the cellphone are more or less synchronized This chapter discusses the process of the 2-step ver- with the Google servers. Fortunately, the default ication system, from enabling to actually using it. settings on the supported platforms allow the device to be synchronized by the Network Time Protocol (NTP) over the network. 2.1 Enabling The user wanting to use the 2-step verication process has to explicitly enable it on their Google account page. This will spawn a setup wizard asking if he wants to receive the verication code through a text message or a voice call, or by generating the code using an application on his smartphone. 2.2.1 Backup Codes

Of course the situation can arise when a user has (temporarily) lost his phone. In this case Google enables the user to print a small list of backup codes beforehand. It is recommended that this small piece of paper is kept somewhere close to you, like a wallet. This recommendation is based on 2.1.1 Text message or voice call the idea that you will always have them with you, This method enables users with a standard cellu- should you need them. On the other hand the wallar phone to receive verication codes from Google. let is also a safe place to store the paper because They will have to enter their cellphone or landline the user will notice more quickly when he has lost number and choose whether to receive a text mes- it and can take appropriate action by disabling the sages or voice call with a code which has to be en- codes. tered to verify access to that phone. After successfully entering this code, the verication system can 2.3 Legacy Applications be enabled. The drawback of this new login procedure is that third-party applications, like e-mail clients, are not 2.1.2 Mobile Application able to present the user with a dialogue to provide Google has developed an Open Source verication a verication code. Google has solved this by discode generator for three mobile platforms: Ap- abling login to these legacy services with the normal ples iOS, its own Android Mobile Operating Sys- password. To login to one of these services, the user tem (OS) and the BlackBerry OS by Research in rst has to create an ASP. This is a randomly genMotion (RIM)[7]. When a user chooses to use one erated code of 16 lower-case characters that is used of these applications, the wizard proceeds to give a for a specic service. Google asks the user to prolink where to download the application for the ap- vide the name of the service for which he is going to propriate OS and presents the user with a so called use the ASP. This name only functions as a label secret, which the application needs to generate the and in theory can also be used for any other legacy right codes. The code can be entered by scanning a application. The ASP is displayed only once and QR-code (iOS and Android only) or by entering it is intended to be entered immediately into the apmanually. When the application is congured cor- plication for which it is used. Some of the services rectly, it will generate a code that is valid for 30 requiring these ASPs are[8]: seconds and the user is asked to enter this code to verify the set up. 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 can not be used to log in to the web browser interface of any Google service. When one of the ASPs has been compromised, the user can login to the webinterface and revoke access of that passwords.

and accounts that require 2-step verication. The passwords consist of 16 lowercase characters which is fairly simple in appearance. If a pattern or weakness in the ASPs can be found, it would leave many third-party applications vulnerable to bruteforcing. We will investigate the strength of the generated ASPs and also look closely at the dangers of having multiple passwords for the same account.

The fact that every application which relies on a service that Google oers and that doesnt support 2-step verication can get its own ASP, means that the intricate security of Googles 2-step verication system relies on how third-party applications and platforms handle your passwords. The scope of this research focusses on the possible weakness that is 3 Experiments introduced by shifting this responsibility to mobile To test the strength of the 2-step verication sys- devices, which is why the three supported mobile tem, we are going to explore all the new dierent operating systems are going to be investigated. systems that Google has oered in order to login The idea of the ASPs is that one is generated for to their services once 2-step verication is enabled. each application which requires one. However, it Our goal is to nd a weakness in one of the new sys- has to be noted that the ASP is not linked to that tems or in their implementation. Also, since a lot specic application and can thus be used as a passof applications on smartphones dont support the word for multiple services. The reason why Google 2-step verication process yet, we are going to in- encourages multiple ASPs is because they can be vestigate which issues are present when moving the revoked by the user, when they think a service has security of your accounts into the hands of your been compromised. For our research this means smartphone. that if we are able to nd one ASP, we will have access to every Google service that is accessible by a third-party application. 3.1 Secret code on smartphones Essential in the new 2-step verication process is the generation of time-based tokens on the smartphone of the user. This kind of verication is not new and has been used by RSA Inc. on their SecureID token generators. These small devices are designed to be tamper-resistant to protect the data stored on it, even wiping all storage when it detects that it is being opened. Google has implemented the same kind of functionality in their Google Authenticator application for three dierent smartphone platforms. Interestingly, these devices are nowhere near tamper-resistant and this might expose a vulnerability. The secret entered during the enabling process of the system has to be stored on the devices. We will take a look at how secure this storage is, and how we can extract the secret from it. This could enable an attacker to generate the same codes on a dierent device. 3.2 Application Specic Passwords 3.3 Backup codes

Section 2.2.1 explains why backup codes are of importance to the working of Googles 2-step verication process. We are going to look into how these codes are generated, their strength and, similarly to the ASPs, their entropy.

4
4.1

Results
Recover secret token from smartphone

We created our own Google account, wagthy@gmail (We Are Going To Hack You) on which all the experiments are done. 4.1.1 QR code

As explained in Section 2.3, the ASPs are introduced to bridge the gap between third-party ap- When we decode the QR codes information, we get plications that dont support 2-step verication yet the following link as output: 3

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

Figure 1: QR code generated by Google

The webview.db was used as default in Android Gingerbread 2.3.7 and below by applications to save the user credentials in. Today, some applications (Dropbox for example) still use this database to store the plaintext password and user credentials, however most new applications use OAuth tokens to interact with web services, making the webview.db database legacy. For the Google Authenticator application, this database is empty. The webviewCookiesChromium.db and webviewCookiesChromiumPrivate.db databases are used to store cookies and are less interesting for us and for this application (theyre also empty). The last database we found is conveniently called databases and actually contained data. We were able to query the database for its schemas and discovered a table accounts, querying this table gave the following results:
sqlite > select * from accounts ; 1 | wagthy@gmail . com | y c 4 2 t o c u 3 x m j g d 7 q | 0 | 0 | 0

otpauth : // totp / wagthy@gmail . com ? secret = yc42tocu3xmjgd7q

Listing 1: OTPAuth URL The same secret key is shown in the browser if the manual entry method is chosen. This key is generated one time and can not be retrieved through the browser once the authentication process is completed. Unless the attacker can scan the barcode while its displayed on the victims screen or copy the secret directly, there should be no way to get the secret again. However, we are going to investigate if the secret can be retrieved from the smartphone devices and if the security of this system is in any way weakened by relying on the smartphones for an additional layer of security. 4.1.2 Android

Listing 2: Databases database output As shown in Listing 2, the account e-mail address and the secret are simply stored in plain text on the device. If an attacker manages to gain access to the device, the secret can be retrieved relatively fast and simple.

4.1.3 Apple iOS Once the [email protected] account was added to the Google Authenticator application, we could try To get access to the lower level of the iPhone lesysand nd the secret key in the Android le system. tem, the device needs to be jailbroken in advance. Jailbreaking is the process of getting rid of some of The experiment was done on a rooted Android 4.0.4 the limitations imposed by Apple on their mobile device. Since Android uses SQLite databases per- devices. The device we tested was jailbroken on sistently to save information like metadata and even iOS version 5.0.1 and so we were able to gain root passwords, we are going to look for any database privileges. les that could possibly have the secret key inside. Using these privileges we were able to take a look The Android avour of our test device stores its at the contents of the Google Authenticator appliapplications and data in the /data/data folder. cation storage. Unlike the Android application, we In there, we found the Google Authenticator data were not able to nd the secret within the data folder (\data\data\com.google.android.apps. structure. The next place to look at this time is authenticator2) which contained a databases the iPhone Keychain. The keychain is a password folder. The databases folder includes 4 databases: management system developed by Apple to store the passwords for various applications in a secure manner. To take a look at the contents of the key webview.db chain we need to use a command line application called keychain_dump[9]. Secure Shell (SSH) needs webviewCookiesChromium.db to be enabled on the jailbroken device to get access to a usable command prompt. When this is avail webviewCookiesChromiumPrivate.db able the three commands in Listing 3 are enough to retrieve the contents of the iPhone keychain. databases 4

# wget http : // iphone - datapr otecti on . googlecode . com / files / keychain _ dump # chmod a + x keychain _ dump # . / keychain _ dump Writing 118 passwords to genp . plist Writing 41 internet passwords to inet . plist Writing 7 certificates to cert . plist Writing 11 keys to keys . plist

# ! / usr / bin / perl -w use MIME : : Base32 qw ( RFC ) ; # Use [A -Z ,2 -7 ] use MIME : : Base64 ; $dec32 = MIME : : Base32 : : decode ( " YC42TOCU3XMJGD7Q "); $dec64 = MIME : : Base64 : : decode ( " wLmp uFTd2J MP8A = = " ) ; if ( $dec32 = $dec64 ) { print " Yep , they re equal \ n " ; } else { print " Different values , sorry . . \ n " ; }

Listing 3: Commands to access keychain The genp.plist le contains the data used by the Google Authenticator application in XML format. Listing 4 displays a section of this le with the relevant data. Here we can nd a basic descriptor consisting of the account name, some Base64 encoded data and a protection class dening that this secret is only available when the device is unlocked with the users passcode. This last setting is of importance because the aforementioned method to retrieve the contents of the iOS keychain will not be able to read the entries belonging to this protection class without the passcode.
< dict > < key > acct </ key > < string > wagthy@gmail . com </ string > < key > data </ key > < data > wLmp uFTd2J MP8A = = </ data > < key > gena </ key > < data > b3RwYXV0aDovL3RvdHAvd2Fnd Gh5QGdtYWlsLmNvbT8 == </ data > < key > protection _ class </ key > < string > WhenUnlocked </ string > </ dict >

Listing 5: Comparison of Base32 and Base64 values

Mobile Application The application installed on the device to generate the codes is fairly basic. It has a couple of features: a) adding an identity and secret by QR code, b) adding an identity and secret by manual text input, c) generating HOTP[4] or TOTP[5] tokens for the congured identities. The source code for the dierent applications is available on Google Code[7] and conrms the simplicity of the implementation. The code generation is completely based on the RFCs which arent really complicated either. To give an idea of the simplicity the function to generate the TOTP is given in Equation 1 where K is the secret and T is the current Unix time divided by 30 and rounded down to an integer.

Listing 4: iOS Keychain Data The Base64 encoded data contained in the gena key contains some generic data. In this case, it decodes to ASCII and reveals the rst part of the OTPAuth URL used in the QR code: otpauth://totp/[email protected]?. The data eld contains 80-bits of data representing the secret which was encoded in Base32 in the OTPAuth URL. This encoding improves readability because it only includes the lower-case alphanumeric characters and does not use the 1, 8, 9 and zero numeric characters which in some cases could be mistaken for alphanumeric characters.[10] Base32 is also used in 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 dividers. The Perl script in Listing 5 was used to check whether both values represented the same data. This is indeed the case and thus we can conclude that the secret has been successfully retrieved from the iOS device. 5

T OT P (K, T ) = Truncate(HMAC-SHA-1(K, T ))

(1)

Using a truncate function to shorten the HMAC hash[11] the TOTP function reduces the 160-bit hash to a 6-digit token. Fondling with the algorithm would yield negative results because the Google authentication server must run the same algorithm to verify that the tokens match. The source reveals no other potential vulnerabilities. This holds true for all Google Authenticator mobile applications on other platforms. 4.1.4 BlackBerry OS

The Google Authenticator application for BlackBerry is limited by the fact that it can not store new identities and secrets by scanning the QR code but the user has to type it in manually. Other functionalities are the same. Retrieving the token generator secret from the device is more dicult than the other two platforms. There doesnt exist a jailbreaking/rooting process for the OS to get low-level access. We tried backing

up the device to a PC using the desktop software, but this backup consist only of messages, contacts and call-logs. It did not contain any passwords. A more low-level backup can be made by executing the bbdump command from the desktop software program folder. This command-line program makes a backup of the lesystem designed for developers. Running it, puts the device in a non-responsive state and takes 10-15 minutes. The resulting le unfortunately is encrypted and we werent able to decrypt and extract the secret from it, pursuing the decryption of the le would also lie far outside the scope of this project. All new BlackBerry devices contain a special kind of storage called the Persistent Storage. This special area in the phone is persist between reboots and resets and allows app writers to store login information. The writer can wrap this information in a special Controlled Access class to further limit the access to the password. Using the source code provided by Google we were able to nd out where exactly the secret was stored and this might allow us to extract it using a malicious application. The code displayed in Listing 9 on Page 12 shows how the application requires to be signed using a private code-singing key provided by RIM. It writes preferences to the devices PersistentStore[12] with a controlled access[13] to only allow applications signed using the same key to read the information. This means that in order for us to retrieve the secret we would need to sign our own malicious code using Googles private code-signing key. 4.2 4.2.1 Application Specic Passwords ASP strength

create 500 ASPs and save them to a le. Google allows a maximum of 500 ASPs so we created another script to automatically remove the generated passwords once they were all copied. A total of 2000 passwords were created and the entropy was calculated as shown in appendix A. The results clearly show that the ASPs which are generated are completely random. Graph 2 illustrates our ndings. 4.3 Retrieving ASPs on Android

Google provides a full-edged integration of its services on Android devices, it completely controls the development of the operating system allowing for the default installed applications to perfectly adhere to the Application Programming Interface (API) standards that are set by them. As of Android 4.0, Ice Cream Sandwich, Google integrates OAuth 2.0[14] for authentication and authorization of its services. OAuth 2.0 is a protocol that allows a developer to integrate its application with Googles OAuth 2.0 endpoints. The application has to register with Google, redirect a browser to a URL, parse a token from the response, and send the token to the Google API it wishes to access[15]. The result of the user authentication sequence is an OAuth 2.0 access token. When a Google account has 2-step verication enabled and wants to register with an Android device, the Android device will rst go through the same steps as usual: request for a username and password. However, after correct input of these parameters the user is redirected to a browser page which requires the 6-digit verication code to be entered. Only when also the verication code is correct, will the device by synced to the user account.

This means two things; rst o, the Android applications that provide access to Google services are both fully integrated and implement the OAuth 2.0 protocol for authorization and authentication to the services. This results in the fact that generally, ASPs are not necessary when using an An2616 = 43, 608, 742, 899, 428, 900, 000, 000 (2) droid device. Secondly, the only thing that is saved on the Android device are the authorization tokens Because of the ample amount of possibilities, we dewhich are granted for every Google service applicacided to investigate the entropy of these passwords tion used on the device. and see if there is a pattern to be found that would improve the chances of brute-forcing an ASP. To do Even though ASPs are not needed for access to the this, we needed a large amount of ASPs to run the Google services, they are replaced by authorization tokens, or AuthTokens. Of course, the main diftest on. ference is that the AuthTokens are generated auWe created a script that uses the stored cookie from tomatically by Googles OAuth 2.0 Authorization 1 the login session and uses curl with a for-loop to Server, whereas the ASPs require manual genera1 cURL - http://sourceforge.net/projects/curl/ tion and input. 6

The ASPs are constructed from 16 lower case letters. A simple calculation[2] shows that no less than 43 sextillion combinations are possible with these letters, making the ASPs probably more secure than any standard users password.

IMAP ASP but can also use the ASP which has been entered to use the YouTube application on the device, as any ASP can be used for all legacy applications. Also, getting access to one of the ASPs of the user might not allow the attacker to completely take over the account, but if the mail-account is also used as a primary account for other websites, the attacker might use the password reset function usuSimilarly to the way we went about to nd the ally provided by web services. It is of importance secret in Section 4.1.2, we investigated our Anthat a user immediately revokes the corresponding droid system searching for where the AuthTokens ASP as soon as signs of this start to appear or a are stored on the device. device has been lost. We found that the database that contains all the AuthTokens is called accounts.db and is stored in 4.3.2 Retrieving ASPs on BlackBerry OS /data/system. This database contains all AuthTokens for every Google account and Google service BlackBerry also uses the Persistent Storage to that is set up on the device. The output of a sim- store the other types of passwords on the system. ple query on the authtokens database provides us This means we face the same problems trying to with the complete list of AuthTokens (results are retrieve them. The explanation of this storage and the diculties of retrieve them is given in Sectruncated for clarity): tion 4.1.4.
sqlite > select * from accounts ; 6 | wagthy@gmail . com | com . google | 1/7 gLPlj0Il4uR9 . . . sqlite > select * from authtokens ; 77 | 6 | androidmarket | DQAAAMsAAAAaOj2YpICoQsd89aS5 ... 83 | 6 | mail | D Q A A A M g A A A D u y I s b L H x l Z . . . ...

However, their basic principle remains the same: a stored string of characters which are used to authorize with API endpoints. Because the AuthTokens are not bound to any session or device specic information, we realize that an adversary can use the AuthTokens to access any personal data which is made available through the service API.

4.4

Backup Codes

The backup codes are generated by the user to enable them to login when he has (temporarily) lost possession of his phone. The print-out contains 10 codes with 8 numeric characters on a small piece Listing 6: AuthTokens on Android of paper. The codes can be checked, printed or revoked using the 2-step verication web interface. These tokens will only expire when the user changes Checking the codes allows the user to see how many his password, or when they are revoked manually. of the codes have already been used, implying that This means that they can be copied and used by every code can only be used once. Revocation of adversaries in secret on any other Android device the codes is achieved by simply generating a set of for accessing the Google services, completely cir- new codes, rendering the old codes useless. cumventing the 2-step verication process. To test the entropy of the backup codes, we used a Lastly, it is of course possible that an Android user wishes to use a third-party application to access his Google services (Trillian for multi-chat clients, MailDroid for alternative mailing, etc...). In this case, an ASP has to be generated for the application and the storage of this password relies completely on the application developers. Research into whether or not this is done is out of scope for this paper. However, developers are encouraged to adhere to Googles Auth mechanism standards [16]. 4.3.1 Retrieving ASPs on iOS small curl script to extract 220 codes. Using the same procedure as used in Section 4.2.1 the entropy of these codes was determined as shown in Listing 8. Figure 3 on page 12 shows that this experiment yielded a positive result, clearly the codes are generated completely random. Of course it could be argued that there really is no completely random sequence but this discussion lies far beyond the scope of this project.

5
Storage of the Application Specic Passwords on iOS happens the same way as described in Section 4.1.3 and thus the same process for retrieving them can be applied. As long as the device is jailbroken, unlocked and the user has SSH access to it, the keychain and its contents can easily be retrieved. Note that we dont even need the specic 7

Analysis

The smartphones have to store the secret to generate the TOTP-codes locally in order to be able to generate the verication codes, even when there is no network connectivity. Because the secret is displayed only once after it is generated by Google, we researched weaknesses in the smartphones. On Android the secret was stored in plain text encoded with Base32 in the applications own data

structure. On iOS the secret was stored in a bit more secure manner by using the systems keychain database. Although this database can easily be extracted on a jailbroken phone, it is still necessary for the user to rst unlock it using the passcode. On the other hand, when the iOS keychain database is extracted the attacker will also have possession of all ASPs that the user has used and stored on the phone. On the Android device ASPs are rarely used because of the tight integration with the 2step verication system. The user veries himself once on rst synchronization and after that the device uses the AuthToken provided by the system to login. This means that if the verication is done on a dierent phone, the TOTP-secret, nor the ASPs will be present on the phone.

services in the operating system, ASPs are generally not used. Instead, Google uses the OAuth 2.0 authorization and authentication protocol to authorize users with the Google services. In this scenario, the ASPs make way for individual AuthTokens that are generated automatically on the server side for each Google service and are stored locally on the device. Their function is fairly comparable to that of ASPs though; theyre a string of alphanumerical characters that are checked by the Google AuthServer and if correct, access to the service endpoint is granted. We reasoned that if an adversary would get access to an Android device and if he would be able to obtain the AuthTokens, he could login to any Google service for which an AuthToken is found, with any Android smartphone.

We tried to obtain these AuthTokens from our deThe BlackBerry OS does store all user credentials vice in a similar way as we did with the secret but does so in a very secure manner. We were unkey. Finding the local storage of the AuthTokens able to retrieve the secret or the ASPs from the as done in Section 4.3 was very straightforward and device. has shown that it is easy and fast to obtain these tokens. Not only can the AuthTokens from the 5.1 Mobile Application Google services be found, but also the main account token that is used to authenticate and sync We have investigated the Google Authenticator apthe account with the phone. In theory, replicating plication by looking at its source code, which is these tokens on a dierent Android device would publicly available[3], and looking at the way the work just as well as replicating ASPs and full acHOTP and TOTP algorithms have been implecess to the Google services would be achieved. The mented. The application is created with simplicity only requirement is, that the OAuth protocol verin mind. sion is the same on both the devices, as stated in The verication code generation algorithms have the RFC[14], OAuth 2.0 is not backwards compatbeen implemented according to their RFC speci- ible with OAuth 1.0 and thus tokens from version cations and the algorithms are dead simple, which 2.0 would not work with 1.0. improves their resilience to failure. Tampering with the source code and manipulating the verication code generation algorithms would be a futile approach since the verication codes that are generated with the Google Authenticator application have to match with the ones created on Googles servers. On the server side, the same algorithms are used as on the Google Authenticator application and the verication codes are dependent on the time synchronization using the NTP protocol. If the application on the user side would be tampered with, these codes would not be the same and logging in would fail. This is why we didnt attempt to hack the application itself, but rather use it as it is and try to exploit a possible weakness with the secret code that is used to generate the verication codes. 5.2 Authorization Tokens 5.3 Bypassing CAPTCHAs

To log in using one of the backup codes, the user will have to enter his username and password on the Google Account login-page and when asked to provide the system with a verication code, enter one of the backup codes. The user can provide three codes in error before he has to solve a CAPTCHA to prove not to be a brute-force script. Although this might sound like decent protection, the codes remain static indenitely and could be cracked using a custom written CAPTCHA-solver or a group of workers solving them. For example, if 1,000 workers will solve 1 CAPTCHA every 10 seconds, they would have tried all 100,000,000 possibilities within 12 days. This might not sound realistic but with sites like Death by Captcha2 asking only $1.39 for 1,000 solved CAPTCHAs this is not unlikely to happen.
2 http://www.deathbycaptcha.com

As discussed earlier in this chapter, Android, because of the full-edged integration of the Google 8

Conclusion

Googles 2-step verication system has been created to provide its users with an additional layer of security. In order to test the strength of this relatively new system, we have investigated a multitude of angles trying to nd a weakness that is presented when using this system instead of the usual login procedure. Google introduced several new concepts in order to allow for their users to have access to the Google services, these include Application Specic Passwords, backup codes and the 6-digit verication code. The actual implementation of these concepts are believed to be good.

The RIM BlackBerry OS has provided the programmer with a secure way to store user credentials. The use of its Persistent Storage using a Controlled Access wrapper allows only applications signed with the Google Authenticator code-signing key to retrieve the secret from that storage. As this private key is only owned by Google it would be very hard to get to that sensitive information. Therefor BlackBerry has proven to be the least insecure platform to store this data. We calculated that a total of 43 sextillion possibilities are possible with the use of the 16 lowercase letters of the ASPs, far better than any standard password used by users nowadays[17]. The randomness of the ASPs proved adequate, with no letters being used distinctively more than others. The combination of the large amount of password possibilities and the randomness of the generated passwords make these ASPs very secure, resulting in the fact that attacks such as brute-forcing, guessing, or dictionary attacks on the passwords are very ineective.

The TOTP generated verication codes based on a synchronized time between a mobile device and the Google servers provides a robust system that is not prone to attacks. The same can be concluded from the concept of ASPs, which, because of their large amount of possibilities and high randomness, are very secure passwords. Even though third-party applications often dont employ CAPTCHAs, com- Having the secret from the Google Authenticator mon attacks such as brute-forcing or a dictionary application would only be useful if the attacker has the users password as well, because that step of attack would not be feasible. authentication would still have to be made. But, The backup codes that Google provides are decent the AuthTokens and ASPs that can be obtained in protection but because of the fact that these from the Android and iOS devices can provide an codes are indenitely the same, an attacker could attacker with access to the victims Google services write a custom CAPTCHA-solver to circumvent without the victim ever knowing this, completely them and brute-force the 100,000,000 possibilities. circumventing the 2-step verication mechanism. Or even hire a company to do so. This leads us to conclude that the entire 2-step Lastly, we looked at what possible security weak- verication implemented by Google is a very senesses were introduced by shifting the responsibility cure and robust additional layer of security. Withof a token generator to a mobile device. Each of the out the Google 2-step verication system enabled, previously mentioned concepts have a role to play an attacker would only require the users password on the mobile devices. and will have complete access to the data. When We found that there is an issue with storing creden- the system is enabled by the user, in addition to tials in plain text on Android devices. Retrieving the password, the attacker would also need to have both the secret needed for linking the user account a) the users token within a 30 second interval, or with the Google Authenticator application and the b) the secret to generate a code himself, or c) one AuthTokens can be done by performing a simple of the backup-codes. When the attacker gets access SQL query on the right databases. If an attacker to one of the users ASPs, he will also have access gets physical access to an Android phone, obtaining to a lot of services supported by the ASPs, but will this information can be done fairly fast and simple. not be able to totally take over the Google account. Furthermore, the user can also revoke any and all The iOS application doesnt use its own database of the ASPs to disable access from those passwords. to store the user information but takes advantage of the iOS keychain. This is a special database pro7 Further Research vided by the system allowing programmers to limit the access to their sensitive information. Unfor- Because we only had access to one rooted Android tunately the contents of the database can be easily 4.0 device, we were not able to try the replication obtained as long as the device can be jailbroken and attack of the AuthTokens. With a second device, is unlocked using the users passcode. The secret is tests can be run to try and insert the database valstored in the keychain database in Base64. 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 access to all the Google services the hacked account has access to when the same AuthTokens are used on a dierent device.

8
API

Acronyms
Application Programming Interface American Standard Code for Information Interchange Application Specic Password

ASCII ASP

CAPTCHA Completely Automated Public Turing test to tell Computers and Humans Apart HMAC HOTP IMAP NTP OS Hash-based Message Authentication Code HMAC-Based One-time Password Internet Message Access Protocol Network Time Protocol Operating System

OTPAuth One-Time Password Authentication PAM POP QR RFC RIM SMTP SSH TOTP XML Pluggable Authentication Module Post Oce Protocol Quick Response Request For Comments Research in Motion Simple Mail Transfer Protocol Secure Shell Time-based One-time Password eXtensible Markup Language

10

Application Specic Passwords Entropy check

jack@Jack : ~ $ cat asps - resolved . txt | sed s / . / & \ n /g | grep -v ^ $ | sort | uniq -c | sort -n 1167 m 1176 k 1176 y 1181 d 1185 q 1190 p 1192 c 1198 a 1198 o 1202 f 1203 h 1204 x 1206 w 1211 v 1213 s 1214 b 1220 g 1231 e 1233 n 1236 r 1238 j 1244 t 1247 z 1248 l 1252 i 1255 u

Listing 7: ASP entropy calculation Figure 2: Graph of ASP entropy

Percentage of usage

0 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

Characters

11

Backup codes entropy check

jack@Jack : ~/ OTP$ cat bcodes1 | sed s / . / & \ n /g | grep -v ^ $ | sort | uniq -c | sort -n 154 6 161 7 165 2 168 1 173 3 173 5 175 9 185 0 198 4 199 8

Listing 8: Backup codes entropy calculation

8 6 4 2 0 1 2 3 4 5 6 7 8 9 10
Numbers used

Figure 3: Graph of backup codes entropy

BlackBerry source code

private static final long PERSISTENT _ STORE _ KEY = 0 x 9 f 1 3 4 3 9 0 1 e 6 0 0 b f 7 L ; [..] static { sP ers ist en t O b j e c t = Pe rs i st en t St o re . g e t P e r s i s t e n t O b j e c t ( PERSISTENT _ STORE _ KEY ) ; sPreferences = ( Hashtable ) s P e r s i s t e n t O b j e c t . getContents () ; if ( sPreferences = = null ) { sPreferences = new Hashtable () ; } // Use an instance of a class owned by this application // to easily get the appropriate Co deSign ingKe y : Object appObject = new FieldUtils () ; // Get the public code signing key CodeSigningKey code Signin gKey = C odeSig ningKe y . get ( appObject ) ; if ( codeSigningK ey = = null ) { throw new S e c u r i t y E x c e p t i o n ( " Code not protected by a signing key " ) ; } // Ensure that the code has been signed with the corresponding private key int moduleHandle = C o d e M o d u l e M a n a g e r . g e t M o d u l e H a n d l e F o r O b j e c t ( appObject ) ; if ( ! Contro l l e d A c c e s s . v e r i f y C o d e M o d u l e S i g n a t u r e ( moduleHandle , co deSign ingKey ) ) { String signerId = code Signin gKey . getSignerId () ; throw new S e c u r i t y E x c e p t i o n ( " Code not signed by " + signerId + " key " ) ; } Object contents = sPreferences ; // Only allow signed applications to access user data contents = new C o n t r o l l e d A c c e s s ( contents , codeS igning Key ) ; sP ers ist en t O b j e c t . setContents ( contents ) ; sP ers ist en t O b j e c t . commit () ; }

Listing 9: BlackBerry Secret Storage from AccountDb.java

12

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. googleblog.blogspot.com/2011/02/advanced-sign-in-security-for-your.html. [3] Google Inc., Google Authenticator project, google-authenticator/. April 2012. http://

http://code.google.com/p/

[4] D. MRaihi 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. MRaihi and S. Machani and M. Pei and J. Rydell, RFC6328 TOTP: Time-Based One-Time Password Algorithm, May 2011. https://tools.ietf.org/html/rfc6238. [6] Stephen Rees-Carter, Google application-specic passwords lowered my security, February 2011. http://stephen.rees-carter.net/2011/02/ google-application-specific-passwords-lowered-my-security/. [7] Google, Google Authenticator google-authenticator/. on Google Code. https://code.google.com/p/ https://support.google.com/

[8] Google, Signing in using Application-Specic Passwords. accounts/bin/answer.py?hl=en&answer=185833.

[9] Jean-Baptiste Bdrune and Jean Sigwald, iPhone data protection tools on Google Code, April 2012. 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 Message Authentication, February 1997. https://tools.ietf.org/html/rfc2104. [12] Research in Motion, BlackBerry API Reference: Class PersistentObject. //www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/ PersistentObject.html. [13] Research in Motion, BlackBerry API Reference: Class ControlledAccess. //www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/ ControlledAccess.html. http:

http:

[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. GettingStarted. https://developers.google.com/accounts/docs/

[17] Matteo DellAmico and Pietro Michiardi and Yves Roudier, Password Strength: An Emperical Analysis, March 2010.

13