6 ms·

Turning off less-secure app access to G Suite accounts

50 points by AndrewDucker 7y ago

hellcow 7y ago
This change will prevent us from using a large number of open source apps, effectively locking us into Google's own tools. My org will be eyeing alternatives when this rolls out.
- geofft 7y ago
  That's surprising, it's an open standard that plenty of open source apps do implement, isn't it? Is it just that the apps you're using happen to not have support for it? Which apps are you using that you wouldn't be able to use?
  - hellcow 7y ago
    One example, FairEmail on Android. It supports Google Oauth but ONLY if you use the Google Play version -- not F-Droid -- due to other "security" features from Google. Oauth may be an open standard, but it gives Google control over the clients you can use. If Google decides to one day ban your client of choice, you're SOL. Given their recent decision to ban specific browsers from accessing Google services, I'm not hopeful.
  - alexduggleby 7y ago
    I wonder though how many open source apps will go through the mandatory security audit process (15-75K annually) since IMAP via OAuth is a restricted API scope [1]. [1] https://support.google.com/cloud/answer/9110914?hl=en https://support.google.com/cloud/answer/9110914?hl=en
    - geofft 7y ago
      Ugh, I forgot about that. That said - from "What app types are not applicable for verification?" there are the following exceptions: > Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in. > Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications. > Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains. Also, in general, you don't want an OAuth client secret to be checked into a public repository anyway. So I think there's a straightforward approach: OSS developers/contributors using the app with their personal account use the "personal use" exception to create client secrets for just themselves, and companies deploying the apps (including companies employing people to work on the app) create a client secret for use only within that company and use the "internal use" or "domain-wide install" exceptions. If I were doing this for my own company, I would make a client secret for an app called "$company Internal OSS Apps," use config management to put a file in /etc with our client secret, make it world-readable to anyone who can log in, and tell employees that it's a violation of infosec policy to copy that secret onto non-corporate computers but they should feel free to use whatever OSS they like (that's otherwise compliant with whatever policies we might have) and configure it to read that file. So then there's just the question of actually making OAuth support exist in whatever apps employees want to use. EDIT: Also there's this exception which I think applies to the vast majority of OSS apps (things like mutt and Thunderbird and notmuch): > Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. If your app has server-side OAuth flow implemented, your app also needs to change to client-side OAuth flow. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).
- ASalazarMX 7y ago
  I've been using Thunderbird fine with App Specific Passwords. Despite the name, these are just revocable passwords. https://support.google.com/accounts/answer/185833?hl=en https://support.google.com/accounts/answer/185833?hl=en
  - JetSpiegel 7y ago
    That is what is being deprecated, no?
    - ASalazarMX 7y ago
      Didn't realize until your comment. Bummer.
- sebazzz 7y ago
  We have our helpdesk ticketing system linked through Google Mail. We have to find another solution.
icefog 7y ago
Does mutt support oauth yet? If not, this will be the last straw for G Suite from me. I can sort-of understand turning off "less secure" apps in consumer Gmail, but forcing "security" requirements for private, paid enterprise accounts is ludicrous. Time to find a provider which treats me as a grown-up capable of independent security risk judgement.
- Karunamon 7y ago
  Yes. This was my initial concern, but it looks like it's a simple process of running a script: https://luxing.im/mutt-integration-with-gmail-using-oauth/ https://luxing.im/mutt-integration-with-gmail-using-oauth/
- lukeify 7y ago
  Are there any decent alternatives to G Suite that support out of the box email hosting?
  - jiveturkey 7y ago
    plenty. https://lmgtfy.com/?q=email+hosting+providers https://lmgtfy.com/?q=email+hosting+providers fastmail.fm seems well regarded. (it's not on the first page of results above)
  - Disp4tch 7y ago
    For email you can import your gmail account via IMAP to fastmail. I have a custom domain so it's been awesome to finally serve mail from it and a relatively painless transition.
    - kelnos 7y ago
      The problem I've been having with this is that most of these alternative providers don't offer much space, even on their most expensive plan. My GMail storage use is around 300GB right now. Sure I could probably clean that up if I wanted to, but I don't. I'd rather just pay for 400GB of space, with options to go much higher as time goes on. Fastmail's most expensive plan offers 100GB, and most alternative providers seem to max out in this range (or lower). Mailbox.org is the only thing that I've found that is (or at least claims to be) privacy-respecting that offers lots of space. On a side note, given some of the anti-privacy and anti-encryption legislation passed in Australia in the last couple years, I'm not sure Fastmail would be my first choice to replace Google.
