<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/28/2014 10:58 AM, Gervase Markham
wrote:<br>
</div>
<blockquote cite="mid:535E6CAE.6030205@mozilla.org" type="cite">
<pre wrap="">* What does Google hope to gain by making this change? Is it an
anti-spam/anti-fraud measure?</pre>
</blockquote>
<br>
My interpretation is that this is about user account security.<br>
<br>
I've got a long-form response here because these are relevant issues
to the Gaia email app that merit documentation, and I'm going to
scavenge from this message to provide the documentation / rationale.<br>
<br>
## 2 Factor Auth ##<br>
<br>
Google wants people to use 2-factor auth
(<a class="moz-txt-link-freetext" href="https://www.google.com/intl/en/landing/2step/">https://www.google.com/intl/en/landing/2step/</a>). IMAP/SMTP-based
clients need to continually establish new connections and perform
periodic synchronization without direct user interaction. This
requires some type of persistent credential. <br>
<br>
(Without a persistent credential the user would need to continually
enter a new password that is the concatenation of the user's actual
password plus a currently valid code received via SMS or a Google
Authenticator/TOTP[1] mechanism. I assert this is effectively
unworkable in the face of establishing new connections. It also
leaks the user's password, thereby reducing overall security.)<br>
<br>
Use of single-factor authentication (just a password) that is used
by both the user and all their applications is <br>
<br>
OAuth2 is one of two ways Google currently uses to provide a
persistent credential to applications. The other is "application
specific passwords"
(<a class="moz-txt-link-freetext" href="https://support.google.com/mail/answer/1173270?hl=en">https://support.google.com/mail/answer/1173270?hl=en</a>):<br>
<br>
<br>
### OAuth2 / Account Permissions ###<br>
<br>
OAuth2 can be used without enabling 2-factor authentication on an
account. It provides a persistent, revocable credential that is
explicitly scoped/controlled access to subsets of the user's Google
Account. The requested access is described by Google to the user at
the time of the request but it's a yes/no situation; the user can't
authorize a subset of access to the account.<br>
<br>
In my quick test just now, the explanations were presented as high
level descriptions of the requested capabilities accompanied by
little "i" icons to the right that pop-up more detailed descriptions
when you click on them. When authorizing the currently Google
Chrome-based whiteout.io app, the Google-hosted dialog I got listed
the following requests with the given elaborations.<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<br>
* View and manage your mail<br>
** View, manage, and permanently delete your mail in Gmail<br>
** Create, update, and delete labels<br>
** Compose and send new email<br>
*
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Know who you are on Google<br>
** This app is requesting permission to associate you with your
public Google profile.<br>
* View your email address<br>
** View the email address associated with your account<br>
<br>
Note that since I was already authenticated to Google so I did not
need to enter any credentials. And to reiterate, the page was
served by Google in Google's origin with frame-busting, although
they clearly support a mechanism for plugging in branding in a few
spots.<br>
<br>
A user interface to list existing authorized applications, their
authorizations is accessible from the user's Google account's
"Security" tab/page from the "Account Permissions" portion of the
page. That portion links to documentation at this page:
<a class="moz-txt-link-freetext" href="https://support.google.com/accounts/answer/3466521">https://support.google.com/accounts/answer/3466521</a>.<br>
<br>
The page list capabilities grouped by Google product and reuses the
top-level descriptions from before, but does not provide access to
the tool-tips. So the breakdown for whiteout.io is:<br>
<br>
* Gmail<br>
** View and manage your mail<br>
* Basic account info<br>
** View your email address<br>
** Know who you are on Google<br>
<br>
A revoke button is provided and the date of the original
authorization. No additional data/metadata is currently surfaced in
the UI.<br>
<br>
<br>
### Application-Specific Passwords ###<br>
<br>
These are unscoped credentials that require that 2-step verification
be enabled. The user manually creates an application-specific
password from their Google account's "Security" tab/page in the
"Password" section under "App passwords". The docs at
<a class="moz-txt-link-freetext" href="https://support.google.com/mail/answer/1173270?hl=en">https://support.google.com/mail/answer/1173270?hl=en</a> do a great job
of illustrating how it works, so I'll skip doing that.<br>
<br>
These accomplish much of what the OAuth2 provided credentials
provide, and it is my understanding that :BenB is okay with these
and thinks they may be an acceptable workaround. Their deficiencies
are that they:<br>
<br>
* Are unscoped, which means that even though you may have created
the password for Thunderbird to access your email, if compromised it
could potentially be used to download all of your pictures that you
uploaded via Picasa.<br>
<br>
It's not immediately clear how Google handles these on the
back-end. They could be clever and realize you only ever use them
for email and then auto-scope them under the hood, or not. They
could restrict them to API endpoints, or maybe if you type one into
any interactive login prompt as your password it bypasses all
2-factor checks.<br>
<br>
The biggest concern is that older versions of Android used
application-specific passwords and on an Android tablet I upgraded
Android was able to turn the application-specific password into a
"Full account access" "Account Permission(s)". It is possible there
were additional safe-guards in place like the device providing a
sort-of secondary factor to prove it was the device on file.<br>
<br>
I should point out that Google does have it in their power to make
these credentials scoped. But then there's a new set of problems
where the user doesn't set the right permissions for the app / the
required permissions change / the user blindly pastes in some opaque
set of permissions / etc.<br>
<br>
* Bad UX, significantly worse on mobile than on desktop, though it
varies on the mobile platform. Basically intractable on Firefox OS
because of our lack of copy and paste.<br>
<br>
* Makes it harder for Google to react to zero-days on software / web
sites. One upside to OAuth2 is that since the application is
required to claim to be a specific piece of software/website, Google
has the ability to disable credentials on a per-application basis
quickly across all their users.<br>
<br>
For example, let's say it turns out that there's a buffer overflow
attack on Thunderbird that allows an attacker to steal your
credentials. Google could invalidate all of the Thunderbird tokens
as soon as they find out and refuse to mint any new tokens for
software that claims to be that version of Thunderbird. Thunderbird
registers for a new secret and pushes out a security update with a
fixed Thunderbird and that uses the new credential<br>
<br>
Note that there are also downsides to requiring applications to
register to get the not-really-secret secret key. It does not scale
unless there's an effort to create a community registry of
applications that other OAuth2 providers can pull from.<br>
<br>
One could also make the argument that it makes it easy for Google
to deny access to Thunderbird. But practically speaking, there's
nothing stopping Thunderbird (or any client) from lying about what
client it is. And also it's fairly easy for Google to fingerprint
Thunderbird's IMAP/SMTP behavior if they wanted to systematically
prevent Thunderbird from accessing their system.<br>
<br>
<br>
<blockquote cite="mid:535E6CAE.6030205@mozilla.org" type="cite">
<pre wrap="">* Can the additional data about logins that Google hopes to obtain be
obtained in other ways for IMAP?</pre>
</blockquote>
<br>
I'm not sure exactly what piece of information is being asked about
here. I think there are two possibilities:<br>
<br>
* Google wants your phone number. I just went to create an account
from scratch, and while the form asks for a mobile phone number, the
documentation linked to from the page at
<a class="moz-txt-link-freetext" href="https://support.google.com/accounts/answer/1733224?hl=en">https://support.google.com/accounts/answer/1733224?hl=en</a> says it's
optional.<br>
<br>
I think Google's rationale here is sound, but I do agree with Ben
that Google may potentially do other things with that information
that are not as much in the user's interest.<br>
<br>
<br>
* Google's documentation explicit provides other mechanisms that
don't require the mail client to also be a web browser / have a web
browser. See
<a class="moz-txt-link-freetext" href="https://developers.google.com/accounts/docs/OAuth2#device">https://developers.google.com/accounts/docs/OAuth2#device</a> and the
greater details at
<a class="moz-txt-link-freetext" href="https://developers.google.com/accounts/docs/OAuth2ForDevices">https://developers.google.com/accounts/docs/OAuth2ForDevices</a>.
However this is still OAuth2 and possibly even a somewhat
Google-specific. Given that Thunderbird is unlikely to already have
google.com credentials embedded inside it via cookie, triggers a
different web browser for general web browsing, and the mechanism
does now allow data to be passed back, this might be the ideal
solution for Thunderbird.<br>
<br>
<br>
In a broader contest responding to :BenB's answer here, I'll quote
myself from <a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=849540#c20">https://bugzilla.mozilla.org/show_bug.cgi?id=849540#c20</a>
(and omit a distracting point I retracted in a subsequent comment):<br>
<br>
In terms of error messages, gmail actually already does this. They
provide a structured specific error code that software can identify,
plus they include human-readable text and a link to a support
document. Frequently not the world's best support document, but a
good starting point.<br>
<br>
A big problem with these error messages is that most servers provide
useless, unlocalized, confusing error messages so email clients have
an incentive to not show the error message directly to the user.<br>
<br>
<br>
<blockquote cite="mid:535E6CAE.6030205@mozilla.org" type="cite">
<pre wrap="">* Why can't single-service passwords continue to be used instead?</pre>
</blockquote>
<br>
It's not clear that they are eliminating application-specific
passwords. It'd be great if someone could find this out exactly.
It would not surprise me if they phased them out in the future or
began to more aggressively limit what they could access.<br>
<br>
<br>
<blockquote cite="mid:535E6CAE.6030205@mozilla.org" type="cite">
<pre wrap="">* Do they understand the ramifications of the idea that clients of all
these protocols will need to contain a browser? (Is that actually so?)
</pre>
</blockquote>
<br>
<a class="moz-txt-link-freetext" href="https://developers.google.com/accounts/docs/OAuth2#device">https://developers.google.com/accounts/docs/OAuth2#device</a> as
mentioned above.<br>
<br>
<blockquote cite="mid:535E6CAE.6030205@mozilla.org" type="cite">
<pre wrap="">* Are there any ramifications on open source software in particular?
(Seems from the discussion that the answer is actually no, but we need
to be sure.)</pre>
</blockquote>
<br>
No. From a message I sent earlier in the thread:<br>
<br>
From <a class="moz-txt-link-freetext"
href="https://developers.google.com/accounts/docs/OAuth2#installed">https://developers.google.com/accounts/docs/OAuth2#installed</a>:
<br>
"The process results in a client ID and, in some cases, a client
secret, which you embed in the source code of your application. (In
this context, the client secret is obviously not treated as a
secret.) "
<br>
<br>
<blockquote cite="mid:535E6CAE.6030205@mozilla.org" type="cite">
<pre wrap="">* Who are the other desktop email software providers, and what are their
opinions?
</pre>
</blockquote>
<br>
* The Firefox OS Gaia email app will be implementing this.<br>
<br>
* The whiteout.io client (<a class="moz-txt-link-freetext" href="https://whiteout.io/">https://whiteout.io/</a>) already does this,
as alluded to above. While under development, they are notable in
that you create or import a PGP key as part of the account setup
process and the app will try and upsell your unencrypted recipients
to adopt PGP. The app is in an early stage and is currently
GMail-specific and operates as a Chrome app and unfortunately
although you can install the app via the inline install mechanism
(versus the chrome app store which does require the browser to be
bound to your Google account), actual account setup does require
binding to your Google account. Hopefully they change that in the
future, but you can at least tell Chrome not to sync stuff with the
server and to wrap it with an additional pass-phrase that is not
your Google credentials.<br>
<br>
Andrew<br>
<br>
1:
<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm</a><br>
</body>
</html>