View from the C-Suite

Authentication at Scale

Eric Grosse and Mayank Upadhyay | Google

Google is investing in authentication using two-step verification via one-time passwords and public-key-
based technology to achieve stronger user and device identification.

I f bad actors can impersonate you to your service pro-

vider, they can do anything you can do. This includes
surprisingly destructive behavior, which they can blame
This area is ripe for innovation but isn’t the focus of
this article.
■■ Routine accounts are intended to be long-lasting and
on you. If you think you aren’t a likely target, remember to protect something of value but do not carry a risk
that attackers might not know you as an individual, but of large financial or reputational loss. An example
they might just want to leverage millions of high-repu- would be a subscription to an online newspaper.
tation accounts or leverage your account to get to a real We’d like our authentication methods to be conve-
target. So, strong authentication to avoid impersonation nient enough to apply to routine accounts. However,
is important. some say strong authentication in this case is overkill,
A well-accepted framework for authentication is and we wouldn’t disagree.
“something you know” paired with “something you ■■ Spokesperson accounts are widely understood to rep-
have.” In this article, we describe how Google makes resent users. Examples include a blog with a moder-
such a framework accessible to its diverse user base, ately large following or an account at an online store
what we’ve learned from working at scale, and some of with saved credit card numbers. Some might think
the directions we’re headed. that strong authentication is overkill here, too, but we
disagree; hijacking of spokesperson accounts is more
Account Types common than the general public realizes. The conse-
Not all accounts need strong authentication. We divide quences of a compromise can range from embarrass-
the spectrum of accounts by value: ment to extensive cleanup costs and financial loss.
■■ Sensitive accounts include an individual’s primary email
■■ Users might create throw-away accounts on the or online banking accounts. Here, loss of data, either
spur of the moment for testing, participating in a by deletion or public exposure, is commonly found to
pseudo-anonymous conversation thread, or making have severe and sometimes unforeseen consequences.
a one-time purchase without saving payment cre- ■■ Very high-value transaction accounts are specialized
dentials but with provision for checking order sta- systems used for irrevocable actions such as cross-
tus. Almost any lightweight authentication will do. border monetary flow and weapons release. Such

1540-7993/13/$31.00 © 2013 IEEE Copublished by the IEEE Computer and Reliability Societies January/February 2013 15
Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 View from the C-Suite

