Microsoft's New Outlook Security Changes Impact 3rd-Party Apps and Gmail Integration

Microsoft is making changes to Outlook for consumers to enhance account security as part of its Secure Future Initiative. Starting September 16th, the company will end support for Basic Authentication for Outlook personal accounts, requiring users to access their email through apps using Modern Authentication.

Microsoft will also remove the light version of the Outlook web application on August 19th and discontinue support for Gmail accounts in Outlook.com on June 30th. Users of affected email apps will be notified by the end of June to update their settings or reconfigure their accounts. The latest versions of Outlook, Apple Mail, and Thunderbird will support these changes, while the new Outlook for Windows and Mac apps will continue to support Gmail accounts. Microsoft is also migrating Windows Mail and Calendar users to the new Outlook for Windows app ahead of ending support for the built-in apps later this year.

Outlook Security

[Anonymous Coward]

is an oxymoron.

Thuinderbird

[nicubunu]

I strongly suggest you to try the current Thunderbird (Supernova), which support a lot of features and has a new, modern UI (IMO, new UI in Thunderbird in good, while new UI in Firefox is bad).: optional vertical layout, optional card view and such. Next release (in about a month or so) is expected to bring native Exchange support. Also, very soon they will have an Android version, by adopting K9-Mail. Seriously, after near-death, Thunderbird development is on steroids.

Re:Thuinderbird

[Seven Spirals]

That's all good and I'm glad that Thunderbird supports the "Modern Authentication". However, I'm thoroughly unconvinced that there was anything insecure about IMAP over STARTLS, SSL, or various other schemes. Sounds more like M$ is using "security" as an excuse to lock out open standards and 3rd party mail providers and further try to capture and contain e-mail by using proprietary "standards" they basically pull out of their ass. Google is doing the same thing with their ridiculous "OAuth2" hand waving. It's pretty crass and transparent that they want to shut down small sites that admin their own mail servers and try to capture the market. Also, I don't give a damn if you're all happy with paying $9 a month or whatever, others are not and there is no reason why they should have to, especially given that many of them have been running for decades before this harassment by M$ and Google.

Re:

[barra.ponto]

Davmail supports Modern Authentication for Exchange, I've been using to get my work email into my Linux work machine.
Getmail 5.14 supports XOAuth2 and is able to get mail from Gmail/Imap, I've been using to get my personal email from Gmail into my Linux home machine.

Re:

[Seven Spirals]

Thanks for pointing that out. I knew about DAVmail but not about Getmail. Nice.

Re:

[unrtst]

Davmail supports Modern Authentication for Exchange, I've been using to get my work email into my Linux work machine.

Getmail 5.14 supports XOAuth2 and is able to get mail from Gmail/Imap, I've been using to get my personal email from Gmail into my Linux home machine.

Alpine (modern fork of U.W. Pine email client) also supports modern authentication and OAuth2 (to both exchange/office365 and gmail, as documented examples). However, I couldn't use it to connect to the Office 365 mail servers to get my work email because they block clients based on application certifications (client side certificate that identifies the software client that is connecting to the server).

Are Davmail and Getmail allowed by default to connect to Office 365, or does the server admin have to expl

Re:

[barra.ponto]

However, I couldn't use it to connect to the Office 365 mail servers to get my work email because they block clients based on application certifications (client side certificate that identifies the software client that is connecting to the server). Are Davmail and Getmail allowed by default to connect to Office 365, or does the server admin have to explicitly allow those clients?

One can register an email client, davmail in my case, on Azure, using one's @work email. Maybe admins can block that but in my case that is allowed. Can't remember much, just followed instructions I searched for.

Re:

[unrtst]

However, I couldn't use it to connect to the Office 365 mail servers to get my work email because they block clients based on application certifications (client side certificate that identifies the software client that is connecting to the server). Are Davmail and Getmail allowed by default to connect to Office 365, or does the server admin have to explicitly allow those clients?

One can register an email client, davmail in my case, on Azure, using one's @work email. Maybe admins can block that but in my case that is allowed. Can't remember much, just followed instructions I searched for.

