Monday, September 29, 2014

Google "Less Secure Apps" Explained

Google has a security setting in your account for enabling or disabling "Less Secure Apps".  What is a "Less Secure App" exactly doing or not doing to make it less secure?  Google's answer is relatively vague, and mentions "modern security standards".  You can read Google's description here.

Less Secure Apps:

Google considers apps that directly use your account email address and password less secure.  Many older apps request your login details in order to access Google's services on your behalf.  This is not ideal from a security perspective for several reasons:

  1. You must trust that app to not be dishonest.
  2. You are also trusting these apps to adequately protect the password information from being compromised by 3rd parties. For example, storing the password un-encrypted in the registry or a file on your hard drive would leave it open to easily being compromised should someone or some malicious software gain access to your computer.
  3. Finally, you are also giving that app access to all of your Google account's features, including e-mail, contacts, calendar, drive, etc.  If that app only needs to access your contacts, giving it permission to access all your other services opens up permissions more than necessary.
There is a better method for authentication available...

More Secure Apps:

Google supports an improved method to give apps access to your Google services with a protocol called OAuth2.  Using this authentication method allows apps to access only the Google services within your account that they need.  OAuth2 also eliminates the need for the user to provide the app with an account password.  Instead you get an access code, specific to that app, your account, and needed permissions. The details of how you obtain this access code vary depending on the platform of the app.  The basic idea is that the app directs you to a Google website where you log into your Google account and view the permission request from this app.  The permission request lists all the specific services this app will be able to access.  If you approve, you will be given an access code to enter into the app.  (Some apps can accept this access code automatically, behind the scenes, once you approve the request.)

OAuth2 eliminates the need for users to enter their Google account password.  It also solves the issue of only providing permissions to the necessary services, instead of your whole account.  Also, the access code can only be used by the requesting app.  To use the access code the app must also provide a clientID and client secret, which are registered with Google by the app developer.  Therefore, even if the access code were compromised the malicious party couldn't use it unless it knew the clientID and client secret.  If the malicious party had the access code, clientID, and client secret it could use this, but then it would at least be restricted to the services approved.  Access codes can also be easily revoked when desired.


  1. How do you reconcile "OAuth2 eliminates the need for users to enter their Google account password" with "the app directs you to a Google website where you log into your Google account"? How do you log into your Google account without entering your Google account password?

  2. I should have been more clear and said "OAuth2 eliminates the need for users to enter their Google account password into the app". You do still need to enter your password to sign into Google directly and get the app an access code.

  3. And, aside from the Kool-Aid, what exactly prevents a Token from being sent from any number of different computers? Remember, these are locally calculated which means that any data used to generate the client side certificate that unlocks the token can be sent as well.

    What prevents a tainted mail application from using your "Token" and sending your mail to a private server. The token ONLY acts as a safeguard to losing an insecure password; it doesn't keep the application safe and access to mail provides access to every password.

    What prevents the average user from getting tired of security alerts and giving the application unlimited permissions, after which the developer puts a malicious update out having the app auto-update and do evil?

    Or heck, if the app is given permissions to change your password, why can't it just change it instead of steal it?

    The only thing you're really doing is protecting a horribly insecure password. Something like Rudolf962# that is used in multiple "high risk" sites (websites with your credit information). All of the bad that being hacked yields hasn't been prevented in the slightest.

    (Of course, this does make it easier for Google to start targeting third party apps and revoke their tokens. "Sorry, your mailclient does not have a Google logo and is insecure".)

    1. Just to note: Yes, the only advantage to this is revoking tokens of "known malicious clients."

      But given how easy it is to get Google to go on security lockdown when using a non-standard (or just non-Google) client, you have serious risks to neutrality.

      What defines malicious? Remember, this is a company that has been repeatedly accosted for its unethical behavior, especially with privacy laws. What defines malicious?

  4. Tokens allow access to be restricted to only certain features of your account. For example, maybe you can only work with the calendar. You also cannot change an account password with a token, you need the original password.

  5. OK so Google considers Outlook 2010 (gmail imap authentication using account + password pair) a 'less secure app'.