15 ms·

Winding down Google Sync and Less Secure Apps support

428 points by sschueller 3y ago

taspeotis 3y ago
Oh no how will workplace printers scan to email now
- aiddun 3y ago
  You can still configure an app password
  - sschueller 3y ago
    Good luck with that. I couldn't get it to work and to switch to a mail account on another non Google host. Already before the LSA would disable and you would need to go into the settings to re-enable it all the time.
    - apimade 3y ago
      It’ll end up as a local POP or SMTP daemon which redirects email through an OAuth’d app. Everything old is new again, we’re running services locally just to make legacy work.
    - firecall 3y ago
      App Passwords have always worked fine for us, and have done for years!
- Symbiote 3y ago
  How do they do it now? The one at my work sends the PDF as an attachment, from its own email address.
- jabroni_salad 3y ago
  I use smtp2go for that, it's dead easy.
andris9 3y ago
The wording is kind of ambiguous, but it seems that App-Specific Passwords will continue working > If you have scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails, you’ll need to either: configure them to use OAuth, use an alternative method, or configure an App Password for use with the device. > All Other Applications. If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.
- yau8edq12i 3y ago
  The excerpt you quote doesn't sound ambiguous at all. App passwords will clearly still be supported.
  - khorne 3y ago
    The titles of both the HN post as well as the original blog post are ambiguous however.
  - notpushkin 3y ago
    Yeah. The HN submission title is incorrect though.
- mugs 3y ago
  It wasn't 100% clear to me either. The wording clearly says SMTP will support app passwords, but no clear indication if IMAP will still support them. But I asked Google Workspace Support specifically about this yesterday, and they said: > The application passwords will support IMAP, POP, and all SMTP configurations. Rest assured that OAuth serves as an alternative, offering a straightforward configuration process for any third-party application. The second sentence was just them continually pushing adopting OAuth. I'd love to, but the cost of the (recurring) security review is not feasible for our small SaaS app, so we'll be sticking with app passwords (thankfully).
charcircuit 3y ago
People giving away their google account password to other apps / companies is bad for security. I'm surprised this still existed. I think this hasn't worked for accounts that have had 2FA for quite some time. I remember having to switch several years ago.
- sschueller 3y ago
  I gave Google my IMAP account from another Google account in order not to have to check two accounts and have the mail forwarded...
- unethical_ban 3y ago
  Any decision that limits my ability to use third-party apps, accepting, etc. is a compromise not worth making. It sounds like there is a feature for generating additional passwords for specific apps/scopes? Anyway. Forced 2fa without warning has locked me out of several Gmail accounts. I didn't know when migrating took Proton that you must use their client for mobile. All these violations of abstraction!
- ahoka 3y ago
  Yep, this is the reason OAuth2 exists.
- blagie 3y ago
  It's not always bad security. a) I have apps with their own Google accounts b) I have devices with their own Google accounts It is (or was) a good way to go. Receiving an email from a scanner or sharing something with an app on Google Drive is a lot more secure than OAuth + "This app will have access to EVERYTHING IN YOUR GOOGLE DRIVE"
  - jbverschoor 3y ago
    At a certain point, you'll have apps and devices that have (or have no) permission to use someone else's account that was previously under your control. > "This app will have access to EVERYTHING IN YOUR GOOGLE DRIVE" Then don't use such app
jsnell 3y ago
This is just about Workspace accounts, the change already happened to normal Gmail accounts years ago.
- deleted 3y ago
  [deleted]
- SirMaster 3y ago
  Not entirely true. I still access my personal Gmail account via the Microsoft Exchange option in my iPhone's Mail.app and I get push notifications this way rather than being stuck with Fetch. The reason it still works is that connections made to Google Sync for personal accounts prior to the discontinuation date like 10 years ago are still honored and "grandfathered" if you will. So to get it to work I just need to modify the Exchange GUID in my iPhone to what the GUID was on my phone back when I logged into Google Sync before they discontinued new logins. Fortunately changing this GUID is possible by taking an iPhone backup, modifying a plist file in the backup, and restoring that backup to the phone. So right now, on my iPhone 14 Pro, I am still using Mail.app with push notifications to my personal Gmail account.
interroboink 3y ago
My heart skipped a beat when I read this — I have various scripts and things that interact with Gmail. But it's okay. App passwords will still work, it seems. This is just removal of "Less Secure Apps" support, using the account's plain account user/password. I shudder to think how much automation would die if Google truly killed off everything but OAuth. I don't like the complexity OAuth. I enjoyed this Perl module documentation[1] that breaks down how the dang thing works, clearly written by someone as exasperated as me (: [1] https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Authen/OAuth2/Overview.pod https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
- leipert 3y ago
  Shouldn't be _too_ hard to convert your scripts. I ran into the same problem and one workspace disallows App passwords. You can simply get the OAuth token with a little python script and then use it as the password: https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py https://github.com/google/gmail-oauth2-tools/blob/master/pyt... (see for example https://github.com/lefcha/imapfilter/issues/186 https://github.com/lefcha/imapfilter/issues/186)
  - booi 3y ago
    and then have to reauthenticate it every 2 weeks because the refresh token seemingly expires for no reason...
    - justinc8687 3y ago
      If you set your app to "production", the refresh token works properly. Ignore the verification steps. It'll yell at you, but it'll work.
      - xmprt 3y ago
        How can you set an app to production without Google verification if you're not in a workspace. I'm guessing the answer is that there is no way.
ChrisArchitect 3y ago
Related: Changes to Gmail syncing with other email clients https://news.ycombinator.com/item?id=38975692 https://news.ycombinator.com/item?id=38975692
sir 3y ago
If you can’t switch to OAuth, you can use my proxy to allow any IMAP (or POP/SMTP) client to be used with a “modern” email provider, regardless of whether the client supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.
- mschuster91 3y ago
  Thank you for writing that, really helped me out back when Microsoft pushed OAuth for Office 365.
- nanna 3y ago
  Brilliant. So this is how you could keep a client like mu/mu4e functional for Gmail and outlook365.
  - yashasolutions 3y ago
    actually app password will keep working. Which is basically all you need for mu4e
- emersion 3y ago
  Unfortunately this requires users to setup their own OAuth client, which is a pretty manual/cumbersome process.
  - rollcat 3y ago
    Same if you're building any OAuth-enabled client from source. (Remind me, what's stopping me from extracting the client secrets from the compiled binary, and re-using them elsewhere?)
    - yrro 3y ago
      The provider might notice that their key is being used in an unauthorized way and terminate your account, prosecute you for computer fraud and abuse, etc.
