Ja lekker handig als je applicaties hebt (ik bedoel geen "apps" maar losstaande applicaties op andermans servers) die
het open standaard IMAP protocol gebruiken om mailboxen leeg te lepelen.
Die worden dan verplicht om proprietary Microsoft API's te gebruiken... en als 2nd factor verplicht wordt dan is zelfs
dat niet mogelijk.

"...wat inhoudt dat er geen gebruik meer kan worden gemaakt van protocollen zoals POP, IMAP en SMTP AUTH. "

Dat is zowat het enigste dat ik heb in m'n mailapplicaties als ik naar hotmail.com (exchange) connect. Benieuwd welke alternatieven komend jaar naar voren gaan komen. Voor SMTP heb ik nog nooit iets anders gezien.

Ach dat domme microsoft, waren zij niet een van de eerste die het email adres gingen gebruiken om je aan te melden ipv een login account. Om vele jaren daarna weer terug te keren naar een 2FA, maar dan natuurlijk wel weer iets dat meer gegevens van je registreerd, zoals een telefoonnummer of ander email adres.

Laat Microsoft eerst ASAP wat doen aan het (grotendeels legacy) Exchange Autodiscover protocol, o.a. gebruikt door Outlook.

Dat is zo lek als een mandje (o.a. door de http redirect die by default mogelijk is) waar niet alleen ik Microsoft in 2017 voor waarschuwde. Zie mijn bijdrage van afgelopen nacht: https://www.security.nl/posting/721881/Microsoft+Exchange+lekt+via+Autodiscover-bug+inloggegevens+Windows-domeinen#posting722007.

Schrappen van basic authentication helpt onvoldoende als in plaats daarvan zwakke NTLM hashes naar kwaadaardige servers worden gestuurd en/of als een kwaadaardige server als MitM tussen de client en de bedoelde server al het onversleutelde verkeer kan afluisteren en desgewenst wijzigen.

Het probleem hier zijn niet wachtwoorden, maar het niet verhinderen dat clients inloggen op een andere server dan bedoeld, met gemakzucht als reden:
Bron: https://docs.microsoft.com/en-us/Exchange/architecture/client-access/autodiscover?view=exchserver-2019

Daar gaat mijn secure IMAP. Microsoft en open standaarden. Het gaat nooit wat worden. Te arrogant.
Een mooi moment om over te stappen op wat anders. Er wordt hier toch al steen en been geklaagd over de gebruiksvriendelijkheid van outlook. Men gebruikt thuis Thunderbird en allerlei webclients.

Ze hebben het al een keer eerder geflikt om imap uit te zetten na een update. Nu wordt het dus officieel. Microsoft rules.

Vergeet Exchange. Te duur en te onveilg en je bent niet in control, maar de leverancier. Microsoft bepaalt dus stoppen ze ongevraagd met IMAP, SMTP etc. Heb je net dure Symantec Messaging Gateway's gekocht!
Hier wat open source alternatieven waar je wel in control bent en 90% kan bezuinigen op de kosten.
https://www.zimbra.com/
https://kopano.com/
https://www.cyrusimap.org/
https://www.sogo.nu/
https://www.dovecot.org/
https://kolabnow.com/

Verstandig, om 1 van de core applicaties binnen een bedrijf te vervangen voor zomaar wat software waar je alles maar zelf aan elkaar mag knutselen.
Daarom zie je dit soort genoemde software ook eigenlijk bijna nooit bij grote bedrijven die professioneel IT gebruiken.

Ofwel niet erg verstandig.... Maar de meeste begrijpen dit gelukkig gewoon.

Dit is een goede zet.

