Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security

Microsoft Exchange Online Users Face a Key Security Deadline Saturday (protocol.com) 43

Posted by msmash from the fixing-things dept.
Microsoft is about to eliminate a method for logging into its Exchange Online email service that is widely considered vulnerable and outdated, but that some businesses still rely upon. From a report: The company has said that as of Oct. 1, it will begin to disable what's known as "basic authentication" for customers that continue to use the system. Basic authentication typically requires only a username and password for login; the system does not play well with multifactor authentication and is prone to a host of other heightened security risks. Microsoft has said that for several types of common password-based threats, attackers almost exclusively target accounts that use basic authentication. At identity platform Okta, which manages logins for a large number of Microsoft Office 365 accounts, "we've seen these problems for years," said Todd McKinnon, co-founder and CEO of Okta. "When we block a threat, nine times out of 10 it's against a Microsoft account that has basic authentication. So we think this is a great thing." Microsoft has been seeking to prod businesses to move off basic authentication for the past three years, but "unfortunately usage isn't yet at zero," it said in a post earlier this month.
This discussion has been archived. No new comments can be posted.

Microsoft Exchange Online Users Face a Key Security Deadline Saturday More

Microsoft Exchange Online Users Face a Key Security Deadline Saturday

Comments Filter:

  • That vendor (Score:1)

    by Anonymous Coward

    Using their software is the gift that keeps on giving.

    Now with subscription!

  • the system does not play well with multifactor authentication

    Microsoft's own authentication software doesn't play well. It's the option they push front and center when you have to configure your MFA. I always tell people to use the alternative option link just below. Either get a phone call or text message. Always works. Unlike Microsoft's own software.

    • Re:Doesn't play well? (Score:5, Insightful)

      by vux984 ( 928602 ) on Tuesday September 27, 2022 @05:54PM (#62919155)

      " I always tell people to use the alternative option. Either get a phone call or text message. Always works."

      That's actually less secure. SIM cloning/hijacking is a well known attack vector against phone/text 2FA.

      And no it doesn't always work, hell... my phone doesn't get SMS messages reliably in my basement rec-room. For me wifi is far more reliable. I realize that's not true for everyone though.

      'Tap to approve' is also far less hassle than phone call or text message.

      • Re: (Score:3)

        by Monoman ( 8745 )

        The MS Authenticator apps works fine for our org too. Most folks don't realize these MFA apps don't need data connectivity and that the built in passcode option works if they're in their basement.

        Another option we have done for the few folks that refuse to use their phone or the app is the TOTP device. Some are pretty cheap ( $20) these days.

    • I'm not sure what's wrong with the system setup you're referencing, but it's probably more complex than just because it's Microsoft's MFA. My company of 1,000 employees uses Azure Active Directory with MFA for everything, using the Microsoft Authenticator app, and I've yet to see an issue.

    • It's funny, because every time we have a problem with modern authentication, the first thing that Microsoft's own support staff tells us to do is to turn off Modern Auth (ADAL). I always have to push back on that and tell them to dig deeper for an acceptable solution. Guess they won't be able to use that little chestnut going forward.

  • I think we all know this - if you keep waiting for everyone to move before you terminate a service, there are a non-trivial number of people who will never do it.

    Set deadlines, send regular reminders, and then end it at the deadline. Good on Microsoft (in this instance).

    • What would be really useful is if Microsoft could provide an easy way to access a log of users that are still using basic authentication. There is a way to find this information, but why isn't there a simple dialog for it?

      • more simple than: Navigate to the Azure portal > Azure Active Directory > Sign-in logs. Add the Client App column if it isn't shown by clicking on Columns > Client App. Select Add filters > Client App > choose all of the legacy authentication protocols and select Apply. ??

        • more simple than: Navigate to the Azure portal > Azure Active Directory > Sign-in logs. Add the Client App column if it isn't shown by clicking on Columns > Client App. Select Add filters > Client App > choose all of the legacy authentication protocols and select Apply. ??

          How is that as simple as a button in the Admin panel (no need to go down the hierarchy) that, with a single click, gave you a report of all the users who had logged in using basic auth during the past month, or something similar?

          Also, the logs you refer to only go back 7 days, which is hardly sufficient.

          • So your complaint is that not everything you want to do is exactly one click away? I mean it you want to have a GUI that's just a million buttons feel free to ask for it in Microsoft's feedback forum, I'm sure they get working on that right away.

            • So your complaint is that not everything you want to do is exactly one click away?

              Actually, no, because the proposed method involves trawling through logs and it is quite possible one might miss a user who only occasionally logs in using basic auth. You also seem to ignore the 7 day limitation.

              But, really, Microsoft has put a lot of effort into this, but doesn't seem to have thought about making it easy for administrators. It's hardly beyond their capabilities. This is an obvious thing to do yet Microsoft doesn't seem to have thought about to the obvious thing to make the transition for

          • You can go back more than 7 days but you have to pay more. Welcome to the cloud. For my ex employer, MS is busting their budget trying to achieve parity with what they had with on prem solution. E3 pricing plan is not sufficient if you want real visibility into your Azure environment.

      • This report is in the m365 admin portal, and the warning about basic auth deprecation has been up there for three years. Anyone still using it has already asked for an exception to get it turned back on and can ask for an exception again to turn it back on until January.

        • This report is in the m365 admin portal

          Where is this mythical report? Yes, you can gather some information from the last 7 days from the sign-in logs, but that's not quite the same as I am suggesting.

          Even Microsoft, in their many emails on this topic hasn't actually told anyone how to gather information about users still using basic auth.

          Anyone still using it has already asked for an exception to get it turned back on

          Unless it was turned off for that tenant, why would they ask for an exception?

          • What would you like to see that's not in the sign-in report? Are you looking at Sign-in Logs >> Filters >> Client App >> Legacy Auth Clients?

            The only really opaque part to it is that you can trace the app with the user agent string. e.g. EXO is BAV2ROPC. Android is CloudMagic. (I don't know the one for iKit.)

            • What would you like to see that's not in the sign-in report? Are you looking at Sign-in Logs >> Filters >> Client App >> Legacy Auth Clients?

              That's what I am looking at. There are some issues with the data and some with the presentation.

              Data: only the last 7 days is not sufficient. That's less than a typical vacation.

              Presentation. You might have to look through pages of sign-in logs in order to find all the users. We have a tiny number of users, I can't imagine what it would take to look through this if I had hundreds or thousands of users. Even with only two users still reported using legacy auth, the report is more than one page. I simply wan

              • The lack of a summary list is a legitimate criticism, and I agree. The sign-in logs should go up to 30 days if you change the "Date" drop down.

                If you want historical data and you've got AAD P1 or P2 you can hoover the data over into a Log analytics workspace and/or Power BI and create the summary report from there.

                The other way around it is to use the Download button above the date box, grab the CSV, and pivottable it in your favorite open-source spreadsheet product that is totally not Excel because no-one

                • The sign-in logs should go up to 30 days if you change the "Date" drop down.

                  I tried that. You have to pay more (have a more expensive plan) to see more than 7 days.

                  If you want historical data and you've got AAD P1 or P2

                  Is that another way to say that I need to spend more?

                  The other way around it is to use the Download button above the date box, grab the CSV,

                  Agreed, but that should not be necessary. The whole rigamarole should not be necessary.

    • Comment removed based on user account deletion

  • Microsoft is the cause as well (Score:4, Interesting)

    by SmaryJerry ( 2759091 ) on Tuesday September 27, 2022 @05:40PM (#62919123)
    The MFA that comes with 365 Business Standard is buggy and difficult to use and get properly setup with multiple users. Sometimes it completely locks out a user and then they aren't able to login on certain devices even with their MFA and password. It seems like they are pushing to get you on Business Premium where you can actually manage MFA properly in Azure.

    • I can confirm that Azure Active Directory with MFA works well. My company then syncs AAD to it's on-premise servers' ActiveDirectory configuration. This also works well.

    • Re: (Score:1)

      by Tablizer ( 95088 )

      Generally MS is making their non-cloud solutions trickier to set up or keep running. That means the cloud is much more profitable to them, probably because lock-in and nickle-and-diming is even easier to achieve in Cloudville.

      Our org's procurement bureaucracy is not designed to handle MS's cloud-based "microfee" approach, and it's causing indigestion.

  • I know of many business that send various notifications, invoices, and such via e-mail programmatically. Along with, say, copiers or multi-function printers that scan to e-mail. It's very common for this to be done using Basic Authentication. Requiring MFA is going to break a lot of these applications.

    • After tracking down the original post [microsoft.com] by Microsoft, I see that this will NOT break the applications I referred to.

      From the post...

      "Starting October 1st, we will start to randomly select tenants and disable basic authentication access for MAPI, RPC, Offline Address Book (OAB), Exchange Web Services (EWS), POP, IMAP, Exchange ActiveSync (EAS), and Remote PowerShell. We will post a message to the Message Center 7 days prior, and we will post Service Health Dashboard notifications to each tenant on the day of t

      • No, it won't break SMTP sending. But it will break automated applications that *read* these notifications via IMAP Basic Authentication.

      • Actually if you are not actively using SMTP AUTH it will be disabled according to: https://learn.microsoft.com/en... [microsoft.com] Additionally in the link you referenced a comment from a Microsoft employee stated: SMTP will continue to function normally as long as: you have SMTP auth enabled either at the tenant level or mailbox level, you don't have security defaults enabled, or MFA enabled for those mailboxes using SMTP auth. So their are instances where things could break unless you take action to prevent it.

    • These types of email apps are a security risk and need an update. It is precisely these types of applications that open up security holes in many companies' infrastructure.

  • as long as I never ever lose my phone.

  • If MS were smart, they'd have a fee they'd gradually crank up over time after the "retirement" date: a legacy fee. It has 2 benefits. First, MS gets a nice revenue stream, second, businesses don't feel the pressure of a hard-edge cut-off date. Sure, they'll grumble about the legacy fee, but it usually "feels" softer than a solid deadline. It's like the parable of the boiling frog.

  • So, after October 1, I should not see dozens of Microsoft servers trying to hack my system with Microsoft users forwarding mail through Microsoft systems to send spam with fake Microsoft system links?

    That will be interesting.

  • This open source project -- an OAuth2 email proxy -- may be useful to those impacted by this change:

    https://github.com/simonrob/em... [github.com]

    It adds a OAuth2 proxy service that lets code that (say) only supports IMAP to still talk to Office365 online email accounts. On one side, it offers Basic Authentication, and on the other side, OAuth authentication to Office365.

    The Microsoft announcement and followon discussion:

    https://techcommunity.microsof... [microsoft.com]

  • Vendor lock-in (Score:5, Insightful)

    by thelancelot ( 7067951 ) on Tuesday September 27, 2022 @06:44PM (#62919275)
    This is another case where the large companies like Google and Microsoft are creating more vendor lock-in. What this is going to do is break existing email clients, scripts, and migration tools which use basic IMAP/POP connection methods to manipulate or move emails. Instead they want you to use their own specific API's, clients (web based, GMail, Outlook) and more complex browser based authentication methods for token exchange and management. They say the old method is insecure because of encryption and 2FA, but both of those are supported using basic authentication if done properly. Hackers are already finding ways using proxies to hack the MFA token exchange method: https://www.zdnet.com/article/... [zdnet.com] If you use encrypted (SSL/TLS) based basic authentication with 2FA, it can be nearly as secure as what they are forcing. The one advantage it does have is that you can provide a token per client, and only revoke access to that specific client, where with basic authentication changing the password would remove access from all clients. Of course is this one feature worth completely breaking decades of old software and scripts by eliminating the old connection method? I think this is the first step of deprecation for Google and Microsoft and wouldn't be surprised if in the near future they didn't eventually force OAuth for SMTP and then eliminate the use of IMAP and POP for email access on their services. If you want more information about this situation and a email provider that values supporting open legacy environments then I would suggest checking out this post: https://www.imageway.com/2022/... [imageway.com]

    • Re: (Score:2)

      by ei4anb ( 625481 )
      OAuth2 and OpenID Connect are published standards. Office 365 still supports IMAP and SMTP. Yes, MS does recommend using their Graph API but that's not forced. Basic Auth is not secure because, if stolen, the password can be used to access other services. If the OAuth2 token were stolen then it can only be used to access email and it has a limited lifetime.
      • Not completely true. If the Basic Auth password is stolen and that password is only for an email account, then it can only be used to access email just like a OAuth2 token. What you are saying is only true if the same password you use for your email is used elsewhere, which is a big no no. You could say users won't do that, then you have the option to force application passwords which will allow you to make forced unique passwords to use used on a per app basis. Limited lifetime? Most have issues with long
  • '"we've seen these problems for years" said Todd McKinnon'

    We'll sell you a shït authentication system and then charge you more to fix it.

  • It has been industry standard since the inception of passwords that users create their own passwords, and no matter how you repeat that they must not do so, they re-use passwords. The solution is simple. Don't let users create passwords. The website/service should generate a password for you. That would solve 90% of the current security issues with passwords.

    • By "solve" you mean it would force the users to all write them down on post-it notes or use a password manager with a single master password. Whether that is considered better or not is likely to draw some enthusiastic responses.
      • He is correct, the real problem is users tend to create easily guessable passwords that get reused in multiple locations. Even OAuth2 requires you to login to a webpage with a password to obtain a unique token to be used by the client. This alone means a password is still required as part of MFA. You are correct in saying the only possible way to easily manage unique complex passwords is to use a password manager to store them with a single master password that is easy for the user to remember which is sto

  • Any excuse for vendor lockin (Score:3)

    by WaffleMonster ( 969671 ) on Tuesday September 27, 2022 @08:26PM (#62919453)

    Remember about a year ago signing up for a teams account and could not believe it was impossible to configure basic things like an email address nor was there not even any way to hide the BS email address displayed. Your options are basically go all in with MS or they will fuck you over every way possible. This is simply more of the same in the name of security for your own sake.

    The primary issue with present day systems is lack of SAS and secure authentication. The failures reflect Microsoft's continuous multi-decades total failure to adopt secure authentication procedures and technologies not the inherent shortcomings of passwords. They don't care and are not even trying.

    All MFA schemes subject to trivial authenticator impersonation are worthless against phishing the single largest security threat corporations face. They know it, everyone knows it yet it is allowed to persist. They simply don't care.

    In case there were any doubts about motives:

    "Certificate-based authentication is still legacy authentication and as such will be blocked by Azure AD conditional access policies that block legacy authentication. "

    So the secure MFA solution immune to authenticator impersonation (and interoperable with non-MS clients) gets disabled while the insecure MFA solutions worthless against authenticator impersonation are allowed to persist. This all makes a heck of a lot of sense.

    The statistics about what is and is not being compromised are temporary blips that fail to consider the inevitable and obvious reaction of thinking human adversaries. It's like deploying a new spam filter that matches 90% of all spam and thinking you've accomplished something. Really what happens a few weeks later your thinking human adversaries adapt and your efforts are wasted. Unless there is a credible and competent technological hurdle involved nothing is being accomplished all you are doing is rearranging deck chairs.

  • What I find extremely curious is that Gmail, one of the biggest webmail providers and direct competitor to MS Office Online, still does not support OAuth for retrieving mail from third parties, despite literally years of being asked by many users. This means soon one won't be able to use Gmail as single point of contact for multiple accounts that include an Office one. Which absolutely sucks...

Slashdot Top Deals

Real Programmers think better when playing Adventure or Rogue.

Close