deleted 3y ago
[deleted]
ChrisArchitect 3y ago
News from September (2023)
- sschueller 3y ago
  Email was sent out today to many Google Workspace admins with a link to this blog post.
kylehotchkiss 3y ago
This is all about getting users off of the fantastic native mail apps and onto googles own. You can’t get realtime mail notifications without gmail.app or the soon to be deprecated Google sync. I hate it. I pay Google for workspace and I hate it. At least Mimestream still works on desktop but I bet they’re coming for that soon too.
- cbg0 3y ago
  Yes, it's pretty obvious this is what's going on. The solution to these "less secure apps" was to simply generate stronger passwords for them instead of making the user jump through hoops by using oauth2 proxies, especially for older hardware/software.
  - rezonant 3y ago
    Which is actually supported already with App specific Passwords...
- rezonant 3y ago
  App specific passwords will continue to work, and will work fine if your native app does not support the usual OAuth flow.
  - mcv 3y ago
    This is good to know, because I think I already use those everywhere (except on my latest machine; I should fix that). Even so, I will also be using this as a reminder to move my stuff away from Google.
  - eastern 3y ago
    "will continue" can't really be said about anything Google with any degree of confidence.
- esskay 3y ago
  Fully agree. Also paying for my gmail account and hate every moment of it but nobody seems to be able to get remotely close to gmail for spam handling.
tamrix 3y ago
[flagged]
magicalhippo 3y ago
Been dealing with Microsofts OAuth transition at work, and it's been a bit of a PITA. Part of the problem is that it's just so opaque. You send the token and the server replies "nope", with no further explanation. I spent literal days trying to figure out why Client Credentials-flow didn't work until I found an answer buried on their help forum saying oh yeah, client credentials flow isn't supported yet. It is now for IMAP/POP, but still not for SMTP IIRC (though OAuth is not requiredfor SMTP yet). Next it was figuring out the right scopes, which at the time was not very well documented. Again not very helpful error messages by the servers. Google's mail servers any better?
- xtajv 3y ago
  > Part of the problem is that it's just so opaque. You send the token and the server replies "nope", with no further explanation. Catch-all HTTP 401s and 403s are there to thwart https://en.wikipedia.org/wiki/Oracle_attack https://en.wikipedia.org/wiki/Oracle_attack - unfortunately, servers cannot afford to be "helpful" when it comes to unauthenticated clients.
  - mmbop 3y ago
    They should have a debug mode that is user-activated for stuff like this. I also have burned too many hours trying to get various OAuth flows working.
    - magicalhippo 3y ago
      Yeah some development servers that didn't actually send the mail anywhere but did give usable error messages for example would be amazing. To avoid it being used as an attack vector they could be tied to special app registrations that had to be registered with the mail development system in advance.
- datadrivenangel 3y ago
  Microsoft is amazingly good at those opaque error messages. Such a mess of UX
superkuh 3y ago
It's important to note here that OAuth isn't one thing anymore like it was for OAuth 1. With OAuth2 it's more like OAuth is a toolset for implementing your own proprietary protocol. Each major provider needs it's own custom implementation in email clients to cover it. There's no general purpose oauth2 in practice. OAuth2 is more like a per-corporation protocol. Lets hope they don't sunset "app passwords" for at least a few more years. If you haven't yet, consider setting up your own mailserver for kicks and using it for non-important things to build IP reputation for when public email stops being email entirely.
purpleidea 3y ago
I haven't been able to get `offlineimap` working with gmail in at least the last six months. If anyone has been successful, please let me know. The blog posts I've found all have out of date information. If I'm locked into their cloud, I'd at least like to have a backup of my data-- and no, I don't want the takeout service, the Maildir format and features of offlineimap are what work great!
- fifteen1506 3y ago
  App passwords worked for me like 3 or 4 months ago.
- terinjokes 3y ago
  I use mbsync/isync instead of offlineimap, but I've had no issues using mailctl to handle the OAuth2 tokens and refresh. Does the example on the ArchWiki[0] work for you? [0]: https://wiki.archlinux.org/title/OfflineIMAP#OAuth2_access_tokens_via_mailctl https://wiki.archlinux.org/title/OfflineIMAP#OAuth2_access_t...