accounts justify stronger protections than are cov- a sophisticated password manager. This failure mode
ered in this article. remains among the most common preventable prob-
lems and was a prime motivation for the two-step verifi-
We focus on protecting access to what we call spokes- cation system we describe later.
person and sensitive accounts. Note that accounts might A closely related failure mode is offline brute-forcing.
move from one category to another over time. For Many advise choosing a high-entropy password (http://
example, a store account might be downgraded when xkcd.com/936) to harden password hashes, which may
its payment credentials expire. Upgrade is more com- be stolen by SQL injection attacks and other means.5
mon and less noticeable—for instance, when a Twitter Users sometimes type their password in the wrong
account accumulates more followers or a user registers text field or type a commonly used password rather
an email account as a bank- than the intended one
ing account recov- owing to muscle
ery backup. Security and usability problems memory. We haven’t
seen evidence that
are intractable: it’s time to give up
Common such lost passwords
Threats on elaborate password rules and are actively abused,
We contend that look for something better. but internal data on
security and usabil- Google employees
ity problems are indicates that such
intractable: it’s time to give up on elaborate password mistakes are common and can leak high-value pass-
rules and look for something better. Prominent exam- words. Internally, we mitigate this threat by forcing pass-
ples of today’s password authentication system failures word change when such a mistake occurs, but a better
include the “mugged in Madrid” scam directed against solution would be to use a password manager that under-
journalist James Fallows’ wife;1 the compromise of stands context and thus can prevent this confusion.
Sarah Palin’s email account during the 2008 presiden- Another authentication failure mode is the use of
2
tial election season; and most recently, the multiple easily guessed security question and answers, or as
account takeover of journalist Mat Honan. 3 wags say, “something you know” paired with “some-
People are reactive about security; it’s rational to thing everyone knows.” Even if nobody knows the
invest only as much effort as necessary to reduce risk name of your crush in the third grade, there are a finite
to an acceptable level. Even with an easier alternative to number of names to guess. A strong use of security
passwords, justifying transition costs would be difficult. Q&A is to make up random answers, write them down
So, we owe it to the reader to not only cite anecdotes in a safe place, and use them only for account recovery.
but also systematically list the common attacks used in Such security answers can be thought of as long-term,
the wild. stable passwords and resist capture by being stored
Phishing is a widely reported password failure offline and rarely used. Because few users will know to
mode: attackers lure users to a login page that looks operate in this mode and many would misplace their
like one they’re used to, perhaps by proxying to the real answers, it’s probably better to abandon the security
authentication server or by harvesting their passwords Q&A approach.
and even supplemental two-factor codes or security Malware infection is another class of failure mode.
questions and answers. By reading about the problem For example, Zeus logs keystrokes and steals authen-
or, even better, hearing about a security breach from tication tokens.6 Although it’s important for users to
friends and family and observing the pain it causes, run up-to-date software from trusted sources and some
users improve their chances of recognizing an attack. kind of antivirus scanning, these aren’t sufficient on
Password managers can help if they’re well integrated their own due to the constantly evolving threat of 0-day
with the device and browser, so passwords are used only attacks that exploit new and unknown bugs in today’s
with the correct sites. However, users would still need to complex software systems. Building more hardened
guard against clever attacks.4 platforms is still the best defense, but in this article
Reuse is another common password failure mode. we also discuss some approaches for channel binding
A password from a throw-away account at a weakly authentication tokens to the client device for which
defended site might be lost through intrusion, then used they were issued.
by attackers to access other, more valuable accounts. Perhaps most important, password loss can be
Common security advice is to pick a different password undetected, only to resurface later on other devices.
for each site. Although this advice is wise, using mul- Therefore, we aim to create consumer-ready tools
tiple passwords is burdensome unless combined with using hardware-protected public-key cryptography for

