Live data from Hacker News

Turning off less-secure app access to G Suite accounts

gsuiteupdates.googleblog.com

11–20 of 37 posts

Re: Turning off less-secure app access to G Suite accounts

#11
post #3

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.

eh? using your g suite password for email is a huge mistake. the problem isn't the password auth per se, it's that the permissions you grant if the password is exposed are vast, not limited to just sending/receiving email.

that said, why they insist on turning it off, rather than just use ASPs, is a bit unfriendly. but it's definitely not because they are treating you as a child.

Re: Turning off less-secure app access to G Suite accounts

#12
post #10
post #2

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.

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?

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.

Re: Turning off less-secure app access to G Suite accounts

#13

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 h…

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.

Re: Turning off less-secure app access to G Suite accounts

#14
post #9
post #7

Earlier quoted context omitted.

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

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.

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.

Re: Turning off less-secure app access to G Suite accounts

#15

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 h…

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.

Re: Turning off less-secure app access to G Suite accounts

#16

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 h…

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.

Re: Turning off less-secure app access to G Suite accounts

#17

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 h…

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]

Re: Turning off less-secure app access to G Suite accounts

#18
post #3

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.

I built a pine-like mail client that uses the GMail API: https://github.com/ThomasHabets/cmdg

I'm not saying it's perfect, but it's what I've used to read and write email every day for the last year or two, so it's past that point.

Patches welcome. :-)

Re: Turning off less-secure app access to G Suite accounts

#20
post #10
post #2

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.

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?

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

Post reply on HN