Het is sowieso geen goed idee om je username/wachtwoord in te geven en op te slaan in een applicatie, zeker als het gaat om online services.
Je denkt/hoopt dat deze enkel gebruikt worden voor imap, o.i.d., maar eigenlijk kan je dat niet garanderen.
Een app met jouw username/wachtwoord heeft alle toegang die ook jij zelf hebt en kan dus jou imiteren.
Als je credentials verkeerdelijk gebruikt worden of elders terecht komen ben je de pineut. (En dat is exact wat er vandaag gebeurt als wachtwoorden gelekt worden.)

Vandaag zijn er al allerlei alternatieven, die open standaarden zijn en helemaal geen proprietary Microsoft protocollen. (Vb: SAML, OIDC, OAUTH 2.0) Deze vallen onder de noemer "modern authentication".

i.p.v. Een username/wachtwoord in te geven in je app, krijgt deze een API key. Deze key heeft enkel en alleen de rechten om bijvoorbeeld e-mail te lezen en te sturen.
Op die manier krijgt iedere app een eigen API key (belangrijk voor monitoring) en zeer gerichte rechten (belangrijk om misbruik tegen te gaan).
(Ook lost het tal van problemen op als je bijvoorbeeld je wachtwoord ooit wijzigt.)

In deze vorm van authenticatie is er wel een centrale Identity/authentication provider nodig (IdP), en het is Microsoft er natuurlijk om te doen om deze te worden. (Net zoals Google, Apple, Facebook, etc... dan zijn in hun ecosysteem.)
De meeste (grote) bedrijven zetten hun eigen IdP op voor hun werknemers.

Met dergelijke protocollen is het bijvoorbeeld mogelijk dat een applicatie bepaalde rechten "vraagt" en je als gebruiker hiervoor al dan niet toestemming dient te geven. Ook kunnen API keys een beperkte geldigheidsduur hebben zodat er om de zoveel tijd opnieuw een authenticatie of MFA gevraagd zal worden zodat een app niet oneindig lang toegang heeft.
M.a.w., de gebruiker (of admin) is in controle en weet steeds welke app toegang heeft tot welke data.

Dus dit is een goed ding.

Idealiter zou je enkel en alleen je wachtwoord moeten opgeven in een centrale IdP die je vertrouwt en alle authenticatie en authorisatie gebeurt dan via deze centrale IdP.

verstandig om je core buisness door MS te laten beinvloeden die IMAPS/SMTPS uit willen zetten ?

Je hebt duidelijk niet begrepen waar ik het over had.
Wat ik bedoel is dat je een bedrijf bent wat naast de vele persoonlijke mailboxen ook wat specifieke mailboxen heeft
waar een verwerking achter hangt. Bijvoorbeeld een mailbox waar je een serviceverzoek heen kunt sturen of een
factuur. Er is dan een applicatie ergens die deze mailbox uitleest en de mailtjes verwerkt, dwz er een ticket van
maakt of de factuur registreert in het financiele systeem.
Dit soort applicaties gebruikt vaak IMAP omdat dit leverancier-onafhankelijke toegang tot een mailbox geeft.
Er zijn er wel die ook Microsoft specifieke API's ondersteunen maar lang niet allemaal en lang niet in alle versies.
(bijv om dit te kunnen moet je eerst upgraden naar een enterprise versie)

Dit heeft dus niks te maken met "je credentials weggeven" ofzo. Het gaat alleen over de credentials van die ene
mailbox en die is normaalgesproken altijd bijna leeg.

Zijn ze nou helemaal gek geworden daar bij Microsoft? Ik gebruik alleen maar IMAP om vanaf Linux bij mijn Microsoft e-mailaccounts te komen! En IMAP voor alle niet-Microsoft accounts, maar dat staat er los van. Hoezo zou IMAP een verouderd protocol zijn? Of onveilig? Totale onzin die de aandacht moet afleiden van problemen met juist Microsoft software en protocollen. Ik ga mijn Microsoft e-mailaccounts maar opzeggen want ik kan er zo te horen straks toch niet meer normaal bij.