16 IEEE Security & Privacy January/February 2013

Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 both users and devices. Although other projects focus
on preventing harm from live malware controlling cli-
ent machines or from a server break-in, our goal in this
article is to prevent persistence. After recovering from
an attack, users should be able to regain control of their
accounts without losing any long-term credentials.
Because we focus on technical solutions, it’s worth Figure 1. After successfully typing the right password
acknowledging that some failure modes call for non- during sign-in, the user enters a code from a preregistered
technical solutions. Your roommate knows a lot about mobile phone. The user can choose to skip the code next
you, even when it’s safe to use your unlocked computer time on this particular browser.
without getting caught. Although continuity-based face
recognition can conceivably help in this situation, tech-
nology and cryptography aren’t the answer—you need In this model, strong user authentication is applied
to get a better roommate. only when acquiring a new device and when making
occasional sensitive transactions, such as setting up email
Device-Centric Authorization forwarding, deleting all mail, or making a large purchase.
Traditionally, user authentication requires that users Users will forget their passwords if these operations are
submit a bearer-token credential, such as a password, to rare, but that is okay. They should be able to write down
a client device, and the device forwards this on to the their password and store it in a safe place for these rare sit-
server. This model began at a time when users would uations, or have pairing techniques (such as short codes)
sit down at a simple terminal connecting to a time- to bootstrap any new device using an existing device.
shared computer. Today, the client device is much more Note that this model doesn’t necessarily apply to all
capable and might cache credentials for ease of use (for devices and use cases. For example, users might want
example, a Web browser with a password manager or a short-term relationship with a device, such as a bor-
mail clients that use the Internet Message Access Pro- rowed machine or kiosk. In this case, the device should
tocol [IMAP]). offer a guest mode with an obvious session termination
Instead, imagine that each client device has its own gesture that clears credentials and cached data.
strongly asserted identity. When you acquire a new
device, you “bless” it with the ability to access your Two-Step Verification
account. This delegation step might require the device As its first large-scale measure for client device authori-
to submit multiple factors on your behalf the first time zation, Google introduced an opt-in two-step verifica-
you access an account or require an out-of-band pair- tion feature, 2sv. As Figure 1 illustrates, first-time users
ing protocol. From then on, the device always asserts its log in to Google from a new computer (after passing
unique credential to the server. the traditional username/password authentication),
As a result of this delegation, your device (or your and then they’re asked for a six-digit verification code,
well-isolated profile on a shared device) is granted per- which might come from an SMS text message or a voice
manent access to your data. If you lose the device, you call to a preregistered phone, an offline application pre-
simply revoke that one instance of delegation; this is installed on a smartphone, or a one-time “scratch code”
clearly less painful than changing your password in the from a pregenerated list on their settings page. This code
traditional model, which requires reconfiguring all your sets a nonexpiring cookie in the browser that makes the
personal devices. Device-centric authorization also user’s device a recognized second factor, or a trusted
makes abuse detection easier because of the server’s computer, for all future authentication.
ability to distinguish between your multiple devices and Users can revoke their trusted computers under the
to observe their behavior individually. 2sv settings at accounts.google.com/security. Note that
Today, smartphones follow this model of delegating this revocation doesn’t erase any cached data on disk. We
full account access to a device. The OS is responsible for recommend using an encrypted file system and OS-level
activity timeouts and protecting the locked screen. Even user separation as a first line of defense against theft.
with a locked screen, the device retains account access Our experience with 2sv has been good. Adopted
so it can receive calendar updates, incoming chats, and by millions, it’s among the largest two-factor authenti-
so on. Devices are often configured to require a short cation deployments in the world. Nearly a quarter mil-
PIN to unlock the screen. Note that the low-entropy lion accounts added 2sv during the two days after Mat
PIN is of no use by itself to an attacker who might have Honan’s story broke, illustrating a phenomenon that we
tricked the user into revealing it somehow, much like an observe more broadly: people take security more seri-
ATM PIN is useless without the card. ously after an acquaintance or public figure has suffered

www.computer.org/security 17
Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 View from the C-Suite

