80

According to https://support.google.com/accounts/answer/6010255:

Google may block sign in attempts from some apps or devices that do not use modern security standards. Since these apps and devices are easier to break into, blocking them helps keep your account safer.

What are those "modern security standards" and why is it dangerous to allow apps which do not support them? Also, is it dangerous to enable the option (allow less secure apps) if you do not use those apps? If so, why?

I believe it might be OAuth2.0 over IMAP (according to this page). As far as I know, this is Google's own extension and is not used by any other service providers.

In my specific case I was trying to access my Gmail account using Kmail (v4.14.0) and IMAP.

Hjulle
  • 906
  • 1
  • 6
  • 10
  • 1
    There is some discussion (and links to more discussion) on http://forums.mozillazine.org/viewtopic.php?f=39&t=2852231. – Hjulle Aug 24 '14 at 02:31
  • Poor implementation of, say, encryption (whether in storage or while sending it to google) might lead to someone stealing your passwords. – KnightOfNi Aug 24 '14 at 02:31
  • Knowing how Google operates, they are probably detecting actual exploits, then blocking the apps that originated them. – Jeff-Inventor ChromeOS Aug 24 '14 at 02:35
  • 1
    Why would Google allow you to disable the protection against actual exploits? I'm pretty sure this is about OAuth2.0. – Hjulle Aug 24 '14 at 02:41
  • 3
    I'm sure they just want to make sure that only THEY get to violate your security. ;-) – user447607 Nov 27 '14 at 08:47

3 Answers3

52

In my understanding, "less secure apps" refers to applications that send your credentials directly to Gmail. Lots of things can go wrong when you give your credentials to third party to give to the authentication authority: the third party might keep the credentials in storage without telling you, they might use your credentials for purposes outside the stated scope of the application, they might send your credentials over a network without encryption, etc.

Additionally, it could be an app that a user has installed locally such as an IMAP client (see the following support note from google: https://support.google.com/accounts/answer/6010255?hl=en)

"Less secure" isn't meant to say that apps that use your credentials are necessarily full of security holes or run by criminals. Rather, it is the category of behavior -- giving your credentials to a third party -- that is fundamentally less secure than using an authorization mechanism like OAuth. With authorization, you never allow the third party to see your credentials, so an entire category of problems are instantly eliminated.

In OAuth, you authenticate directly to Gmail with your credentials and authorize an app to do certain things. The third-party app only sees an authorization token provided by Google as proof that you authenticated correctly and agreed to authorize that app.

As for why it would be dangerous to enable less secure apps (versus using a particular app that may be untrustworthy), I'm not totally sure. Google's refusal to authenticate happens after you've already given away your credentials to the application. It seems to me that any time you provide your credentials to a third party, it doesn't matter whether or not you've allowed authentication by "less secure apps" -- someone can just load up a log-in screen and directly log in as you. The only possible cases I can think of are:

  • Possibly "app-based" login attempts are treated differently from "human-based" login attempts, in particular how they treat sudden changes in location. Maybe the "less secure" app you're trying to use has servers on another continent, so it's not suspicious to Gmail when an app tries to log in as you somewhere else, while an attempt to use the log in screen from another continent by a human would be suspicious.

  • Possibly "less secure" auth methods include some other login method that doesn't directly reveal your credentials to the third-party but are less secure than OAuth 2.0 in some other way (e.g., they're vulnerable to eavesdropping by an attacker, or they make it somehow easier for an attacker to access your account without knowing your password).

Those two points are pure conjecture and very well may not be true in actual fact.

Bob Stein
  • 175
  • 1
  • 7