miroljub 3y ago
And I migrated away all my accounts from Google in anticipation of it being more and more user hostile. Honestly, if I were still at Google, I would be outraged. In the name of false security, they make the wall around their garden taller and thicker every single day.
jonathanstrange 3y ago
I will do everything in my power to pressure my university to migrate their email accounts to another service. This is anti-competitive behavior designed to make it as hard as possible to use email client software. For example, check the procedures needed to set up oauth2 in my preferred client claws-mail.[1] That's insane. [1] https://www.claws-mail.org/faq/index.php/Oauth2 https://www.claws-mail.org/faq/index.php/Oauth2
- alisonsandy 3y ago
  > This is anti-competitive behavior designed to make it as hard as possible to use email client software Use App password. They are not blocking any 3rd party clients. Are you advocating using real password in every random client that may or may not transmit it in full text elsewhere? I do assume you know security essentials.
  - jonathanstrange 3y ago
    I will do that if our university decides to switch on 2-factor authentication (which would be total chaos), but my trust in Google's ability to make this effortless and easy in third-party email clients is zero. See my other post why. Regarding security: Google had physical fiber optics connections to the NSA and claimed they didn't know about them. It's not a very credible claim but if if was true, then it would be proof that Google has no competence in security at all.
    - alisonsandy 3y ago
      Any decent 3rd party client does this already. Take for example, thunderbird or k9-mail - major open source ones. Even Mail (from Apple, macOS) does this. What else you need? Sure if you use mutt or ALPINE read the related forums for help. while anyone can criticise any large company one should do it for the correct reasons.
      - jonathanstrange 3y ago
        Your frankly-speaking somewhat condescending reply fails to address the issue. This has nothing to do with the client software, which is claws-mail in this case. My organization does not enable 2-factor authentication. Once they do, claws-mail can be configured to use "App passwords." But if you look at my other post, quotes of Google's own documentation of "App passwords" and various testimony in this thread do not inspire much confidence that this will work as an acceptable long-term solution. As I said elsewhere, the rationale behind all of this seems to be anti-competitive behavior. It's not new idea to disguise anti-competitive behavior as security issues (cf. e.g. Apple's code signing and Gatekeeper). This also explains the misleading and incorrect term "Less Secure Apps" Google uses.
gramakri2 3y ago
I don't think the title is correct. IMAP/SMTP will still be supported with App Passwords. That's my reading of it.
nextgens 3y ago
It would be great if Google supported rfc8414 and rfc7591. Right now most MUAs hardcode credentials instead of auto-discovering/registering/configuring them and decline to implement those standards "because the big boys don't support them". The practical result is that one cannot use oauth2 on their domain easily: the MUA needs to be told about which set of oAuth2 creds to use. See https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm https://searchfox.org/comm-central/source/mailnews/base/src/... , https://github.com/thunderbird/autoconfig/tree/master/ispdb https://github.com/thunderbird/autoconfig/tree/master/ispdb and https://bugzilla.mozilla.org/show_bug.cgi?id=1602166 https://bugzilla.mozilla.org/show_bug.cgi?id=1602166
Perseids 3y ago
> An app password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App passwords can only be used with accounts that have 2-Step Verification turned on. [1] Isn't it funny, how the "less secure app or device" is completely on par with OAuth-capable apps regarding security just by using a server-side mechanism Google could have promoted since… forever? Almost as if it technically isn't a feature of the app at all. (Yeah, I get it, "apps where the secure workflow is less convenient" doesn't have the same ring to it, so the simplification is justifiable for easy communication – you will say. The greater problem is that it is kind of Google's thing to always interpret security concerns in such a way that it furthers Googles agenda and this puzzle piece is no exception.) [1] https://support.google.com/mail/answer/185833 https://support.google.com/mail/answer/185833
- happyopossum 3y ago
  > just by using a server-side mechanism Google could have promoted since… forever? Google has been pushing 2FA and App Specific Passwords for many many years. They’re just now making it mandatory for apps that can’t update to support oauth
- joshuamorton 3y ago
  > Isn't it funny, how the "less secure app or device" is completely on par with OAuth-capable apps regarding security just by using a server-side mechanism Google could have promoted since… forever? They aren't on part though, Oauth is vastly less phishable and has vastly more control over specific permissions. App passwords are functionally all-or-nothing, whereas with OAuth you can configure whether something can read, modify, change settings, etc.
dbrgn 3y ago
There is e-mail, and there is Gmail. (By the way, there are a lot of great e-mail providers other than Google. Often even with a web UI superior to the one by Gmail.)
- kiwijamo 3y ago
  Example: Fastmail.
lgrapenthin 3y ago
[flagged]
kuon 3y ago
I host my own email server, and I want to tell that with a static IP with reverse dns, spf, dkim and dmarc I had zero issue delivering mails. It might sound complicated, but it is not that hard.
- martin_a 3y ago
  True! Also you can pay 2 €/month to Hetzner/$webhosterofchoice and have them handle that for you... No need for Google after all is what I want to say.
emersion 3y ago
Note that Google has a very complicated process to migrate an IMAP/SMTP app to OAuth. There is a long list of requirements to register an OAuth client for these protocols: https://developers.google.com/terms/api-services-user-data-policy#additional_requirements_for_specific_api_scopes https://developers.google.com/terms/api-services-user-data-p...
forwardemail 3y ago
[flagged]
pdimitar 3y ago
I'm accessing my Google Drive through rclone, I should check if this affects it.
- RockRobotRock 3y ago
  It won't. rclone uses OAuth.
  - pdimitar 3y ago
    Oh, cool. Thank you.
mort96 3y ago
Flagged, because the title is both editorialized and factually wrong.
schappim 3y ago
@dang the title is misleading as the user can also "configure an App Password for use"
greatgib 3y ago
To be noted, the most annoying thing with Oauth2 and Google on Android is that you can't login with an email client or calendar with your Google account without your full phone to be associated with this Google account. Also giving policy right on your device by this Google account. That is totally insane in my opinion. And you can't easily bypass that as oauth2 usage in WebView inside apps are easily restricted by Google on Android.
- ysleepy 3y ago
  Can't alternative clients like k9 implement OAuth on their own? I believe I set up Thunderbird on my desktop with OAuth and it works (With office365). Sadly the number of email clients I would trust is limited, many send off your credentials to some remote server. EDIT: k9 already supports oauth for imap. https://docs.k9mail.app/en/6.400/accounts/incoming_imap/ https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
  - dmw_ng 3y ago
    The trouble with OAuth is to get a production client ID you must pass a third party security audit.. this is in excess of $20k and AIUI must be repeated periodically. Using a developer client ID is already heavily limited, and I have no doubt now that this ladder has been pulled up, developer IDs will see further restrictions in future. IMAP/POP passwords have long defaulted to disabled in Gmail, Gmail survived 20 years without need for these new restrictions, I can't imagine attack techniques have improved and Google's internal technical staff have regressed so substantially that they are now essential. This change seems more motivated by creating frictions for escaping the Google vortex than anything to do with security.
    - rrdharan 3y ago
      > I can't imagine attack techniques have improved and Google's internal technical staff have regressed so substantially I can definitely imagine, and I in fact believe, both of those things to be true.
  - greatgib 3y ago
d99kris 3y ago
I understand their announcement says app passwords will stay (for now). But should Google eventually also deprecate app passwords, it would really restrict the use of third-party clients with GMail, given the self-paid security assessment OAuth clients must undergo. It would be a sad development given that email is one of the last popular "open messaging protocols" in use, where one can choose what client to use.
- martin_a 3y ago
  Everybody is free to use something else besides GMail. Nobody forces anybody to use that.
  - leejoramo 3y ago
    But then there are there are large organizations who decide these things for many people.
deleted 3y ago
[deleted]
londons_explore 3y ago
It's because IMAP, SMTP and POP allow substantial access to your google account and life, yet none have the ability to do 2 factor. Nor do they allow any kind of anti-robot verification. That means it's super easy to do credential stuffing attacks, and at google-scale, that sort of attack is going to let an attacker ruin a lot of lives. This is a good thing, and they should have done it years ago (they kinda did by defaulting IMAP/POP/SMTP access to off - that protects most users - this is just for the rest)
- TacticalCoder 3y ago
  I take it if someone really still want to fetch all his emails the old way, he could configure GMail to forward every single email to another address (not a GMail one): one still allowing IMAP/POP. Not a panacea but it may be an acceptable workaround for some usecases.
  - londons_explore 3y ago
    You can still use app-specific passwords, so your 1992 mail client will still work... Although sending even an app-specific password in cleartext over the internet seems like a bad plan.
    - mcv 3y ago
      But why are those more secure than other passwords? How can they know that this 1992 app is the app it claims to be?
      - londons_explore 3y ago
        Because for the user account, people use things like "hunter2". But app specific passwords are long random strings unlikely to be reused by the user for another site.
        mcv 3y ago
dm319 3y ago
Is this going to be a problem for my mutt and mbsync setup?
londons_explore 3y ago
I wonder if this was triggered by the 23andMe breach? In that, it became pretty clear that the press and the public will blame a company if user accounts are breached even if the user had a weak/reused password. Since then, companies kinda have a responsibility to protect the users data despite the user doing stupid stuff.
- jsnell 3y ago
  No. This was originally announced in 2019 and has been proceeding in phases since then.
londons_explore 3y ago
This rollout plan seems misguided... You're going to remove the option from the admin console before sunsetting the feature? So users can't turn it off to test/see impact?
londons_explore 3y ago
You know what would be nice... Google going through their access logs and sending every admin an email list of usernames and services impacted by this change. Ie. The following users in your organisation are logging in with password-based "Less Secure authentication", and will need to migrate to another login method by 30th September: [list] Logins were to the following services: [list] For a full breakdown of which users logged in to which services insecurely on what date/time, reply to this email and we will auto-respond with complete logs. For help resolving this issue, see [our help article].
- sschueller 3y ago
  They did, I got an email, with an attachment spread sheet containing users email addresses on my domain. Bottom of email stated "A list of affected users is attached."
  - liveoneggs 3y ago
    me too? The file was named users.xls.exe and it just opened a weird black screen for a minute and closed. idk
- ourdomain-admin 3y ago
  I got an email listing my users, luckily only 4. What i'm trying to find now is how to run my own report so i can see when those users are 'fixed'. Anyone able to point me in the right direction? Thanks
  - londons_explore 3y ago
    you probably can't - the report is probably a massive mapreduce over all of googles access logs - the kind of thing they can do once, but they won't add a button to the dashboard for you to do yourself.
    - ourdomain-admin 3y ago
      Thanks. I've spent the morning looking and that would explain why I couldn't find it.
jcmontx 3y ago
What's the way to go with backends that send emails using gsuite's SMTP?
donatj 3y ago
Welp. Add Google Sync to the Google Graveyard
nunez 3y ago
They really buried the lede here. Google Sync is their implementation of Exchange ActiveSync. Google Sync (or IMAP) is the only way to send emails with aliases on iOS with Apple Mail. This is terrible.
_chu1 3y ago
Made the swtich to Tuta (previously Tutanota) about 2 years ago and never once looked back. I only wish they had support for some sort of protocol for third-party clients.
- joering2 3y ago
  That was a turn off for me personally. While I think more expensive per user (but free for up to 150 emails per day without your own domain name), ProtonMail has "Proton Bridge" that works wonderfully for me on Windows 7/11. It gives you what the name suggest, its a bridge between your cloud encrypted emails and sets up local SMTP that you can connect any program to (I have Thunderbird and Outlook). Haven't had any issues at all.
  - _chu1 3y ago
    Is Proton Bridge free now? I remember it being paid.
nurettin 3y ago
The problem with gmail's OAuth is the initial setup. After that is done, it works fine for years. First, you need to create an authorization token and a refresh token. If your authorization fails, you need to use your refresh token to get a new key. But the most damning part is: The initial process which gets you a refresh token requires you to login via browser. That's hard to deploy on a headless server. At some point I remember having to create a large enough swap space to run UI, install xorg, install google-chrome, go through the graphical process, then uninstall xorg and remove the unused swap.
bvrmn 3y ago
Does anybody know what makes refresh key is more secure than login/password? I'm quite dumb and don't understand how OAuth make apps more secure. Also maybe someone knows how to get read only token for IMAP access? Last time I've checked there were no any scopes. One literally could use same token to access and IMAP and SMTP. But IMAP/SMTP token split could really improve security.
- merb 3y ago
  because apps do not get credentials, so the token can be easily revoked just for this app. thats why app passwords are still fine.
  - bvrmn 3y ago
    Thank you, it makes a lot of sense.
ctime 3y ago
Google isn’t really worried about password entropy beyond a reasonable amount. The primary threat model is phishing. This is why multifactor is so important and once once you have that enabled, nobody gives a shit if you even rotate your password. Just needs to be long enough and not guessable because it’s not the sole means of authentication. Probably not a good idea to have something as critical as one’s primary email account identity tied to only a single factor of phishable credentials. Requiring App passwords seems better, but it bypasses requiring a MF. oAuth, while a a beast, seems even better as the workflow still initially requires a second factor.
SirMaster 3y ago
So if I am connecting to my Gmail on my iPhone via the "Microsoft Exchange" option and using an app password I will still be OK? The reason I still connect via the "Microsoft Exchange" option instead of picking the "Google" option in Apple's Mail.app is because I get Push notification for my Gmail when using the "Microsoft Exchange" option compared to only having the Fetch option available for the "Google" option. After reading more carefully, I guess my method is done for. "As part of this change, Google Sync will also be sunsetted: Beginning June 15, 2024: New users will not be able to connect to Google Workspace via Google Sync." "September 30, 2024: Existing Google Sync users will not be able to connect to Google Workspace. Here is how you can transition your organization off Google Sync. To find Google Sync usage in your organization, please go to the Admin Console, navigate to Devices > Mobile & Endpoints > Devices, and filter by Type: Google Sync." That really sucks, I prefer the Mail.app to the third party Gmail app and I liked push notification e-mail compared to Fetch on a 15 minute timer. Why can't google do Push notifications through Mail.app yet?
- DamnableNook 3y ago
  The limitations and clearly second-tiering of the Exchange connector are what pushed me to move away from Google Workspaces last year. I settled on Fastmail, precisely because they support Push in iOS Mail.app. From my research, they are one of the very few who support the imap extensions required to do that. Have been very happy with them so far, they support all my workflows, and do so a lot better than Gmail.
JTbane 3y ago
Man, the way Google treats paying customers is appalling... It seems very frequent that they remove [WIDELY USED FEATURE] on a whim and tell users to pound sand.
daitangio 3y ago
[flagged]
mschout 3y ago
If I'm accessing IMAP with an app password will I still be able to do this after the Sep 30 deadline? I've re-read this 3 times and I have no idea. It almost sounds like they are disabling anything other that XOAUTH auth method from IMAP (which, I think, they already did for non Workspace accounts).
varelse 3y ago
[dead]
andreimackenzie 3y ago
About 10 years ago we set up a pretty slick integration from our office wifi controller to Google's account directory using WebDAV and Radius. It allowed us to have a WAP for insiders who could authenticate with their Google-issued one-time-passwords (needed because normally a Google login requires MFA if configured) and access our internal network with their individual Google accounts (no sharing of wifi credentials; no separate wifi login to manage for offboarding). It was certainly Less Secure by modern standards, but it saved a boatload of time for everyone to be right on our internal network as soon as they connected to wifi instead of having to VPN in.
deleted 3y ago
[deleted]
GordonFreeman65 3y ago
[dead]

428 points by sschueller 3y ago

taspeotis 3y ago

Oh no how will workplace printers scan to email now

aiddun 3y ago
You can still configure an app password
- sschueller 3y ago
  Good luck with that. I couldn't get it to work and to switch to a mail account on another non Google host. Already before the LSA would disable and you would need to go into the settings to re-enable it all the time.
  - apimade 3y ago
    It’ll end up as a local POP or SMTP daemon which redirects email through an OAuth’d app. Everything old is new again, we’re running services locally just to make legacy work.
  - firecall 3y ago
    App Passwords have always worked fine for us, and have done for years!
Symbiote 3y ago
How do they do it now? The one at my work sends the PDF as an attachment, from its own email address.
jabroni_salad 3y ago
I use smtp2go for that, it's dead easy.

andris9 3y ago

The wording is kind of ambiguous, but it seems that App-Specific Passwords will continue working > If you have scanners or other devices using simple mail transfer protocol (SMTP) or LSAs to send emails, you’ll need to either: configure them to use OAuth, use an alternative method, or configure an App Password for use with the device. > All Other Applications. If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth or create an app password to access these apps.

yau8edq12i 3y ago
The excerpt you quote doesn't sound ambiguous at all. App passwords will clearly still be supported.
- khorne 3y ago
  The titles of both the HN post as well as the original blog post are ambiguous however.
- notpushkin 3y ago
  Yeah. The HN submission title is incorrect though.
mugs 3y ago
It wasn't 100% clear to me either. The wording clearly says SMTP will support app passwords, but no clear indication if IMAP will still support them. But I asked Google Workspace Support specifically about this yesterday, and they said: > The application passwords will support IMAP, POP, and all SMTP configurations. Rest assured that OAuth serves as an alternative, offering a straightforward configuration process for any third-party application. The second sentence was just them continually pushing adopting OAuth. I'd love to, but the cost of the (recurring) security review is not feasible for our small SaaS app, so we'll be sticking with app passwords (thankfully).

charcircuit 3y ago

People giving away their google account password to other apps / companies is bad for security. I'm surprised this still existed. I think this hasn't worked for accounts that have had 2FA for quite some time. I remember having to switch several years ago.

sschueller 3y ago
I gave Google my IMAP account from another Google account in order not to have to check two accounts and have the mail forwarded...
unethical_ban 3y ago
Any decision that limits my ability to use third-party apps, accepting, etc. is a compromise not worth making. It sounds like there is a feature for generating additional passwords for specific apps/scopes? Anyway. Forced 2fa without warning has locked me out of several Gmail accounts. I didn't know when migrating took Proton that you must use their client for mobile. All these violations of abstraction!
ahoka 3y ago
Yep, this is the reason OAuth2 exists.
blagie 3y ago
It's not always bad security. a) I have apps with their own Google accounts b) I have devices with their own Google accounts It is (or was) a good way to go. Receiving an email from a scanner or sharing something with an app on Google Drive is a lot more secure than OAuth + "This app will have access to EVERYTHING IN YOUR GOOGLE DRIVE"
- jbverschoor 3y ago
  At a certain point, you'll have apps and devices that have (or have no) permission to use someone else's account that was previously under your control. > "This app will have access to EVERYTHING IN YOUR GOOGLE DRIVE" Then don't use such app

jsnell 3y ago

This is just about Workspace accounts, the change already happened to normal Gmail accounts years ago.

deleted 3y ago
[deleted]
SirMaster 3y ago
Not entirely true. I still access my personal Gmail account via the Microsoft Exchange option in my iPhone's Mail.app and I get push notifications this way rather than being stuck with Fetch. The reason it still works is that connections made to Google Sync for personal accounts prior to the discontinuation date like 10 years ago are still honored and "grandfathered" if you will. So to get it to work I just need to modify the Exchange GUID in my iPhone to what the GUID was on my phone back when I logged into Google Sync before they discontinued new logins. Fortunately changing this GUID is possible by taking an iPhone backup, modifying a plist file in the backup, and restoring that backup to the phone. So right now, on my iPhone 14 Pro, I am still using Mail.app with push notifications to my personal Gmail account.

interroboink 3y ago

My heart skipped a beat when I read this — I have various scripts and things that interact with Gmail. But it's okay. App passwords will still work, it seems. This is just removal of "Less Secure Apps" support, using the account's plain account user/password. I shudder to think how much automation would die if Google truly killed off everything but OAuth. I don't like the complexity OAuth. I enjoyed this Perl module documentation[1] that breaks down how the dang thing works, clearly written by someone as exasperated as me (: [1] https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Authen/OAuth2/Overview.pod https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...

leipert 3y ago
Shouldn't be _too_ hard to convert your scripts. I ran into the same problem and one workspace disallows App passwords. You can simply get the OAuth token with a little python script and then use it as the password: https://github.com/google/gmail-oauth2-tools/blob/master/python/oauth2.py https://github.com/google/gmail-oauth2-tools/blob/master/pyt... (see for example https://github.com/lefcha/imapfilter/issues/186 https://github.com/lefcha/imapfilter/issues/186)
- booi 3y ago
  and then have to reauthenticate it every 2 weeks because the refresh token seemingly expires for no reason...
  - justinc8687 3y ago
    If you set your app to "production", the refresh token works properly. Ignore the verification steps. It'll yell at you, but it'll work.
    - xmprt 3y ago
      How can you set an app to production without Google verification if you're not in a workspace. I'm guessing the answer is that there is no way.

ChrisArchitect 3y ago

Related: Changes to Gmail syncing with other email clients https://news.ycombinator.com/item?id=38975692 https://news.ycombinator.com/item?id=38975692

sir 3y ago

If you can’t switch to OAuth, you can use my proxy to allow any IMAP (or POP/SMTP) client to be used with a “modern” email provider, regardless of whether the client supports OAuth 2.0 natively: https://github.com/simonrob/email-oauth2-proxy https://github.com/simonrob/email-oauth2-proxy. No need for your client to know about OAuth at all.

mschuster91 3y ago
Thank you for writing that, really helped me out back when Microsoft pushed OAuth for Office 365.
nanna 3y ago
Brilliant. So this is how you could keep a client like mu/mu4e functional for Gmail and outlook365.
- yashasolutions 3y ago
  actually app password will keep working. Which is basically all you need for mu4e
emersion 3y ago
Unfortunately this requires users to setup their own OAuth client, which is a pretty manual/cumbersome process.
- rollcat 3y ago
  Same if you're building any OAuth-enabled client from source. (Remind me, what's stopping me from extracting the client secrets from the compiled binary, and re-using them elsewhere?)
  - yrro 3y ago
    The provider might notice that their key is being used in an unauthorized way and terminate your account, prosecute you for computer fraud and abuse, etc.