harm. After studying hijacking campaigns directed at In Android OS versions Ice Cream Sandwich
high government officials, we found that among the and higher, 2sv users can set up their phones via a
hundreds whose password had been stolen, presumably browser-based sign-in flow that the system offers
by phishing, two officials had enabled 2sv and were suc- when a second factor is necessary. The browser flow
cessfully protected from compromise.7 enables a flexible HTML-based UI that incorporates
However, not nearly enough of our users are pro- a 2sv challenge, avoiding the need for ASP. Further-
tected, and we recognize that awkward corner cases more, Android’s centralized account management
and inadequate documen- model makes it unneces-
tation contribute sary for multiple
to this.8 We will In the future, we envision users will apps to ask the user
continue to polish for the same pass-
own enough authorized devices
the rough spots. To word and 2sv code;
minimize setup time, that they can always use an old instead, these apps
we encourage SMS device to authorize a new one. request the sys-
or voice delivery of tem account man-
2sv codes. Approxi- ager for short-lived
mately 10 percent of our users subsequently install and scoped tokens for the data they need to access. There-
provision the offline smartphone application for code fore, users in the Android ecosystem have an easier
generation, which doesn’t require working cellular ser- time setting up 2sv.
vice or even a registered phone number. Initially, we thought of 2sv as part of user authentica-
When deployed at scale, some users will experience tion, much like the one-time password (OTP) tokens
account lockout owing to lack of coverage while travel- that enterprises commonly require for remote authen-
ing, temporarily slow text message delivery, loss of the tication. To make 2sv practical for consumers, we
device, changing of mobile phones without requesting reduced the default verification requirement to once per
phone number portability, and so forth. We find that month. But, we found that 30 days is either too short
customer support for account recovery is crucial in or too long; it’s annoyingly frequent and disconcerting
wide 2sv deployment. when applied independently to every browser in every
Fortunately, many users set up backup modes for device and yet too large a window of vulnerability for a
code generation, such as home or work landlines, a fam- lost, unlocked device.
ily member or friend’s phone, and paper-based codes. We changed our mental model to treat 2sv primarily
These users tend to self-recover from issues related to as a means of permanently authorizing a client device.
loss of their primary 2sv code generator. We’ve also (Users can still achieve the old behavior if desired; the
found that the smartphone app users rarely need addi- 2sv validation page includes a checkbox that, if not
tional help because, among other reasons, they’re unaf- checked, indicates the 2sv cookie should expire at the
fected by message delivery issues. end of the browser session rather than last forever.)
Users with many client-side applications that allow Requiring verification once per month had a training
for only traditional username/password-based sign-in advantage; verification was frequent enough to remind
tend to have the hardest time setting up 2sv. Typical users to bring their phone when traveling or update
examples include IMAP-based mail clients on desk- their registered phone number after a change. Now if
tops and certain smartphones. To allow backward users go a long time without typing a 2sv validation
compatibility on those apps and devices, we provide code, we might remind them about their 2sv enrollment
a transition feature called application-specific pass- and phone number information and perhaps even ask
word (ASP). An ASP is intended to be a high-entropy for a practice code. But we won’t lock them out of their
machine-generated password that’s hard to remember account if the browser already has a valid 2sv cookie.
and consequently hard to phish. Unfortunately, the We’re reasonably satisfied with this balance.
same properties that increase such passwords’ secu- A final interesting observation about 2sv is that it’s
rity also cause friction for users. To fix this problem abused by account hijackers. After stealing the account
across the industry, we prefer that client platforms password and breaking in to the account, hijackers add
employ a centralized account management model 2sv (with their own phone number) just to slow down
with a browser sign-in option, as the Android OS does. account recovery by the true owner! Anecdotally,
Another weakness of ASP is the misimpression that it we’ve heard that the online game World of Warcraft—
provides application-limited rather than full-scope one of the few other consumer services that has very
account access. (OAuth, which we discuss later, is the widely deployed two-factor authorization—has seen
right tool for that job.) the same phenomenon.

