Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers 4

up vote 16 down vote accepted

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.

share|improve this answer
    
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 7: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 3 at 8:04
1  
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 at 21:02
    
@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 at 15:56
add comment

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

share|improve this answer
    
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
add comment

The security flaw that you've pointed out is indeed true in my opinion. Having personally configured this to work for clients and well as on various applications on Windows and Linux systems, I can vouch for the fact that for applications such a IMAP, etc it DOES NOT ask for your original account password. Instead a application specific password is taken.

Now this "one time password" is not really used here, reason being IMAP clients don't store cookies, etc thus it's easier for them to validate the user based on this application specific password each time.

This application specific password is a 16 char length low case alphabetic passcode. Thus having 26^16 possible combinations (specifically 43608742899428874059776 possible combinations). Google does not allow you to bruteforce this. Trust me, I've tried, 3-4 attempts or so and you're out.

Problem:

The flaw that I do find with this is that the application specific password is not really application specific, as one generated for Google Chrome can access my email if used in Outlook. Software modifications in my opinion must be made to ensure that the code remains application specific or tied to a particular instance of the application.

Finally, to answer your question, well it depends. I personally find it more secure as:

  • 99% people do not know about this.
  • People majorly use passwords than are much less secure than a 16 bit lower case alphabetic string.

Keeping this is mind, it does protect you from web-based attacks and you can use Google APIs to generate app-specific passwords for one transaction and them expiry them after that. This was still in development last time I checked though.

Ultimately, it can't be bruteforced in a finite amount of time, but if someone gets their hands onto that, your account is as good as compromised. Then again, if someone gets your password, the same happens. Most clients do not store this application specific password in plain text.

share|improve this answer
    
Thanks for providing your take on this feature. They really ought to make these passwords app-specific on the server side, suspending the password if it is used in a suspicious manner. Secondly, even though Google will likely detect a bruteforce attempt, I still find it odd that they'd generate fixed length passwords consisting only of letters. –  Pieter Aug 12 '12 at 15:27
    
Quite true. But in my limited experience, they had a good intention. 2 Step Verification is a great free security feature, what they didn't plan for, is how applications would communicate if a user opted for it. However, I think reporting this issue to them will definitely get it fixed overtime. ;) –  Rohan Durve - Decode141 Aug 12 '12 at 15:29
    
"Most clients do not store this application specific password in plain text." what do you mean? –  curiousguy Aug 13 '12 at 2:27
    
The application specific password is utilized by software applications such as Outlook in order to access certain Google Services such as IMAP Email. Most of such application generally encrypt this application specific password, otherwise anyone with access to your system could just read this password from the program's files and use it however they like. It must be noted that programs at times follow weak security procedures. It is possible that offline bruteforcing of they encrypted version is done to get your plain text hash from the vuln. software. –  Rohan Durve - Decode141 Aug 13 '12 at 2:34
    
Offline bruteforcing would require physical access to the device. Without 2-factor auth you need to reset your password in this case. With 2-factor auth you can revoke the app-specific password and keep your current pass. –  Pieter Aug 13 '12 at 7:33
show 8 more comments

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.

share|improve this answer
    
Nah, you don't need to enter the original password. Putting up my answer shortly. –  Rohan Durve - Decode141 Aug 12 '12 at 15:07
4  
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. –  Terry Chia Aug 12 '12 at 15:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.