Ze zijn niet gek geworden. De troep van open protocollen met de vele pleister door de vele lekken mag beste eens goed aangepakt worden. Je moet ergens beginnen. Wat je aangeeft is dat een ontwerp met veiligheid niet van de open source gemeenschap te verwachten is. Volvo was ooit een voorloper in veiligheid met auto's, dat kon geen enkele autohobbyist zelf. IBM had ooit de voortrekkersrol, dat is verleden tijd. Ook het opkopen ven Redhat veranderd daar niets aan.

Wat ik bedoel is dat een username/wachtwoord combinatie voor authenticatie enkel bedoelt is voor menselijke toegang.
Het wachtwoord wordt door een persoon ingegeven indien dat nodig is, niet door software.

Vanaf het moment je een applicatieve toegang nodig hebt, is het natuurlijk zeer aanlokkelijk en makkelijk om je wachtwoord op te slaan in een config file o.i.d. van die applicatie, maar dat is niet de bedoeling want de confidentialiteit van je wachtwoorden kan niet meer gegarandeerd worden. (En dan heb je ook allerlei gevolgproblemen, zoals non-repudiation, etc...)
Helaas wordt dit veel toegepast omdat het zo makkelijk is, maar dit is eigenlijk een anti-security pattern omdat er geen enkele andere limitatie is. (Bij wachtwoord managers moet je bijvoorbeeld ook nog steeds eerst manueel authenticeren voordat je toegang hebt tot de opgeslagen wachtwoorden.)

Voor applicatieve toegang is het beter om authenticatie en authorisatie via API keys te doen. Dit is altijd al zo geweest, en het enige wat Microsoft nu doet is de "verkeerde manier van werken" niet meer toe te laten.

Er is geen enkele reden waarom IMAP/POP3/SMTP toegang niet via een modern authenticatie protocol zou kunnen gebeuren: https://docs.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth

Nogmaals, dit is geen Microsoft protocol, maar een open authenticatie/authorisatie standaard geschikt voor het moderne internet waarbij "software" toegang heeft tot data en niet "mensen".
Username/wachtwoord combinaties gebruiken zodat applicaties toegang tot data hebben is nooit een goed idee geweest, maar stamt nog uit de "early days" toen er nog niet anders bestond. Deze "nieuwe" standaarden zijn inmiddels ook al bijna 20 jaar oud, trouwens.

Het wordt steeds de gekker. De problemen met Microsoft echange software wordt afgewenteld op de open standaarden. Haha wat een zielige vertoning. Tijd op exchange echt te skippen voordat er nog meer economische schade ontstaat.

Hahahaha! Afgerond 100% van de lekken betreft Microsoft software en alleen Microsoft heeft 'problemen' met open source. Natuurlijk, want de superioriteit van bedrijven die open source software gebruiken (zoals Google) wordt met de dag duidelijker. Bovendien gebruikt Microsoft zelf stiekem open source voor haar eigen systemen maar houdt dat liefst zoveel mogelijk stil omdat ze minder geld zou kunnen verdienen aan haar klanten als die dat ook zouden gaan doen.


Microsoft was ooit een voorloper maar dat gaat steeds sneller achteruit. Het begint een grote schertsvertoning te worden, met steeds meer problemen waarbij de 'oplossingen' nieuwe problemen veroorzaken. Typisch voor spaghetticode en een spaghetticodebouwwerk. Het gebruik van deze software voor lichte consumententoepassingen in professionele context kost bedrijven en instanties bergen geld!

Zie ook deze reactie: https://www.security.nl/posting/722126#posting722323

(Met name de verwijzing onderaan deze reactie, naar de resultaten van onderzoek van de ransomware-aanval op o.a. Veenendaalse zorggroep Charim is interessant en relevant)

Het gaat om 'basic auth', dus gaat het niet over secure auth,
is wat ik hier uit opmaak.

En voor de eeuwige discussies;
... Apple sucks, M$ sucks,
All companies suck +all customers included.