18 IEEE Security & Privacy January/February 2013

Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 From a security perspective, 2sv is effective against available to the website to be passed down to the
the common failure modes of reused passwords and attached hardware. One of these APIs is called during
lost password hashes, but in the long term, it will be the registration step, causing the hardware to generate
ineffective against clever phishing. It won’t protect a new public-private key pair and send the public key
users against someone who steals both their pass- back to the website. The website calls the second API
words and phone. We’re aware of two targeted account during authentication to deliver a challenge to the
hijackings getting past 2sv: in one, the attackers alleg- hardware and return the signed response. The protocol
edly used social engineering against the phone net- specification calls for a key-generation process inside a
work, resulting in loss of SMS; in the other, they secure element with attestation and for the private key
allegedly used malware on the phone, resulting in loss to never be exposed outside.
of voicemail. Besides the physical controls we mentioned, addi-
tional privacy protections are built in to the 2sv token.
Smartcard-Like USB Token Note that the secure element never returns a previ-
With the current version of 2sv, users type a code into ously generated public key in any new registration
a new device to authorize it. To better protect against step. This makes tracking users across websites diffi-
phishing and, at the same time, to make the server side cult by using the token as a supercookie that bypasses
immune to authentication database theft, we’re inter- other anonymizing precautions. Furthermore, the
ested in smartcard-like solutions based on asymmetric browser provides the token with a hashed identifier
or public-key cryptography. of any website requesting a signing operation. This
Others have tried similar approaches but achieved allows the token to withstand tracking attempts in
little success in the consumer world. Although we rec- which a website shares the registered user’s public key
ognize that our initiative will likewise remain specula- with another website as well as datacenter intrusion
tive until we’ve proven large-scale acceptance, we’re attacks in which public keys are stolen. Finally, the
eager to test it with other websites, following three guid- protocol allows for extensions for the website to send
ing principles: a display string to the user, which we will use for anti-
malware mitigation.
■■ For maximum portability, this method mustn’t We recognize that multiple form factors are neces-
require software installation on the host other than a sary for broad consumer adoption. A removable USB-
compliant Web browser. based token with lean and audited firmware has a small
■■ One device should be sufficient with a reasonable attack surface for malware and a clear mental model for
number of websites for which users have accounts. privacy. However, having to carry an additional token
But, for privacy preservation, the websites mustn’t be is likely to be a barrier to adoption for many consum-
able to correlate users based on the device. ers. Some more appealing form factors might involve
■■ User device registration with target websites should integration with smartphones or jewelry that users are
be simple and shouldn’t require a relationship with likely to carry anyway. We’d like your smartphone or
Google or any other third party. The registration and smartcard-embedded finger ring to authorize a new
authentication protocols must be open and free for computer via a tap on the computer, even in situations
anyone to implement in a browser, device, or website. in which your phone might be without cellular con-
nectivity. For many users, travel is likely to present the
Our first implementation of such a solution has been need to sign in to a new machine. We’re finding that
an experimental USB token for 2sv. The token speaks on the biggest technological challenge isn’t cryptography
USB without needing special operating system device but the lack of a standardized interface on consumer
drivers. A higher-level protocol specifies packet formats platforms for device-to-device interaction in the real
for obtaining signed assertions from this token and can world. Some technologies with which we’re experi-
be exercised by application-level code on the host OS. menting are unsecured radio frequency communica-
The USB token also has a capacitive touch-sensitive area tion (RFCOMM) (unpaired Bluetooth) and near-field
for user confirmation. communication (NFC).
We’re currently working on an internal pilot of this In the future, we envision users will own enough
2sv token to validate the form factor and user experience. authorized devices that they can always use an old
Consumer provisioning should allow users to buy a com- device to authorize a new one and will only need a
pliant token from a vendor of their choice, insert it into a strong password for deep backup. As the overall authen-
computer where they’re already authenticated to a web- tication system strengthens, we predict that authoriza-
site, and register their token with a single mouse click. tion flow will be the next avenue of attack, so we seek to
A compliant browser will make two new APIs harden this process in advance.

www.computer.org/security 19
Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 View from the C-Suite

Channel Bindings This feature, called ChannelID in Chrome browser

