yandex has free mail with free custom domain hosting
Turning off less-secure app access to G Suite accounts
21–30 of 37 posts
Re: Turning off less-secure app access to G Suite accounts
#22This 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.
I've been using Thunderbird fine with App Specific Passwords. Despite the name, these are just revocable passwords.
Re: Turning off less-secure app access to G Suite accounts
#23Earlier quoted context omitted.
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
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).
Re: Turning off less-secure app access to G Suite accounts
#24yandex has free mail with free custom domain hosting https://connect.yandex.com/pdd/
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".
Re: Turning off less-secure app access to G Suite accounts
#25I 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?
Re: Turning off less-secure app access to G Suite accounts
#26Earlier quoted context omitted.
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 s…
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.
Re: Turning off less-secure app access to G Suite accounts
#27This 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), bu…
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.
Re: Turning off less-secure app access to G Suite accounts
#28Does 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.
Not if the sole purpose of that account is email and nothing more. I should be able to make decisions about what an account is used for and how to authenticate, even if that's the "wrong" or "less-secure" decision.
Re: Turning off less-secure app access to G Suite accounts
#29It’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.
Re: Turning off less-secure app access to G Suite accounts
#30Earlier quoted context omitted.
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 s…
You can try Migadu, which is priced by number of outgoing emails per day and not by storage or domains or mailboxes. The company is in Switzerland, but it uses a data center in France. I personally have very limited experience with the service, and cannot give either a strong yes or no for it.