Karunamon 7y ago
This seems like a transparently disingenuous way to further platform lock-in using security as a pretext. I question the level of "security" this provides, especially given that there's little difference on the client side from using an app-specific password and using an OAuth2 bearer token, except the latter is more annoying to acquire and use. Either way, it's a small blob of text managed via Gsuite that the user has to have on their device and that an attacker could steal.
- jiveturkey 7y ago
  from the client side, yes. but from their side, ASPs are a codebase they apparently would like to free themselves from. it's understandable, given that most client apps by far (by %use) support oauth. oauth2 is definitely more annoying for a client to implement, much more annoying. but it's much easier for a user than ASPs.
  - deleted 7y ago
    [deleted]
- zozbot234 7y ago
  The blogpost mentions that an attacker could use a normal username and password to access your account via some app that they control, and this is a channel they're trying to get rid of. Even if all that OAuth does is meaningfully enforce the "app-specific" part (including providing the user with a workflow to authorize app access or reject it) this is a meaningful improvement in security.
- knorker 7y ago
  Except app-specific passwords are not app-specific at all. You maybe have a calendar app, but then someone steals that and uses it to read email, and delete account recovery emails sent, owning you to hell and back. ASPs are a real problem and a liability. A read-only view into your calendar or email is not as much. I'm not saying you're wrong about what their motivation actually is (but you are just speculating), but you can't throw a rock without hitting a security expert who can easily argue why ASPs are a huge security liability.
souterrain 7y ago
Microsoft’s Office365 will make a similar change in October 2020. https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/ https://developer.microsoft.com/en-us/office/blogs/end-of-su...
awake 7y ago
If you want to add an email alias to GMAIL the merge step requires less secure access. I was unable to merge two gmail accounts last week because google kept blocking me thinking my account was getting hacked.
slim 7y ago
yandex has free mail with free custom domain hosting https://connect.yandex.com/pdd/ https://connect.yandex.com/pdd/
- djhn 7y ago
  Any company based in Russia, China (or any other regime perceived as authoritarian and lacking in the rule of law department) is going to struggle to get on the short-list of "organizations to trust with the master keys to your whole online life".
  - slim 7y ago
    it depends on your threat model
mrsaint 7y ago
I wonder how to configure Postfix if I wanted to continue using it as a relay client to Gmail. Postfix doesn't support SASL XOAUTH2 yet does it?
dragonsh 7y ago
It’s better not to use such restrictive service which push you to the corner. Let the customer decide whether they want oauth or password authentication, but we are google why should we care for customer, you use us so you need to comply with our demands. My feeling is all this are ways to increase the revenue of google and they are just doing the same Microsoft and oracle was known for. This is called circle of life, it’s just instead of licenses they are locking users with API’s and proprietary development. Now in hindsight old Microsoft, oracle looked better compared to today’s google. In old days anyone can develop for win32 api and did not need Microsoft’s audit and charge for approval. Obviously today’s Microsoft is doing same as google so none is better. This whole thing is nothing to do with security but mostly a way to lock in users into gsuite, once you design your apps without login and password with oauth specific workflow and approval by google, it will be hard for anyone to justify a change.
newscracker 7y ago
This is going to be a bit cumbersome for those using Thunderbird or Mail.app (on Mac) or Outlook (Mac) over (plain) IMAP — the document instructs users to remove and re-add these accounts. That would mean (in my understanding, at least of Thunderbird) re-downloading all mails and folders once again into the newly setup account in the client. Those who use only a single device are probably going to have to schedule this appropriately to avoid having no visibility into mails for sometime.
dragonsh 7y ago
Google PR at work downvoting critical comments and post out of HN front page. Money can buy position like it can on google search.

50 points by AndrewDucker 7y ago

This change will prevent us from using a large number of open source apps, effectively locking us into Google's own tools. My org will be eyeing alternatives when this rolls out.