We have been focusing on how clients authenticate to version 24, is being deployed with no user-visible effect.
the server because authentication in the other direc- It’s just a silent hardening of the platform, an unusually
tion is settled: Secure Sockets Layer (SSL) with server pleasant way to roll out new security features. In keeping
certificates. Let’s see now how SSL can harden client with the zero-user-interface design, deleting browser
authentication. history or cookies and site data will automatically delete
Entering a username and password in a Web login the corresponding domain key pairs. Moreover, alterna-
page for user authentication, or a 2sv code for client tive browser profiles and incognito mode use different
device authentication, sets a cookie in the browser’s local key pairs, just as they use different cookies and site data.
storage. Although browsers provide various defenses Using the TPM chip built in to many laptops for hard-
against rogue Java­Script stealing these cookies, they’re ware-protected cryptography is another appealing way
typically less protected than the private keys associated to protect these private keys and limit loss from malware
with SSL client certificates, or disk imaging. We hope
which can be stored in the our efforts will encourage
OS’s keychain or hardware vendors to
even under hardware ChannelID in Chrome browser version more widely include
protection, such as 24 is being deployed with no user-visible higher-­performance
a Trusted Platform TPMs that could
Module (TPM) or
effect. It’s just a silent hardening of the be employed for
smartcard. This leads platform, an unusually pleasant way this purpose. In the
to the idea of using to roll out new security features. meantime, we plan
client certificates to experiment with
and SSL session the smartcard-like
secrets instead of cookies. Although client certificates USB token as a semi-permanent secure element in com-
have been around since the early days of the Web, they puters. Such a USB token becomes a kind of “ignition
never became popular because the user interface for key” that locks a user’s computer as soon as it’s removed.
adding them was painful, often involving complicated
sequences of browser- and platform-specific popup Server-Side Technology
screens with no website customization. Using a single For server authentication by the client device, the
client certificate is a privacy mistake because it enables situation is better. Most browsers can verify SSL cer-
tracking; on the other hand, using multiple client cer- tificates properly, and sites can turn on features such
tificates and asking users to select one manually is a as HTTP Strict Transport Security to prevent down-
burdensome user experience. Given these disadvan- grade attacks. Although we must remain vigilant for
tages, the consequent widespread use of cookies, and SSL protocol and implementation mistakes—and
the amount of application software that would need to server key compromise—the largest observed risk of
be updated, the idea of switching to client certificates man-in-the-middle attacks on SSL is the compromise
seems infeasible. of root certificate authorities, such as Diginotar. Even
However, a new approach shows great promise— exotic attacks grow in importance over time, so we’ve
binding cookies cryptographically and automatically focused substantial effort on certificate transparency
to the SSL client. The first time a compliant browser and related ideas.
talks to a new domain, it automatically generates a key Certificate transparency ensures that server certifi-
pair, which is reused for future SSL connections to that cates are published in a few well-known locations, so a
domain. Cookies (or other bearer tokens) can be bound website operator can verify that it holds the only cer-
to that client key so that they’re usable only inside con- tificates that can authenticate as its servers. A browser
nections that the client initiates.9 that receives a server certificate gets cryptographic
We used a fast public-key cryptosystem, elliptic proof that it’s been published as well as supplemental
curve P256, and used the public key directly rather processes to catch unreliable publishers, attackers who
than a self-signed X.509 certificate. The computation compromise the central systems, or even a government
and network overhead was low, even with the new TCP coercing the central players. Because correct operation
connections. In a typical serving architecture, the SSL of the logs can be verified independently, this scheme
terminator on a front-end server passes the client public doesn’t introduce yet another trusted party.10
key (or its hash) to the back-end server. Back-end serv- Risk analysis is often left out of authentication dis-
ers can adopt channel bindings incrementally whenever cussions because it’s invisible to the user, but it’s an
they’re ready for the change. important part of the system. For average users with