apsillers
  • 5,780
  • 27
  • 33
  • 13
    I see. All that stuff about untrusted apps is rather ingenuous. The OS and browser are still given full trust. When the browser is Firefox and the email client is Thunderbird, that's just silly. More generally, giving access to the email account allows taking control of the account, so there is no benefit in forcing email clients to use OAuth. This is looking more like a world-grabbing move hidden in a genuine but partially misapplied security concern. – Gilles 'SO- stop being evil' Nov 05 '14 at 18:14
  • 2
    In a word: BULLSHIT. ...and how the heck do they get off accusing others of not being modern when they don't even support gpg encryption?? ...or ANY encryption for that matter. – user447607 Nov 27 '14 at 08:48
  • Gilles, what you said is not true. Giving an app e-mail access allows it to read, send and modify e-mails, however it cannot change your password or make purchases on Google Play. The issue is not browsers or mail clients, but rather apps that run on third-party datacenters. Username/Password (only) based authentication does not allow for using browser information and challenging users who have suspicious activity, and thus enabling it is less secure. – epsalon Nov 24 '15 at 01:52
  • 6
    If you enable [2-step verification](https://www.google.com/landing/2step) you can then generate an [application-specific password](https://support.google.com/accounts/answer/185833?hl=en) that bypasses the *less secure* application check. With 2-step verification enabled, the option to allow *less secure apps* is not available. It is shame Google doesn't explain this solution on the *sign-in attempt prevented* email messages they send. It's intresting that a login using a so-called *application-specific password* is not considered *less-secure* despite still sending authentication credentials. – starfry Apr 14 '16 at 10:06
  • 3
    According to [Why doesn't outlook 2013 meet modern security standards?](http://security.stackexchange.com/q/111742/453), the details are that gmail only allows a "(non.standard) XOAUTH2 SASL mechanism (the correct tag is actually OAUTHBEARER)." It seems to be documented here: https://developers.google.com/gmail/xoauth2_protocol – nealmcb Oct 23 '16 at 23:36
5

I don't have enough reputation to comment, but I want to add my own experience on when I've "found" the issue...

I was setting up a new email client Airmail 2.0 to use Google's SMTP server to send mail on behalf on a Gmail account.

Now, my setup might not be too "common": I have this specific Gmail address forwarded to a different address, which is the one I'm using from Airmail, and I'm setting the gmail address as an "alias" of that account. Likely to avoid looking like Spam, Airmail allows to configure a specific SMTP server to use when sending "from" an alias.

I have another Gmail account set up on Airmail without any "funky" configuration or redirections, and that one is working fine (no messages about "reduced security", for example). So I copied the SMTP settings from the "normal" account to the new one:

These are the settings for the "classical" account:

Old Gmail Account SMTP Settings

And these are the ones for the "alias" SMTP server:

New Gmail Account SMTP Settings

Notice any differences? Me neither!!

I've been having a look around, and I've also found the page mentioned previously, Google's Security article New Security Measures Will Affect Older (non-OAuth 2.0) Applications where the change is announced - this paragraph (emphasis mine!) seems to imply that apps will need to be "authorised" to access to the account in similar way as many other "app clients" (Dropbox, etc) do:

That's why, beginning in the second half of 2014, we'll start gradually increasing the security checks performed when users log in to Google. These additional checks will ensure that only the intended user has access to their account, whether through a browser, device or application. These changes will affect any application that sends a username and/or password to Google.

I'm not against the idea, by itself, but I'd appreciate having more info what apps need to do to be considered safe so we can ask our app providers to implement the necessary changes...

More info on the topic here: GMail starts to block less secure apps: how to enable access again.

What is more puzzling is that my "other" Gmail account doesn't trigger this type of messages, as I don't have 2FA enabled so according to the previous article I should've got some of those errors!

UPDATED 2014-12-31, 17:52 GMT: Out of curiosity, I've checked the settings for my old Gmail account, and I've seen that it's actually set to "less security" (as Google calls it). I guess that when Google introduced the feature, the default for existing accounts that are being accessed by "less-secure" (as per Google terms) clients, is to allow them to keep on being accessed.

On the other hand, as some of the comments on the original Google Blog Post say, it's great that Google worries about our security, but the could have started by supporting things like CRAM-MD5 or DIGEST-MD5 for authentication instead of just plain LOGIN.

JJarava
  • 232
  • 1
  • 4
  • 9
0

People are using mobile apps that do not take proper actions to secure GMail users credentials. So Google is taking the only thing it can do: ending malicious hackers fun by forbidding apps from throwing users and passwords around and forcing the use of an authentication method that it trusts (their own!).

The problem with these apps is not one, but various: some do not use ssl/tls for data encryption, others allow hackers to intermediate the communication, etc.

By doing this, they allow attackers to capture the user GMail credentials, leading to accounts compromise.

So Google changed from an Authentication to an Authorization method, something that looks similar to what GitHub uses.

DarkLighting
  • 1,523
  • 11
  • 16
  • 2
    This answer doesn't make much sense. Apps that don't use TLS are easily blocked by disabling cleartext protocols. It isn't really possible to block specific clients since a client can easily impersonate another. Did you mean that Google blocks **protocols* *, which is indeed what seems to be happening? Authentication and authorization are different things, one doesn't replace the other. – Gilles 'SO- stop being evil' Nov 05 '14 at 18:06
  • That part of the answer is simply enumerating behaviors that go against "security standards", as an example of problems that happen when mobile apps try to communicate sensitive information. Google is not blocking *specific clients*. Google is blocking clients that do not use the method specified by the new API. I know that authentication and authorization are different things. And as you will see if you do some research, the new way talks about OAuth 2.0, which is not Authentication, but an Authorization method. Please, do not downvote if you did not understand the answer. – DarkLighting Nov 05 '14 at 19:07
  • If the app doesn't use oauth that doesn't mean it's "less secure". I would be more concerned about the privacy issue (i.e. logging in through the web interface). – Anthony Hunt Sep 29 '15 at 09:32
  • OAuth is just a solution to address the credential exposing issue. On top of it we still have to employ other mechanisms to ensure the security of the operation. Please, OAuth is NOT the ultimate answer to anything. What HE said about "less secure" (and i think that you should comment on HIS answer) is that using OAuth is more secure that allowing apps to use your own credential, not that OAuth is a must-have item. You are losing the reference. They made a comparison, not an absolute affirmation. – DarkLighting Sep 29 '15 at 15:13