deleted 3y ago

[deleted]

ChrisArchitect 3y ago

News from September (2023)

sschueller 3y ago
Email was sent out today to many Google Workspace admins with a link to this blog post.

kylehotchkiss 3y ago

This is all about getting users off of the fantastic native mail apps and onto googles own. You can’t get realtime mail notifications without gmail.app or the soon to be deprecated Google sync. I hate it. I pay Google for workspace and I hate it. At least Mimestream still works on desktop but I bet they’re coming for that soon too.

cbg0 3y ago
Yes, it's pretty obvious this is what's going on. The solution to these "less secure apps" was to simply generate stronger passwords for them instead of making the user jump through hoops by using oauth2 proxies, especially for older hardware/software.
- rezonant 3y ago
  Which is actually supported already with App specific Passwords...
rezonant 3y ago
App specific passwords will continue to work, and will work fine if your native app does not support the usual OAuth flow.
- mcv 3y ago
  This is good to know, because I think I already use those everywhere (except on my latest machine; I should fix that). Even so, I will also be using this as a reminder to move my stuff away from Google.
- eastern 3y ago
  "will continue" can't really be said about anything Google with any degree of confidence.
esskay 3y ago
Fully agree. Also paying for my gmail account and hate every moment of it but nobody seems to be able to get remotely close to gmail for spam handling.