geofft 7y ago
That's surprising, it's an open standard that plenty of open source apps do implement, isn't it? Is it just that the apps you're using happen to not have support for it? Which apps are you using that you wouldn't be able to use?
- hellcow 7y ago
  One example, FairEmail on Android. It supports Google Oauth but ONLY if you use the Google Play version -- not F-Droid -- due to other "security" features from Google. Oauth may be an open standard, but it gives Google control over the clients you can use. If Google decides to one day ban your client of choice, you're SOL. Given their recent decision to ban specific browsers from accessing Google services, I'm not hopeful.
- alexduggleby 7y ago
  I wonder though how many open source apps will go through the mandatory security audit process (15-75K annually) since IMAP via OAuth is a restricted API scope [1]. [1] https://support.google.com/cloud/answer/9110914?hl=en https://support.google.com/cloud/answer/9110914?hl=en
  - geofft 7y ago
    Ugh, I forgot about that. That said - from "What app types are not applicable for verification?" there are the following exceptions: > Personal Use: The app is not shared with anyone else or will be used by fewer than 100 users. Hence, you can continue using the app by bypassing the unverified app warning during sign-in. > Internal Use: An app is internal when the people in your domains only use it internally. Learn more about public and internal applications. > Domain-Wide Install: If your app is intended for only G Suite enterprise users, access will depend on permission being granted by the domain administrator. G Suite domain administrators are the only ones that can whitelist the app for use within their domains. Also, in general, you don't want an OAuth client secret to be checked into a public repository anyway. So I think there's a straightforward approach: OSS developers/contributors using the app with their personal account use the "personal use" exception to create client secrets for just themselves, and companies deploying the apps (including companies employing people to work on the app) create a client secret for use only within that company and use the "internal use" or "domain-wide install" exceptions. If I were doing this for my own company, I would make a client secret for an app called "$company Internal OSS Apps," use config management to put a file in /etc with our client secret, make it world-readable to anyone who can log in, and tell employees that it's a violation of infosec policy to copy that secret onto non-corporate computers but they should feel free to use whatever OSS they like (that's otherwise compliant with whatever policies we might have) and configure it to read that file. So then there's just the question of actually making OAuth support exist in whatever apps employees want to use. EDIT: Also there's this exception which I think applies to the vast majority of OSS apps (things like mutt and Thunderbird and notmuch): > Local Data Storage: If you don’t want to go through a security assessment, you need to change your server storage to local storage only. If your app has server-side OAuth flow implemented, your app also needs to change to client-side OAuth flow. Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device (such as a computer, mobile phone, or tablet).
ASalazarMX 7y ago
I've been using Thunderbird fine with App Specific Passwords. Despite the name, these are just revocable passwords. https://support.google.com/accounts/answer/185833?hl=en https://support.google.com/accounts/answer/185833?hl=en
- JetSpiegel 7y ago
  That is what is being deprecated, no?
  - ASalazarMX 7y ago
    Didn't realize until your comment. Bummer.
sebazzz 7y ago
We have our helpdesk ticketing system linked through Google Mail. We have to find another solution.

icefog 7y ago

Does mutt support oauth yet? If not, this will be the last straw for G Suite from me. I can sort-of understand turning off "less secure" apps in consumer Gmail, but forcing "security" requirements for private, paid enterprise accounts is ludicrous. Time to find a provider which treats me as a grown-up capable of independent security risk judgement.

Karunamon 7y ago
Yes. This was my initial concern, but it looks like it's a simple process of running a script: https://luxing.im/mutt-integration-with-gmail-using-oauth/ https://luxing.im/mutt-integration-with-gmail-using-oauth/
lukeify 7y ago
Are there any decent alternatives to G Suite that support out of the box email hosting?
- jiveturkey 7y ago
  plenty. https://lmgtfy.com/?q=email+hosting+providers https://lmgtfy.com/?q=email+hosting+providers fastmail.fm seems well regarded. (it's not on the first page of results above)
