Microsoft delays disabling Basic Authentication for several Exchange Online protocols 'until further notice' Microsoft has shifted gears on plans to disable Basic Authentication for five Exchange Online protocols this year, provided your tenant is actually using them. It's a change from previous proclamations on the issue and is in recognition of the fact that some IT admins simply haven't got round to dealing with the problem yet. …
There's an awful lot of automated mailing stuff in apps here there and everywhere that use basic SMTP for sending out emails. e.g. lots of commercial products that send customers automatic progress emails when an event happens e.g. order taken, order shipped etc.
That legacy codebase needs SMTP servers that just happily do basic auth
In which case, I would suggest running an on-premise relay server - you can roll your own via Linux/BSD or purchase one of the many SMTP relays that offer AV scanning and other security/compliance features.
The real story behind this is the amount of technical debt many enterprises have that is preventing the use of modern authentication. pre-2013 Office or Skype? pre-Windows 2012 R2 ADFS? Pre-Windows 2012R2 DC's?
The problem is that "modern authentication" is not a standard, although it uses a few standard protocols. Also the authentication token that is received afterwards need to be renewed regularly, which is also not a standard. And then how would you be able to use this with POP3 or IMAP?
If they were to disable basic authentication then you could only connect products to Office 365 that explicitly support it.
The servicedesk application we are using for example supports POP3/IMAP but not the Microsoft proprietary implementation.
The only solution I could personally come up with was to forward all mail to our own server and then fetch the mail with IMAP from there.
The following statement also indicates the issue:
"We have worked for nearly two years to push our app developers both internal and external to modern auth. We've put in a tremendous amount of work"
Microsoft spinned the change as a simple security improvement, but in reality a lot of stuff needs to be done only to implement support for Office365. If Gmail where to do the same, it wouldn't even be compatible and you'd need to put in the same amount of work for every provider you'd want to support.
So... all of a sudden your email (possibly automated) stops working unless you log into a browser and tweak the password your automated systems are using on a frequent basis?
This sounds *terribly* impractical.
Fortunately, it's not actually quite that bad: if it works like other oauth2 implementations, you can get new tokens via a fairly simple curl call, i.e. automatically. You don't need a full web browser, JavaScript or any of that crap (but then again since you can do this automatically I'm not sure what actual security it brings). It's just that every single client needs changing, and with some, like getmail, not even up to migrating away from Python 2, this might be a fairly long wait for the "long tail". And I bet a bunch of MS's own employees are using said long tail of clients... hence the stay of execution.
The problem with moving to something new, is that there are many things in play that won't work with it.
Which is why the delay.
So, what is basic auth?
While BA could mean submitting your credential over an unencrypted connection, usually, this is not the case.
The problem is that long accepted industry standards allow for encrypted auth using a username and password. For example, just about any https web site where you enter data you'd rather people not see. It's deemed "ok", because the connection is encrypted.
So, what's the problem?
Obviously there are some sites that allow people to hammer attempts without restriction (even Microsoft). So, in theory, somebody could brute force a login after trying many times (since Internet services are involved, there's latency, so this could actually take many many years to brute force, even an 8 character password).
The other problem, and this is actually bigger, is how the end point is using/storing your data. A lot of data exposure happens as those service providers get compromised (happens all the time).
But, again, overall, the reason why encrypted tunneling of personal id info is allowed, is because the world still depends on it... a lot. And some protocols are even weaker B2B (even bank to bank, for example, or medical provider to medical provider). That is, there's a ton of even lower hanging exploitable stuff out there.
Extra.... Microsoft believes that it, and it alone, owns all email world wide. And they don't want to support non-Microsoft clients (if possible). They believe this, and want this to be so true. So with that said, an even bigger security problem is when you place all your trust, all your business, everything... in the hands of a singular player with a not so great track record when it comes to security. Just something to think about.
Which don't work with all sorts of legacy software and devices that email errors/warnings, etc.
I gave up on outlook.com email as they broke POP/IMAP recently probably for this reason (dicking about with password authentication methods). Really, if you have a secured link as practically all clients support, or you use a VPN (so open port 25 test is safe) then the issue is underlying pisspoor password policy (UPPP if you want).
Christ, I ended up moving some stuff over to Yahoo of all places for a free email backup as they decided to improve security by requiring you to use a "token" which is just a fixed machine generated password of decent entropy instead of someone reusing pass12345 as they do on all other sites. Just how hard would it be for MS to do the same to deal with UPPP?
Here’s the problem this largely solves: User stupidity.
Modern authentication allows IT sysadmins (like me) to use pluggable authentication methods which tap into the security features devices already provide to stop users from compromising their own email accounts on the regular. Things like using SSO to skip interactive login altogether while VPNed in, while also requiring the use of a security token or mobile app as 2FA.
For legacy backend infrastructure, the solution is simple. Intelligent SMTP relay from inside the corporate network. The legacy stuff routes email to my own SMTP server using the most secure options it supports, then my server uses modern authentication to pass the message on. Alternatively, one can set up connectors on Exchange Online to remove the need for authentication passing entirely if we are talking about scan-to-email.
Intelligent SMTP relay:
- able to send upstream with all supported encryption/authentication methods
- anything can send internally via the relay IFF it authenticates using company IDAM
- white-list any applications/devices that can't authenticate to document what you need to fix in the future
- queue monitoring so you know when there is an upstream issue
- optional: AV scanning
- optional: content scanning for DLP
- optional: content rewrite/company signatures etc
- optional: load balance for resilience depending on your organisations requirements
This can all be done on a Linux box via how-to guides or there are a number of of-the-shelf products that provide this functionality. Or if you are happy to spend the money on it, Exchange with any required add-ons to get the optional features.
I accept that many may see this is vanilla SMTP relaying within their organisation but those that are unable to support modern authentication probably don't.
Microsith don't get to set internet standards, only the IETF can do that (although MS are welcome to participate). It's not for them to dream up proprietary solutions partly designed to lock-out non-MS mail clients and back end mail services. If more secure authentication protocols are needed, they should be designed as an open internet standard.
At work, we have a lot of people wedded to Thunderbird (although I eventually switched to Evolution, as trying to access Office 365 calendars from Thunderbird became too awkward, requiring ever-changing add-ons (a project that the Thunderbird org should really do some more work on in-house, although the fault of course lies with MS's opaque non-standard calendar system)), and, even more so, a hardy bunch whose fingers are firmly clenched around Alpine, which I imagine would really struggle with any change to login processes...
All the tech companies are at it, its less about standardisation, and more about strategic manoeuvring.
Wasn’t it recently ‘do no evil’ google wanted to start pushing its weight around with ‘critical FLOSS’
I dont know about others, but my opinion of tech companies has severely gone down hill in recent years
Do these companies attract sociopaths like shit does with flies?
> Microsith don't get to set internet standards, only the IETF can do that
W3C would like a word.
Anyone can set a "standard", the question is whether anyone will follow that standard. (National standards bodies and ISO are different: based on statute and inter-governmental treaties.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
