
Turning off less-secure app access to G Suite accounts - AndrewDucker
https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
======
Karunamon
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.

~~~
knorker
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.

~~~
icedchai
Perhaps they could support app specific passwords that behave similar to
bearer tokens, with a scope that limits API access, etc. Not saying this is a
good thing. OAuth is simple enough to set up.

------
souterrain
Microsoft’s Office365 will make a similar change in October 2020.

[https://developer.microsoft.com/en-us/office/blogs/end-of-
su...](https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-
basic-authentication-access-to-exchange-online-apis-for-office-365-customers/)

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

~~~
lukeify
Are there any decent alternatives to G Suite that support out of the box email
hosting?

~~~
Disp4tch
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
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.

~~~
nmjenkins
You can buy more storage at Fastmail: it's the same cost as an extra user to
add the same amount of storage. e.g. for a Professional account, you can add
an extra 100 GB storage for an extra $9/month.

Gmail reports a combined storage with Drive etc., so you may find not all of
your quota use is actually email.

------
hellcow
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
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?

~~~
alexduggleby
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
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)._

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

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

------
slim
yandex has free mail with free custom domain hosting

[https://connect.yandex.com/pdd/](https://connect.yandex.com/pdd/)

~~~
djhn
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
it depends on your threat model

------
mrsaint
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
Google PR at work downvoting critical comments and post out of HN front page.

Money can buy position like it can on google search.

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