tamrix 3y ago

[flagged]

magicalhippo 3y ago

Been dealing with Microsofts OAuth transition at work, and it's been a bit of a PITA. Part of the problem is that it's just so opaque. You send the token and the server replies "nope", with no further explanation. I spent literal days trying to figure out why Client Credentials-flow didn't work until I found an answer buried on their help forum saying oh yeah, client credentials flow isn't supported yet. It is now for IMAP/POP, but still not for SMTP IIRC (though OAuth is not requiredfor SMTP yet). Next it was figuring out the right scopes, which at the time was not very well documented. Again not very helpful error messages by the servers. Google's mail servers any better?

xtajv 3y ago
> Part of the problem is that it's just so opaque. You send the token and the server replies "nope", with no further explanation. Catch-all HTTP 401s and 403s are there to thwart https://en.wikipedia.org/wiki/Oracle_attack https://en.wikipedia.org/wiki/Oracle_attack - unfortunately, servers cannot afford to be "helpful" when it comes to unauthenticated clients.
- mmbop 3y ago
  They should have a debug mode that is user-activated for stuff like this. I also have burned too many hours trying to get various OAuth flows working.
  - magicalhippo 3y ago
    Yeah some development servers that didn't actually send the mail anywhere but did give usable error messages for example would be amazing. To avoid it being used as an attack vector they could be tied to special app registrations that had to be registered with the mail development system in advance.