20 IEEE Security & Privacy January/February 2013

Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 weak or reused passwords, this back-end risk-based smartcard with a private key that it uses on behalf of the
checking is particularly critical to reduce what would program. For instance, consider the case of applications
otherwise be widespread account hijacking. If 2sv and running on Google App Engine (GAE). There are three
other two-factor systems comprise “something you common design patterns:
know” and “something you have,” this might be called
“somewhere you are” and “some way you behave.” A ■■ GAE provides some built-in sensitive resources, such
geolocation pattern of login IP addresses that is violated as the Datastore. When an application gets a handle
suddenly should trigger extra concern. The server might for talking to the Datastore, it comes with implicit
post an alert, as Gmail’s Web interface does when detect- authentication. The application can be confident that
ing an unusual country of login. As with credit card risk any data it puts in the Datastore is accessible only to a
analysis, it must allow for people going on vacation. In future instance of itself and not to other apps.
more extreme risk signal cases, forcing users to answer ■■ GAE enables the app to reach other resources par-
additional questions to verify identity might be justi- ticipating in the OAuth authentication ecosystem
fied. Some of these risk signals are sophisticated, going we describe later. For example, the GAE app named
well beyond login geolocation to include users’ behav- [email protected] can acquire
ior after they’ve logged in. It can be difficult to design an OAuth token valid for one hour, scoped to the
these notification and challenge systems to work effec- Google Docs API.
tively without creating extra opportunities for phishing ■■ GAE participates in lower-level handshakes, allowing
attacks by mimicry. an app to talk to proprietary architectures. Assume
A server can adopt a federated login approach, effec- that an app has to authenticate itself to a particu-
tively letting one server pass the burden of validating lar bank’s gateway, which mediates access to various
user authentication to another server using browser other resources. The app can request GAE to sign a
redirection. This is especially appealing for small web- blob with the RSA private key that GAE manages for
sites, which can leverage large sites’ much richer set of it. The app uses that token to authenticate to the bank
authentication and risk analysis technologies to over- gateway, which replies with a bank-specific credential
come new users’ reluctance to create and manage yet that the app can use to access other resources directly.
another account. In this pattern, GAE automatically manages the app’s
public key, and the bank obtains it from a well-known
Service Accounts and Delegation discovery endpoint.
Trying to eliminate passwords in the real world revealed
two important aspects that are worth mentioning: Our final topic, delegation, often applies to these ser-
authentication by applications and account sharing. vice accounts but also meets real-world personal needs,
Programs like the Secure Shell (SSH) client or a as we learned when we began actively fighting password
Web browser executing RSA operations speak directly sharing in our organization. Generally, delegation refers
on behalf of a person. Other programs, such as print to an account owner granting a third party scoped access
servers, also need strong identity yet have existence to the account, possibly involving restrictions to certain
independent of any person. objects or actions. In the narrowest case, the delegated
Authenticating programs differs from authenti- scope might include only knowledge of the account’s
cating people in some important ways. For instance, email address, so delegation is one implementation of
there’s often no good place to store a credential. federated login.
Passwords certainly shouldn’t be hardwired into the The best delegation systems might be the ones
source code or in a command invocation line; most tightly integrated with an application. For example,
developers have learned to avoid these rookie security email account owner Alice designates deputy Bob
mistakes. But storing them in a configuration file is by explicitly authorizing the deputy’s account bob@­
problematic; how do we control access to the file from example.com to read Alice’s incoming messages and
an unauthenticated program? And if the program is to send messages with an authenticated address such
authenticated, why does it need to read a credential? as “From: Alice <[email protected]> (sent by bob@
Do we update the password every time developer team example.com).”
membership changes? Such integrated application behavior can provide
Cloud computing “service accounts” are a mod- productive sharing without granting full account access.
ern solution to this problem. We can rely on the cloud Alice might trust Bob to read and send email but not to
infrastructure to testify about a program’s identity to approve payments over some threshold.
other components or even outside systems. Think of Adding delegation features to each application inde-
the cloud infrastructure as holding the equivalent of a pendently would require a lot of implementation effort

www.computer.org/security 21
Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.
 View from the C-Suite