- Disp4tch 7y ago
  For email you can import your gmail account via IMAP to fastmail. I have a custom domain so it's been awesome to finally serve mail from it and a relatively painless transition.
  - kelnos 7y ago
    The problem I've been having with this is that most of these alternative providers don't offer much space, even on their most expensive plan. My GMail storage use is around 300GB right now. Sure I could probably clean that up if I wanted to, but I don't. I'd rather just pay for 400GB of space, with options to go much higher as time goes on. Fastmail's most expensive plan offers 100GB, and most alternative providers seem to max out in this range (or lower). Mailbox.org is the only thing that I've found that is (or at least claims to be) privacy-respecting that offers lots of space. On a side note, given some of the anti-privacy and anti-encryption legislation passed in Australia in the last couple years, I'm not sure Fastmail would be my first choice to replace Google.

Karunamon 7y ago

This seems like a transparently disingenuous way to further platform lock-in using security as a pretext. I question the level of "security" this provides, especially given that there's little difference on the client side from using an app-specific password and using an OAuth2 bearer token, except the latter is more annoying to acquire and use. Either way, it's a small blob of text managed via Gsuite that the user has to have on their device and that an attacker could steal.

jiveturkey 7y ago
from the client side, yes. but from their side, ASPs are a codebase they apparently would like to free themselves from. it's understandable, given that most client apps by far (by %use) support oauth. oauth2 is definitely more annoying for a client to implement, much more annoying. but it's much easier for a user than ASPs.
- deleted 7y ago
  [deleted]
zozbot234 7y ago
The blogpost mentions that an attacker could use a normal username and password to access your account via some app that they control, and this is a channel they're trying to get rid of. Even if all that OAuth does is meaningfully enforce the "app-specific" part (including providing the user with a workflow to authorize app access or reject it) this is a meaningful improvement in security.
knorker 7y ago
Except app-specific passwords are not app-specific at all. You maybe have a calendar app, but then someone steals that and uses it to read email, and delete account recovery emails sent, owning you to hell and back. ASPs are a real problem and a liability. A read-only view into your calendar or email is not as much. I'm not saying you're wrong about what their motivation actually is (but you are just speculating), but you can't throw a rock without hitting a security expert who can easily argue why ASPs are a huge security liability.

souterrain 7y ago

Microsoft’s Office365 will make a similar change in October 2020. https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/ https://developer.microsoft.com/en-us/office/blogs/end-of-su...

awake 7y ago

If you want to add an email alias to GMAIL the merge step requires less secure access. I was unable to merge two gmail accounts last week because google kept blocking me thinking my account was getting hacked.

slim 7y ago

yandex has free mail with free custom domain hosting https://connect.yandex.com/pdd/ https://connect.yandex.com/pdd/

djhn 7y ago
Any company based in Russia, China (or any other regime perceived as authoritarian and lacking in the rule of law department) is going to struggle to get on the short-list of "organizations to trust with the master keys to your whole online life".
- slim 7y ago
  it depends on your threat model

mrsaint 7y ago

I wonder how to configure Postfix if I wanted to continue using it as a relay client to Gmail. Postfix doesn't support SASL XOAUTH2 yet does it?

dragonsh 7y ago

It’s better not to use such restrictive service which push you to the corner. Let the customer decide whether they want oauth or password authentication, but we are google why should we care for customer, you use us so you need to comply with our demands. My feeling is all this are ways to increase the revenue of google and they are just doing the same Microsoft and oracle was known for. This is called circle of life, it’s just instead of licenses they are locking users with API’s and proprietary development. Now in hindsight old Microsoft, oracle looked better compared to today’s google. In old days anyone can develop for win32 api and did not need Microsoft’s audit and charge for approval. Obviously today’s Microsoft is doing same as google so none is better. This whole thing is nothing to do with security but mostly a way to lock in users into gsuite, once you design your apps without login and password with oauth specific workflow and approval by google, it will be hard for anyone to justify a change.

newscracker 7y ago

This is going to be a bit cumbersome for those using Thunderbird or Mail.app (on Mac) or Outlook (Mac) over (plain) IMAP — the document instructs users to remove and re-add these accounts. That would mean (in my understanding, at least of Thunderbird) re-downloading all mails and folders once again into the newly setup account in the client. Those who use only a single device are probably going to have to schedule this appropriately to avoid having no visibility into mails for sometime.

dragonsh 7y ago

Google PR at work downvoting critical comments and post out of HN front page. Money can buy position like it can on google search.