datadrivenangel 3y ago
Microsoft is amazingly good at those opaque error messages. Such a mess of UX

superkuh 3y ago

It's important to note here that OAuth isn't one thing anymore like it was for OAuth 1. With OAuth2 it's more like OAuth is a toolset for implementing your own proprietary protocol. Each major provider needs it's own custom implementation in email clients to cover it. There's no general purpose oauth2 in practice. OAuth2 is more like a per-corporation protocol. Lets hope they don't sunset "app passwords" for at least a few more years. If you haven't yet, consider setting up your own mailserver for kicks and using it for non-important things to build IP reputation for when public email stops being email entirely.

purpleidea 3y ago

I haven't been able to get `offlineimap` working with gmail in at least the last six months. If anyone has been successful, please let me know. The blog posts I've found all have out of date information. If I'm locked into their cloud, I'd at least like to have a backup of my data-- and no, I don't want the takeout service, the Maildir format and features of offlineimap are what work great!

fifteen1506 3y ago
App passwords worked for me like 3 or 4 months ago.
terinjokes 3y ago
I use mbsync/isync instead of offlineimap, but I've had no issues using mailctl to handle the OAuth2 tokens and refresh. Does the example on the ArchWiki[0] work for you? [0]: https://wiki.archlinux.org/title/OfflineIMAP#OAuth2_access_tokens_via_mailctl https://wiki.archlinux.org/title/OfflineIMAP#OAuth2_access_t...

miroljub 3y ago

And I migrated away all my accounts from Google in anticipation of it being more and more user hostile. Honestly, if I were still at Google, I would be outraged. In the name of false security, they make the wall around their garden taller and thicker every single day.

jonathanstrange 3y ago

I will do everything in my power to pressure my university to migrate their email accounts to another service. This is anti-competitive behavior designed to make it as hard as possible to use email client software. For example, check the procedures needed to set up oauth2 in my preferred client claws-mail.[1] That's insane. [1] https://www.claws-mail.org/faq/index.php/Oauth2 https://www.claws-mail.org/faq/index.php/Oauth2

