What are the dangers of allowing "less secure apps" to access my Google account?

  • 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.

    There is some discussion (and links to more discussion) on http://forums.mozillazine.org/viewtopic.php?f=39&;t=2852231.

    Poor implementation of, say, encryption (whether in storage or while sending it to google) might lead to someone stealing your passwords.

    Knowing how Google operates, they are probably detecting actual exploits, then blocking the apps that originated them.

    Why would Google allow you to disable the protection against actual exploits? I'm pretty sure this is about OAuth2.0.

    I'm sure they just want to make sure that only THEY get to violate your security. ;-)

  • apsillers

    apsillers Correct answer

    7 years ago

    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.

    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.

    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.

    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.

    If you enable 2-step verification you can then generate an application-specific password 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.

    According to Why doesn't outlook 2013 meet modern security standards?, 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

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM