Analysis of Google’s 2-step Verification
Research Paper
Michiel Appelman –
michiel.appelman@os3.nl
Yannick Scheelen –
yannick.scheelen@os3.nl
May 29, 2012
Abstract
Google 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’s smartphone with a special application, or sent tothe smartphone by voice call or SMS. For legacy applications, Google provides Application Specific Passwords that provide direct access to their ser-vices without needing a verification code. This pa- per will look if this verification system actually adds more security, not give the user a false sense of itand definitely not weakening it.
1 Introduction
In 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
HMAC -Based One-time Password
Time-based One-time Pass-word
(TOTP) algorithm[5]. The generated token
is 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 Password
s(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
Internet Message Access Protocol
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 in the 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 process
This 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
Research inMotion
(RIM)[7]. When a user chooses to use one
of these applications, the wizard proceeds to give alink where to download the application for the ap-propriateOSand 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, if the 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
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 anASP. 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 theASP.This name only functions as a labeland in theory can also be used for any other legacyapplication. TheASPis displayed only once andis intended to be entered immediately into the ap-plication for which it is used. Some of the servicesrequiring theseASPs are[8]:
1.POP,IMAPandSMTPmail protocols
2
2. Microsoft ActiveSync clients3. Jabber (Google Talk)4. Sync for Google Chrome5. Calendar clients6. YouTube clients on iOSIt is also important to note that theseASPs cannot be used to log in to the web browser interfaceof any Google service. When one of theASPs hasbeen compromised, the user can login to the web-interface and revoke access of that passwords.
3 Experiments
To 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 of the 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 Section2.3, theASPs are intro-
duced to bridge the gap between third-party ap-plications that don’t support 2-step verification yetand accounts that require 2-step verification. Thepasswords consist of 16 lowercase characters whichis fairly simple in appearance. If a pattern or weak-ness in theASPs can be found, it would leavemany third-party applications vulnerable to brute-forcing. We will investigate the strength of the gen-eratedASPs and also look closely at the dangers of having 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 ownASP,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 theASPs is that one is generated foreach application which requires one. However, ithas to be noted that theASPis not linked to thatspecific application and can thus be used as a pass-word for multiple services. The reason why Googleencourages multipleASPs 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 oneASP, we will haveaccess to every Google service that is accessible bya third-party application.
3.3 Backup codes
Section2.2.1explains 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 theASPs, 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
Search History:
Result 00 of 00
00 results for result for
p.
Analysis of Google's 2-Step Verification
Done for the Offensive Technologies course part of the MSc System & Network Engineering at UvA.
3.2K
Reads
3
Readcasts
1
Embed Views
Recommended
More From This User
Notes
Load more