and likely lead to gratuitously different systems. Web 2. “Tennessee Man Convicted of Illegally Accessing Sarah
service providers searched for a substitute to the bad Palin’s E-mail Account and Obstruction of Justice,” Dept.
practice of users giving away their passwords to third Justice, 30 Apr. 2010; www.justice.gov/opa/pr/2010/
parties for scraping information like contacts, and came April/10-crm-509.html.
up with multiple independent protocols like Google’s 3. M. Honan, “How Apple and Amazon Security Flaws Led to
AuthSub, Yahoo’s BBAuth, and Facebook’s Login. The My Epic Hacking,” Wired, 6 Aug. 2012; www.wired.com/
industry has recently made great progress toward a uni- gadgetlab/2012/08/apple-amazon-mat-honan-hacking.
fied standard under the OAuth 2.0 umbrella. 4. K. Bhargavan and A. Delignat-Lavaud, “Web-Based
OAuth provides a way to grant scoped access to Attacks on Host-Proof Encrypted Storage,” Workshop
an account using a bearer token inside SSL, which the Offensive Technologies (WOOT 12), Usenix, 2012; http://
account owner can revoke on a per-delegation basis.11 moscova.inria.fr/~karthik/pubs/host_proof_woot12.
As a potential improvement, we envision that OAuth pdf.
bearer tokens could be channel-bound to an SSL ses- 5. F. Pesce, “Lessons Learned from Cracking 2 Million
sion that uses client authentication. LinkedIn Passwords,” Qualys Security Labs, 8 June
An aside on terminology: there is another authen- 2012; https://community.qualys.com/blogs/security
tication standard called OATH that has nothing to labs/2012/06/08/lessons-learned-from-cracking
do with OAuth. The Google Authenticator App for -2-million-linkedin-passwords.
Android, Blackberry, and iOS implements the HMAC- 6. K. Stevens and D. Jackson, “Zeus Banking Trojan Report,”
based OTP (HOTP) algorithm (RFC 4226) and the Dell SecureWorks, 11 Mar. 2010; www.secureworks.
Time-based OTP (TOTP) algorithm (RFC 6238), com/research/threats/zeus.
which are central to OATH. It’s easy to get confused by 7. “Ensuring Your Information Is Safe Online,” Google
the proliferation of labels. Official Blog, 1 June 2011; http://googleblog.blogspot.
The Google Cloud Print architecture provides a nice com/2011/06/ensuring-your-information-is-safe.html.
example of both service accounts and delegation. When 8. J. Fallows, “Gmail’s 2-Step Verifications: Some
printing a document, users share limited-time read FAQs,” The Atlantic, 9 Aug. 2012; www.theatlantic.
access to that one document with the service account com/technology/archive/2012/08/gmails-2-step
embedded in the cloud-ready printer. The service -verification-some-faqs/260934.
account identifies itself with an OAuth2 refresh token 9. M. Dietz et al., “Origin-Bound Certificates: A Fresh
obtained using a version of the OAuth2 device flow. Approach to Strong Client Authentication for the Web,”
Users don’t need to grant the printer any more access Usenix Security Symp., Usenix, 2012; https://www.usenix.
to their personal information than the contents of the org/conference/usenixsecurity12/origin-bound
document. Conversely, the printer (which might be in -certificates-fresh-approach-strong-client-authentication.
a public location) doesn’t give users direct connectivity 10. B. Laurie, A. Langley, and E. Kasper, “Certificate Trans-
or authority. parency,” Internet Engineering Task Force, 29 Nov. 2012;
http://tools.ietf.org/html/draft-laurie-pki-sunlight.
11. D. Hardt, “The OAuth 2.0 Authorization Framework,”

A long with many in the industry, we feel passwords

and simple bearer tokens, such as cookies, are no
longer sufficient to keep users safe. We’re investing in these
Internet Engineering Task Force, 31 July 2012; http://
tools.ietf.org/html/draft-ietf-oauth-v2.

client-side technologies and authentication methods Eric Grosse is vice president of security engineering
using one-time passwords and public-key-based technol- at Google. His research interests include all areas of
ogy to strengthen user and device authentication. practical computer and network security and privacy.
Grosse received a PhD in computer science from
Acknowledgments Stanford. He’s a member of ACM, IEEE, and SIAM.
We thank Ben Lauri, Brian Eaton, Diana Smetters, Dirk Bal- Contact him at [email protected].
fanz, Eric Sachs, Frank Cusack, Marc Donner, Marius Schilder,
Naveen Agarwal, Nishit Shah, Roberto Ortizr, Sam Srinivas, Mayank Upadhyay is principal engineer at Google. His
Úlfar Erlingsson, the rest of the 2sv team, and the anonymous research interests include many aspects of Web secu-
referees for helpful comments and material. rity, wireless network security, and usability. Upad-
hyay has an MS in computer science from Stanford.
References Contact him at [email protected].
1. J. Fallows, “Hacked!,” The Atlantic, Nov. 2011; www.
theatlantic.com/magazine/archive/2011/11/hacked/ Selected CS articles and columns are also available for free
308673. at http://ComputingNow.computer.org.

22 IEEE Security & Privacy January/February 2013

Authorized licensed use limited to: KTH Royal Institute of Technology. Downloaded on September 20,2022 at 04:38:05 UTC from IEEE Xplore. Restrictions apply.