Yes. I went through those instructions (https://alpineapp.email/alpine/alpine-info/misc/xoauth2.html and https://alpineapp.email/alpine... [alpineapp.email]).

Like you say, you have to register your client with the mail provider (Azure, Office365, Gmail, etc..). When doing so on my corporate account, it is not automatically accepted. An admin must review and approve it. The admin would not do so.

This provides a simple way for them to block email clients based on user agent, regardless of whether or not that email client prope

Re:

[barra.ponto]

When doing so on my corporate account, it is not automatically accepted. An admin must review and approve it. The admin would not do so.

I've been using Emacs to read emails for close to 40 years (I shaved my grey beard 12 years ago!). The day I can't do that at work I'll retire, but I understand that is not an option for everyone.

I've been with my current company going on 20 years and had to work around the different setups used, from on premises to O365. The craziest work around I had was to run outlook in a virtual machine with filters that copied everything to a cyrus imap setup on my linux box and then just read email from there. N

Re:

[unrtst]

Pretty similar story here. Was at the same company for just shy of 20 years. Jumped through hoops to get mail into Alpine several times. This last incarnation was the end of that road for me. I didn't quit/retire over it, but that certainly played a part in my decision to leave. They also reduced max mailbox size (which was never a problem for me before because I downloaded all my mail), and implemented a 1 year email retention (anything older gets deleted), and the only way to save stuff longer required us

Re:

[theendlessnow]

There is truth to this. "Modern Authentication" is as much damage control and marketing speak as it is anything else. Why? Because the interior of Microsoft's OS's and even other entities if full of Archaic Auth, clear text stuff, where MS tries to force signing vs going through the high impact work of encrypting (because it would be painful for them and their base).

There's a lot of crap in Microsoft land. Again, Microsoft uses "words" to mask their poop.

Microsoft is still dealing with all their hi

Re: Thuinderbird

[PsychoSlashDot]

The core issue is that IMAP with or without SSL doesn't support MFA. It isn't about encryption of the data stream. It's about authentication. If you don't have MFA you're vulnerable to phishing, shared-passwords lost in compromised sites and rainbow tables. You may not care personally, but the industry does.

Re: Thuinderbird

[Mousit]

The core issue is that IMAP with or without SSL doesn't support MFA. It isn't about encryption of the data stream. It's about authentication. If you don't have MFA you're vulnerable to phishing, shared-passwords lost in compromised sites and rainbow tables. You may not care personally, but the industry does.

"The industry" already solved this by disallowing access via IMAP using your main account password, and instead requiring that 3rd-party apps must use App-Specific Passwords, which has been the case for major providers for yeeeaaaars now. ASPs are, in practice, effectively the same thing as OAuth/Modern Authentication tokens. After all, to get them you have to log in with whatever MFA you have, thereby authenticating, and then you generate an app-specific password, which the provider generates a random, secure password for you, instead of allowing you to enter some shitty password yourself. This is almost exactly the same thing you do to generate an OAuth token, other than the OAuth being generated via API/programmatically. That's really the only difference, as otherwise the token is just a string. A password. Yes, it's a long, complex, randomly-generated password (same as an ASP can be), but it's still just a password string.

And once generated, that token can be stored, copied, even used by multiple apps. It can also be stolen, if it's stored unprotected. Quite a few mail fetchers that "support" OAuth just have you generate this token string and stick it in their config file, using it in quite literally the same way they use a password entry. The aforementioned getmail, above in this thread, does it precisely this way.

About the only "advantage" that OAuth/Modern Authentication adds over app-specific passwords is that the tokens expire regularly. Most app-specific password implementations I've seen (Apple and Google are the ones I have the most first-hand experience with) don't expire. However that's just a choice from the provider, and could very simply be changed so that ASP's expire just like tokens do, and need to be re-generated periodically by having you log in with your MFA again.

In short, I agree with the parent. There's no reason to shove proprietary "standards" that, in reality, do not actually offer any advantages or additional security over the existing app-specific password method.

It isn't about encryption of the data stream. It's about authentication.

No, it's about control.

Re:

[markdavis]

^^^ +1 Insightful +1 Informative

I wish I had mod points right now. Hopefully others will do it. We do *NOT* need the likes of MS, Google, and Apple completely taking over Email. And this is just another step in that direction.

Re:

[dbialac]

MFA as it exists today violates what needs to be fundamental to good security: difficult for the intruder but easy for the legitimate user. "I forgot my phone" is not easy and if you don't have/want a smart phone, you're forced to buy hardware and pay for a service (cell service) you don't necessarily want. There are people who are tired of constant online access who want to or have ditched smart phones [bbc.com]. I'm becoming one of them. It's also really disconcerting when I watch kids running around with their par

Re:

[markdavis]

>"MFA as it exists today violates what needs to be fundamental to good security [...] "I forgot my phone" is not easy and if you don't have/want a smart phone, you're forced to buy hardware and pay for a service (cell service) you don't necessarily want."

This is not exactly true. With TOTP, you don't have to use a phone. It can be a laptop, a desktop application, a tablet, whatever. It can be some old device you have around. You can use free/open-source apps that have no ties to any company or servic

Re:

[dbialac]

The biggest challenge is convincing the IT department of a large company to do it. Now MS is about to force 2FA on their customers for their customer-focused email accounts for their app. I'm on the verge of setting up my own mail server again and just forwarding mail to a domain I've had and has been active for years.

Re: Thuinderbird

[guruevi]

IMAP/SMTP/POP3 definitely supports OAuth2, even Microsoft added it to their Exchange Online years after it became common. There is even a proxy project that will intercede on behalf of your older applications that donâ(TM)t do OAuth2.

Can they atleast fix search?

[Draconis183]

I mean, please? Pretty please?

Re:

[zlives]

open ai to the rescue?
once all your data is ingested, then profit

Sigh

[vbdasc]

Well, looks like I'll need to reactivate my dusty Yahoo Mail accounts then. Outlook dot com is soon going to be unusable. Farewell Hotmail, and thanks for all the fish.