alisonsandy 3y ago
> This is anti-competitive behavior designed to make it as hard as possible to use email client software Use App password. They are not blocking any 3rd party clients. Are you advocating using real password in every random client that may or may not transmit it in full text elsewhere? I do assume you know security essentials.
- jonathanstrange 3y ago
  I will do that if our university decides to switch on 2-factor authentication (which would be total chaos), but my trust in Google's ability to make this effortless and easy in third-party email clients is zero. See my other post why. Regarding security: Google had physical fiber optics connections to the NSA and claimed they didn't know about them. It's not a very credible claim but if if was true, then it would be proof that Google has no competence in security at all.
  - alisonsandy 3y ago
    Any decent 3rd party client does this already. Take for example, thunderbird or k9-mail - major open source ones. Even Mail (from Apple, macOS) does this. What else you need? Sure if you use mutt or ALPINE read the related forums for help. while anyone can criticise any large company one should do it for the correct reasons.
    - jonathanstrange 3y ago
      Your frankly-speaking somewhat condescending reply fails to address the issue. This has nothing to do with the client software, which is claws-mail in this case. My organization does not enable 2-factor authentication. Once they do, claws-mail can be configured to use "App passwords." But if you look at my other post, quotes of Google's own documentation of "App passwords" and various testimony in this thread do not inspire much confidence that this will work as an acceptable long-term solution. As I said elsewhere, the rationale behind all of this seems to be anti-competitive behavior. It's not new idea to disguise anti-competitive behavior as security issues (cf. e.g. Apple's code signing and Gatekeeper). This also explains the misleading and incorrect term "Less Secure Apps" Google uses.

gramakri2 3y ago

I don't think the title is correct. IMAP/SMTP will still be supported with App Passwords. That's my reading of it.

nextgens 3y ago

It would be great if Google supported rfc8414 and rfc7591. Right now most MUAs hardcode credentials instead of auto-discovering/registering/configuring them and decline to implement those standards "because the big boys don't support them". The practical result is that one cannot use oauth2 on their domain easily: the MUA needs to be told about which set of oAuth2 creds to use. See https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm https://searchfox.org/comm-central/source/mailnews/base/src/... , https://github.com/thunderbird/autoconfig/tree/master/ispdb https://github.com/thunderbird/autoconfig/tree/master/ispdb and https://bugzilla.mozilla.org/show_bug.cgi?id=1602166 https://bugzilla.mozilla.org/show_bug.cgi?id=1602166

Perseids 3y ago

> An app password is a 16-digit passcode that gives a less secure app or device permission to access your Google Account. App passwords can only be used with accounts that have 2-Step Verification turned on. [1] Isn't it funny, how the "less secure app or device" is completely on par with OAuth-capable apps regarding security just by using a server-side mechanism Google could have promoted since… forever? Almost as if it technically isn't a feature of the app at all. (Yeah, I get it, "apps where the secure workflow is less convenient" doesn't have the same ring to it, so the simplification is justifiable for easy communication – you will say. The greater problem is that it is kind of Google's thing to always interpret security concerns in such a way that it furthers Googles agenda and this puzzle piece is no exception.) [1] https://support.google.com/mail/answer/185833 https://support.google.com/mail/answer/185833

happyopossum 3y ago
> just by using a server-side mechanism Google could have promoted since… forever? Google has been pushing 2FA and App Specific Passwords for many many years. They’re just now making it mandatory for apps that can’t update to support oauth
joshuamorton 3y ago
> Isn't it funny, how the "less secure app or device" is completely on par with OAuth-capable apps regarding security just by using a server-side mechanism Google could have promoted since… forever? They aren't on part though, Oauth is vastly less phishable and has vastly more control over specific permissions. App passwords are functionally all-or-nothing, whereas with OAuth you can configure whether something can read, modify, change settings, etc.

dbrgn 3y ago

There is e-mail, and there is Gmail. (By the way, there are a lot of great e-mail providers other than Google. Often even with a web UI superior to the one by Gmail.)

kiwijamo 3y ago
Example: Fastmail.

lgrapenthin 3y ago

[flagged]

kuon 3y ago

I host my own email server, and I want to tell that with a static IP with reverse dns, spf, dkim and dmarc I had zero issue delivering mails. It might sound complicated, but it is not that hard.

martin_a 3y ago
True! Also you can pay 2 €/month to Hetzner/$webhosterofchoice and have them handle that for you... No need for Google after all is what I want to say.

emersion 3y ago

Note that Google has a very complicated process to migrate an IMAP/SMTP app to OAuth. There is a long list of requirements to register an OAuth client for these protocols: https://developers.google.com/terms/api-services-user-data-policy#additional_requirements_for_specific_api_scopes https://developers.google.com/terms/api-services-user-data-p...

forwardemail 3y ago

[flagged]

pdimitar 3y ago

I'm accessing my Google Drive through rclone, I should check if this affects it.

RockRobotRock 3y ago
It won't. rclone uses OAuth.
- pdimitar 3y ago
  Oh, cool. Thank you.

mort96 3y ago

Flagged, because the title is both editorialized and factually wrong.

schappim 3y ago

@dang the title is misleading as the user can also "configure an App Password for use"

greatgib 3y ago

To be noted, the most annoying thing with Oauth2 and Google on Android is that you can't login with an email client or calendar with your Google account without your full phone to be associated with this Google account. Also giving policy right on your device by this Google account. That is totally insane in my opinion. And you can't easily bypass that as oauth2 usage in WebView inside apps are easily restricted by Google on Android.

ysleepy 3y ago
Can't alternative clients like k9 implement OAuth on their own? I believe I set up Thunderbird on my desktop with OAuth and it works (With office365). Sadly the number of email clients I would trust is limited, many send off your credentials to some remote server. EDIT: k9 already supports oauth for imap. https://docs.k9mail.app/en/6.400/accounts/incoming_imap/ https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
- dmw_ng 3y ago
  The trouble with OAuth is to get a production client ID you must pass a third party security audit.. this is in excess of $20k and AIUI must be repeated periodically. Using a developer client ID is already heavily limited, and I have no doubt now that this ladder has been pulled up, developer IDs will see further restrictions in future. IMAP/POP passwords have long defaulted to disabled in Gmail, Gmail survived 20 years without need for these new restrictions, I can't imagine attack techniques have improved and Google's internal technical staff have regressed so substantially that they are now essential. This change seems more motivated by creating frictions for escaping the Google vortex than anything to do with security.
  - rrdharan 3y ago
    > I can't imagine attack techniques have improved and Google's internal technical staff have regressed so substantially I can definitely imagine, and I in fact believe, both of those things to be true.
- greatgib 3y ago

d99kris 3y ago

I understand their announcement says app passwords will stay (for now). But should Google eventually also deprecate app passwords, it would really restrict the use of third-party clients with GMail, given the self-paid security assessment OAuth clients must undergo. It would be a sad development given that email is one of the last popular "open messaging protocols" in use, where one can choose what client to use.

martin_a 3y ago
Everybody is free to use something else besides GMail. Nobody forces anybody to use that.
- leejoramo 3y ago
  But then there are there are large organizations who decide these things for many people.

deleted 3y ago

[deleted]

londons_explore 3y ago

It's because IMAP, SMTP and POP allow substantial access to your google account and life, yet none have the ability to do 2 factor. Nor do they allow any kind of anti-robot verification. That means it's super easy to do credential stuffing attacks, and at google-scale, that sort of attack is going to let an attacker ruin a lot of lives. This is a good thing, and they should have done it years ago (they kinda did by defaulting IMAP/POP/SMTP access to off - that protects most users - this is just for the rest)

TacticalCoder 3y ago
I take it if someone really still want to fetch all his emails the old way, he could configure GMail to forward every single email to another address (not a GMail one): one still allowing IMAP/POP. Not a panacea but it may be an acceptable workaround for some usecases.
- londons_explore 3y ago
  You can still use app-specific passwords, so your 1992 mail client will still work... Although sending even an app-specific password in cleartext over the internet seems like a bad plan.
  - mcv 3y ago
    But why are those more secure than other passwords? How can they know that this 1992 app is the app it claims to be?
    - londons_explore 3y ago
      Because for the user account, people use things like "hunter2". But app specific passwords are long random strings unlikely to be reused by the user for another site.
      - mcv 3y ago

dm319 3y ago

Is this going to be a problem for my mutt and mbsync setup?

londons_explore 3y ago

I wonder if this was triggered by the 23andMe breach? In that, it became pretty clear that the press and the public will blame a company if user accounts are breached even if the user had a weak/reused password. Since then, companies kinda have a responsibility to protect the users data despite the user doing stupid stuff.

jsnell 3y ago
No. This was originally announced in 2019 and has been proceeding in phases since then.

londons_explore 3y ago

This rollout plan seems misguided... You're going to remove the option from the admin console before sunsetting the feature? So users can't turn it off to test/see impact?

londons_explore 3y ago

You know what would be nice... Google going through their access logs and sending every admin an email list of usernames and services impacted by this change. Ie. The following users in your organisation are logging in with password-based "Less Secure authentication", and will need to migrate to another login method by 30th September: [list] Logins were to the following services: [list] For a full breakdown of which users logged in to which services insecurely on what date/time, reply to this email and we will auto-respond with complete logs. For help resolving this issue, see [our help article].

sschueller 3y ago
They did, I got an email, with an attachment spread sheet containing users email addresses on my domain. Bottom of email stated "A list of affected users is attached."
- liveoneggs 3y ago
  me too? The file was named users.xls.exe and it just opened a weird black screen for a minute and closed. idk
ourdomain-admin 3y ago
I got an email listing my users, luckily only 4. What i'm trying to find now is how to run my own report so i can see when those users are 'fixed'. Anyone able to point me in the right direction? Thanks
- londons_explore 3y ago
  you probably can't - the report is probably a massive mapreduce over all of googles access logs - the kind of thing they can do once, but they won't add a button to the dashboard for you to do yourself.
  - ourdomain-admin 3y ago
    Thanks. I've spent the morning looking and that would explain why I couldn't find it.

jcmontx 3y ago

What's the way to go with backends that send emails using gsuite's SMTP?

donatj 3y ago

Welp. Add Google Sync to the Google Graveyard

nunez 3y ago

They really buried the lede here. Google Sync is their implementation of Exchange ActiveSync. Google Sync (or IMAP) is the only way to send emails with aliases on iOS with Apple Mail. This is terrible.

_chu1 3y ago

Made the swtich to Tuta (previously Tutanota) about 2 years ago and never once looked back. I only wish they had support for some sort of protocol for third-party clients.

joering2 3y ago
That was a turn off for me personally. While I think more expensive per user (but free for up to 150 emails per day without your own domain name), ProtonMail has "Proton Bridge" that works wonderfully for me on Windows 7/11. It gives you what the name suggest, its a bridge between your cloud encrypted emails and sets up local SMTP that you can connect any program to (I have Thunderbird and Outlook). Haven't had any issues at all.
- _chu1 3y ago
  Is Proton Bridge free now? I remember it being paid.

nurettin 3y ago

The problem with gmail's OAuth is the initial setup. After that is done, it works fine for years. First, you need to create an authorization token and a refresh token. If your authorization fails, you need to use your refresh token to get a new key. But the most damning part is: The initial process which gets you a refresh token requires you to login via browser. That's hard to deploy on a headless server. At some point I remember having to create a large enough swap space to run UI, install xorg, install google-chrome, go through the graphical process, then uninstall xorg and remove the unused swap.

bvrmn 3y ago

Does anybody know what makes refresh key is more secure than login/password? I'm quite dumb and don't understand how OAuth make apps more secure. Also maybe someone knows how to get read only token for IMAP access? Last time I've checked there were no any scopes. One literally could use same token to access and IMAP and SMTP. But IMAP/SMTP token split could really improve security.

merb 3y ago
because apps do not get credentials, so the token can be easily revoked just for this app. thats why app passwords are still fine.
- bvrmn 3y ago
  Thank you, it makes a lot of sense.

ctime 3y ago

Google isn’t really worried about password entropy beyond a reasonable amount. The primary threat model is phishing. This is why multifactor is so important and once once you have that enabled, nobody gives a shit if you even rotate your password. Just needs to be long enough and not guessable because it’s not the sole means of authentication. Probably not a good idea to have something as critical as one’s primary email account identity tied to only a single factor of phishable credentials. Requiring App passwords seems better, but it bypasses requiring a MF. oAuth, while a a beast, seems even better as the workflow still initially requires a second factor.

SirMaster 3y ago

So if I am connecting to my Gmail on my iPhone via the "Microsoft Exchange" option and using an app password I will still be OK? The reason I still connect via the "Microsoft Exchange" option instead of picking the "Google" option in Apple's Mail.app is because I get Push notification for my Gmail when using the "Microsoft Exchange" option compared to only having the Fetch option available for the "Google" option. After reading more carefully, I guess my method is done for. "As part of this change, Google Sync will also be sunsetted: Beginning June 15, 2024: New users will not be able to connect to Google Workspace via Google Sync." "September 30, 2024: Existing Google Sync users will not be able to connect to Google Workspace. Here is how you can transition your organization off Google Sync. To find Google Sync usage in your organization, please go to the Admin Console, navigate to Devices > Mobile & Endpoints > Devices, and filter by Type: Google Sync." That really sucks, I prefer the Mail.app to the third party Gmail app and I liked push notification e-mail compared to Fetch on a 15 minute timer. Why can't google do Push notifications through Mail.app yet?

DamnableNook 3y ago
The limitations and clearly second-tiering of the Exchange connector are what pushed me to move away from Google Workspaces last year. I settled on Fastmail, precisely because they support Push in iOS Mail.app. From my research, they are one of the very few who support the imap extensions required to do that. Have been very happy with them so far, they support all my workflows, and do so a lot better than Gmail.

JTbane 3y ago

Man, the way Google treats paying customers is appalling... It seems very frequent that they remove [WIDELY USED FEATURE] on a whim and tell users to pound sand.

daitangio 3y ago

[flagged]

mschout 3y ago

If I'm accessing IMAP with an app password will I still be able to do this after the Sep 30 deadline? I've re-read this 3 times and I have no idea. It almost sounds like they are disabling anything other that XOAUTH auth method from IMAP (which, I think, they already did for non Workspace accounts).

varelse 3y ago

[dead]

andreimackenzie 3y ago

About 10 years ago we set up a pretty slick integration from our office wifi controller to Google's account directory using WebDAV and Radius. It allowed us to have a WAP for insiders who could authenticate with their Google-issued one-time-passwords (needed because normally a Google login requires MFA if configured) and access our internal network with their individual Google accounts (no sharing of wifi credentials; no separate wifi login to manage for offboarding). It was certainly Less Secure by modern standards, but it saved a boatload of time for everyone to be right on our internal network as soon as they connected to wifi instead of having to VPN in.

deleted 3y ago

[deleted]

GordonFreeman65 3y ago

[dead]