31

In the wake of the recent Mat Honan story I decided to try out two-factor authentication on my Google account. But in order to keep using it with Exchange, the Android OS, Google Talk and Google Chrome you have to create application-specific passwords.

Summary of the procedure

Application-specific passwords Application-specific passwords

Let me get a few things straight. Do I understand the security implications of application-specific passwords correctly?

  • Google does not automatically disable app-specific passwords when they are suddenly used out of their expected context (e.g. to access e-mail even though it was set up for Chrome sync).
  • I have to generate additional passwords that all give immediate access to my account, bypassing two-factor authentication entirely. The higher the number of application-specific passwords the higher the chances are of a brute force attack succeeding.
  • These passwords have a fixed length and don't contain numbers or symbols, which make them more susceptible to brute force attacks than a password with unknown length containing letters, numbers and symbols.

Assuming that I want to keep using features like IMAP access (which would force me to make at least one app-specific password), would I be better or worse off using two-factor authentication?

curiousguy
  • 5,038
  • 3
  • 25
  • 27
Pieter
  • 1,295
  • 4
  • 13
  • 18

3 Answers3

23

You wrote (emphasis mine):

The higher the number of application-specific passwords the higher the chances are of a brute force attack succeeding.

These passwords have a fixed length and don't contain numbers or symbols, which make them more susceptible to brute force attacks than a password with unknown length containing letters, numbers and symbols.

Short answer: Not in any practical way.

Long answer:

Do the math: 16 lower case letters allows 26^16 different passwords, that is more than 10^22 = 10 × 1000^7 = ten sextillion possible passwords.

If the password is chosen randomly with equal probabilities (we have no reason to believe it is not the case), the odds of breaking the password by brute force are negligible, even if Google does not notice the attack and does not take any counter measure.

Even with 100 application specific passwords for one Google account, there is no way anyone would try this attack. The "susceptibility" to brute force attacks is zero.

And it is much easier on many smart phones to type a password made of only lower case letter than a combination of letters and digit or mixed-case letters (for the same number of possible passwords).

You also wrote:

Google does not automatically disable app-specific passwords when they are suddenly used out of their expected context (e.g. to access e-mail even though it was set up for Chrome sync).

That is the only real security issue here.

Community
  • 1
curiousguy
  • 5,038
  • 3
  • 25
  • 27
  • So if Google set up suspicious activity detection and/or allowed me to configure the permissions (e.g. Gmail, Google Contacts, Google Calendar, etc.) for each app-specific password, the only issue with this system would be fixed? – Pieter Aug 13 '12 at 07:44
  • @Pieter I think so. And a brute-force attack, if not stopped, would be probably be enough to DOS Google (at least the computers responsible for the authentication) before the probability of success against a single account is significant. Of course, Google would react to such attack. – curiousguy Aug 13 '12 at 18:11
  • 1
    By comparison, 16-character lowercase is roughly equivalent to 12.5-character of alphanumeric, or 11.5-character alphanumeric plus symbols, or 75 bits binary, and would take about 350 thousand years at 4 billion guesses per second – tylerl Mar 03 '14 at 08:04
  • 3
    My problem is that this proves 2-step verification is safe, even with 100 application specific passwords BUT one could just as easily use a strong normal password (without 2-step verification) so in this sense isn't 2-step verification a waste of time and resources? – Celeritas Apr 29 '14 at 21:02
  • 4
    @Celeritas app-specific passwords are harder to phish, as the user will never manually enter them, they will simply be stored and used by their app. If they are somehow compromised, then generally you can revoke that password using your master credentials, slightly mitigating the damage. – MikeFHay Jul 16 '14 at 15:56
  • 1
    It seems that they are not random characters but that they are some kind of encoding of underlying values. That could explain the uneven distribution. https://gist.github.com/jonelf/4a5d9415776e823b50ac If so, this significantly lowers the entropy. – Jonas Elfström Sep 04 '14 at 09:00
  • This doesn't change the practical implications, but shouldn't the calculation be `26^16 / 2`, since you only have to search half of the space on average before finding a hit? – Ian Dunn Oct 03 '22 at 22:44
  • ...that also doesn't account for the # of application passwords. If you have to create 3 of them, then the search space is divided even further. – Ian Dunn Oct 03 '22 at 22:54
20

You can NOT sign in to your account with an application specific password

Application-specific passwords cannot change security settings, only access email and chat. So you can have you privacy compromised, but your account cannot be hijacked.

Here is what happens when you try and login to change your account settings using an application specific password:

google login

Community
  • 1
Airton Granero
  • 201
  • 2
  • 2
  • Could you back this up with some references? That's not how I thought this worked. – Pieter Oct 16 '12 at 10:37
  • App-specific password doesn't work there because 2-step works there. App-specific is only intended for interfaces where 2-step is not supported. – trusktr Dec 16 '13 at 20:53
  • 1
    @Airton, Re "..only access email and chat.."; wth is "chat"? and **what about Google Docs data**? – Pacerier Jan 26 '18 at 06:30
  • Even if an attacker can "only access email", that still lets them reset the passwords for any external account that was setup using the compromised address (unless 2FA was used on the external account too). – Ian Dunn Oct 03 '22 at 22:42
2

First of all, two factor authentication clearly protects your primary email account from malicious attacks. Attackers cannot directly gain access to your email account without access to your phone.

This is better than not enabling two factor authentication as there is an added layer of protection.

What the app-specific password does is provide a clear separation from your email account. It gives a way for applications to access the information from your account without having to divulge the password of your email.

As you can see from your pictures, you can monitor the activity of the app-specific password. If anything is out of the ordinary, you can revoke access of the password.

It might is possible to bruteforce the password, but it has less impact than bruteforcing your main account password. Damage control is easier to implement as you can revoke passwords when needed.

Enabling two-factor authentication by Google has no downsides, except for the slight inconvenience of having to reach for your phone or generating a new app-specific password when you need it.

  • Nah, you don't need to enter the original password. Putting up my answer shortly. – Rohan Durve Aug 12 '12 at 15:07
  • 5
    *In addition, the passwords are one time use.* I don't think so. AFAIK, if you set up IMAP in Thunderbird, you have to enter app-specific password as the account password. That password is sent to the server every time Thunderbird checks your e-mail, so that wouldn't make it a one-time password. – Pieter Aug 12 '12 at 15:08
  • yeah, i just did a quick google search. editing my answer now. –  Aug 12 '12 at 15:08