Microsoft stopt op 16 september met Basic Auth-protocol voor Outlook-gebruikers

Microsoft stopt op 16 september met de ondersteuning voor het Basic Authentication-protocol bij persoonlijke Outlook-, Hotmail- en Live.com-accounts. Vanaf dat moment kan er enkel ingelogd worden via apps of websites die het veiligere Modern Authentication-protocol ondersteunen.

Basic Authentication maakte het volgens Microsoft eenvoudig voor kwaadwillenden om gebruikersnamen en wachtwoorden te onderscheppen. Via dit protocol hoefden Outlook-, Hotmail- en Live.com-gebruikers enkel hun gebruikersnaam en wachtwoord op te geven om in te loggen. Het Modern Authentication-protocol zou veiliger zijn en maakt gebruik van extra backendprocessen en tokens. Die moeten voor een veiligere webomgeving zorgen.

Outlook-, Hotmail- en Live.com-gebruikers die na 16 september willen inloggen op een website of applicatie zonder ondersteuning voor Modern Authentication, zullen daar niet meer in slagen. Populaire mailapps zoals Outlook, Apple Mail en Thunderbird ondersteunen volgens Microsoft al het nieuwe protocol.

Reacties (86)

[vanaalten]

Hmmm, hier heb ik een vraag over:
Ik haal nu automatisch eens per uur m'n Hotmail post op met Fetchmail. Wat op zich neerkomt op POP3 username/password inloggen op outlook.office365.com via een SSL beveiligde verbinding.

Ik kan het niet helemaal uit dit of het bronartikel halen, maar het klinkt alsof dit dan ook stopt met werken. Of zie ik dat verkeerd?

[[Yellow]]

Yep, Modern Authentication betekent OAuth2 en dus moet er iets veranderen aan Fetchmail.
Op zakelijke accounts die ik gebruik staat dit al langer aan.
De maintainer van Fetchmail weigert OAuth2 te implementeren dus moet je op zoek gaan naar andere oplossingen. Gelukkig zijn die er en werkt deze ook goed: https://github.com/simonrob/email-oauth2-proxy

Je laat de authenticatie in feite over aan deze proxy en verbindt Fetchmail via localhost hiermee. Fetchmail verbindt dan naar localhost:1993 (met sslproto '') et voilà.

[HollowGamer]

Waarom weigert hij dit te implementeren? Niet om hem in een kwaad daglicht te stellen, ik ben niet bekend met hoe complex het protocol is.

[CAPSLOCK2000]

De auteur maakt verschillende bezwaren maar volgens mij is de kern een machtstrijd met Google en Microsoft. Om OAuth2 support te mogen hebben in je applicatie moet je de applicatie bij Google en Microsoft registreren of je organisatie te vragen zelf een uitzondering te maken en die applicatie te registreren. Uitzonderingen zijn altijd lastig en gedoe voor de gebruikers, dus eigenlijk is zo'n registratie noodzakelijk.

Dat betekent dus ook dat die daar voorwaarden aan kunnen stellen of de registratie opheffen waarna de applicatie niet meer werkt. De auteur vreest speelbal te worden van deze partijen die te pas en te onpas dingen kunnen veranderen. Zo is het geen echte standaard. De recente geschiedenis lijkt hem daar gelijk in te geven want de OAuth2 van MS en Google zijn nu al niet meer compatible en vragen eigen aanpassingen. Dat pas niet bij de Vrije Software filosofie.

Daar komt bij dat hij OAuth2 te complex (500 pagina's tekst) en foutgevoelig vindt en een beetje misleidend. Er wordt gezegd dat je met OAuth2 geen wachtwoord meer nodig heb maar dat klopt niet, dat is niet iets dat door het protocol wordt afgedwongen maar op een ander punt. Zelf vind ik dat niet het sterkste argument. Technisch gezien klopt dat wel maar er is meer aan de hand en het geeft geen goed beeld van de situatie. Toch is er wel wat voor te zeggen dat je bij OAuth2 nog steeds een hoop níet weet over de beveiliging waardoor het niet automatisch altijd beter is.

Ik proef ook nog wat frustatie dat MS geen gebruik heeft gemaakt van Kerberos. Een systeem dat precies hetzelfde kan, jarenlang door MS is gepushed en wel in fetchmail zit.

[Jeoh]

https://gitlab.com/fetchmail/fetchmail/-/issues/45

tl;dr: "Ik vind het niet nodig dus ga ik het niet implementeren"

[JackBol]

Zijn echte argument (staat in je link overigens) is:
1) Als de admin van je org OAuth afdwingt, moet je met ze praten. Want ze willen niet dat er unsanctioned software gebruikt wordt. Als ze dat wel toestaan kunnen ze ook een andere auth dan OAuth toestaan. (dit argument is nu wat zwakker omdat we het over webservices hebben)
2) De OAuth voor Outlook is een dialect en geen standaard. Als FOSS maintainer wil hij terug kunnen vallen op open gespec'te standaarden. Aangezien Outlook de MSAL (XOAuth library) gebruikt zal hij deze moeten reverse engineeren of iemand anders z'n code in zijn project moeten opnemen.
3) Hij ziet geen inherente waarde in Oauth voor 2FA en "passwordless", dus de gain minder dan de pain.

[vanaalten]

Ik krijg de indruk dat het wel degelijk geimplementeerd gaat worden, in Fetchmail 7.
Uit https://gitlab.com/fetchm.../blob/next/README.OAUTH2:

fetchmail 7 adds support for OAuth2

...maar zal nog wel even duren voordat dit in Debian 'stable' gaat komen, om maar een veelgebruikte Linux distro te noemen.

[CAPSLOCK2000]

Ik krijg de indruk dat het wel degelijk geimplementeerd gaat worden, in Fetchmail 7.
Uit https://gitlab.com/fetchm.../blob/next/README.OAUTH2:

Ja en nee. Als je die instructies leest zie je dat het niet echt van harte is en het slechts een matig bruikbare oplossing geeft.

Technisch gezien wordt het geimplementeerd, maar daarmee is het nog niet algemeen bruikbaar. Je moet namelijk aan MS en Google gaan vragen om je applicatie goed te keuren en daar wil de auteur niet aan beginnen. Hij wil geen toestemming moeten vragen om z'n eigen software te mogen gebruiken.

Zonder goedkeuring van MS en Google moeten gebruikers aan hun systeembeheerder vragen om zelf een uitzondering te maken om deze applicatie toe te staan. Ieder vorm van toestemming of uitzondering zal altijd wel ergens weerstand oproepen. Gezien het relatief gering aantal gebruikers van fetchmail zal bijna iedere gebruiker het zelf moeten gaan regelen.
MS en Google zelf zullen hun eigen applciaties natuurlijk altijd goed keuren, daar zijn geen uitzonderingen voor nodig.

[JackBol]

Technisch gezien wordt het geimplementeerd, maar daarmee is het nog niet algemeen bruikbaar. Je moet namelijk aan MS en Google gaan vragen om je applicatie goed te keuren en daar wil de auteur niet aan beginnen. Hij wil geen toestemming moeten vragen om z'n eigen software te mogen gebruiken.

Ik ben zelf een groot FOSS voorstander en heb niets met deze hyper-email leveranciers. Maar ik kan me niet vinden in dit statement. De MSFTs en GOOGs van deze wereld zullen een clientid en secret moeten generen voor hem als hij integratie met de hypermailers wil bieden. Dat MSFT en GOOG hier eisen aan stellen is niet mee dan normaal. Anders kan jan en alleman een clientid en secret onbeperkt aanvragen, wat een brute force aanval een stuk realistischer maakt.

[CAPSLOCK2000]

Dat MSFT en GOOG hier eisen aan stellen is niet mee dan normaal.

Normaal zou ik het niet willen noemen, dusver was het niet nodig, in ieder geval niet in deze sector.

Anders kan jan en alleman een clientid en secret onbeperkt aanvragen, wat een brute force aanval een stuk realistischer maakt.

Ik snap dat het zeker voordelen kan hebben dat MS & Google software controleren, maar er zijn ook nadelen waarvan een deel conflicteren met de Vrije Software filosofie.
De kern daarvan is immers dat de gebruiker de baas moet zijn over software en die zelf naar eigen inzicht moet kunnen gebruiken en veranderen, zonder dat een externe partij dat moet goedkeuren.

Dat gezegd hebbende zie ik niet echt hoe het helpt tegen brute force aanvallen. Als MS of Google de applicatie eenmaal heeft goedgekeurd kan iedereen die immers gewoon gebruiken zoals altijd. Een scriptje maken om deze applicatie een miljoen keer achter elkaar aan te roepen is heel eenvoudig, de applicatie leent zich goed voor automatisering. Wat dat betreft zie ik dus geen concreet voordeel. Als iemand misbruikt maakt kan MS/G alleen de hele applicatie kunnen blokkeren en daarmee ook alle legitieme gebruikers schaden. Dat is een beetje tegen het zere been van de Free Sofware filosofie.
Je hebt dus andere middelen nodig om te verdedigen tegen brute force aanvallen, zoals 2fa en rate-limiters. Precies wat we nu hebben.

[i-chat]

ik lees je claim dat jet tot dusver ook niet nodig was

en dan houdt het eigenlijk wel op

30jaar ervaring met spam an mass bewijst je ongelijk

en het feit dat de msft en googs van deze wereld NU PAS met dit soort eenvoudig te nemen maatregelen komen is al een schande op zichzelf

[svennd]

oauth2 zal geen spammers tegen houden ... dit is puur consolidatie van eigen clients, onder het mom van security. Op z'n best is het 2 vliegen in één klap.

[Mijzelf]

Heb je die readme gelezen?

For Google: Create a project and request an OAuth2 client id and client secret
* Open the Google API Dashboard: https://console.developers.google.com/apis/dashboard
<50 regels instructies weggelaten>
For Microsoft: Register an App to Azure Active Directory and request an OAuth2 client id and client secret
* Open the Azure Cloud Portal: https://portal.azure.com
<'slechts' 22 regels weggelaten>

<snip fetchmail setup>
* Each access token expires after an hour.
* If you run fetchmail from cron, you should run `fetchmail-oauth2.py -c /home/yourname/.fetchmail-oauth2 --auto_refresh ; fetchmail`
* For example, `*/2 * * * * (fetchmail-oauth2.py -c /home/yourname/.fetchmail-oauth2 --auto_refresh ; fetchmail) > /home/yourname/fetchmail.log 2>&1`

Wanneer je internet verbinding er een uur uitligt, kun je je aantekeningen gaan opzoeken hoe je weer nieuwe tokens maakt.

[- peter -]

Daar heb je refresh tokens voor toch?

[air2]

Dan gebruikt ie de verkeerde oauth flow, de oauth service flow is voor service applicaties, en vereist een client secret of certificaat. Als je de client token flow gebruikt, ja dan moet je steeds blijven inloggen, die flow is bedoelt voor applicaties die user interactie hebben. Dit zie je heeel vaak fout geimplementeerd worden.

[xFeverr]

Nee hoor. Je access token vervalt inderdaad na een uur (bij ms) maar je hebt nog een refresh token waarmee je nieuwe access tokens kunt opvragen. En die is veel langer geldig.

[air2]

Het klopt dat de refresh token langer geldig is. Toch is deze flow niet bedoelt voor service applicaties.

De refresh token is eenmalig geldig, de access en refresh tokens krijg je enkel na een redirect op een get of post request. Ze zitten dan in de url. Het inloggen gebeurd op de webpagina van de aanbieder. Het is dus niet zo dat als je je refresh token gebruikt hebt maar er ging iets mis, dat de service applicatie eenvoudig een nieuwe kan achterhalen, dat kan alleen door in te loggen op de website van de aanbieder, dat is lastig te automatiseren voor een service applicatie. Die moet dan immers een pagina renderen (icm javascript etc) om daarna in te loggen om nieuwe tokens te krijgen.

Daarom is er de service workflow, met gedeelde secret of certificaat. DAT is de flow die backend applicaties dienen te gebruiken. Je moet zeker niet je refresh token willen opslaan in een backend applicatie. Dat slaat helemaal nergens op, maar soms bied een leverancier geen service flow aan en dan moet je wel. Maar anders gewoon de service flow gebruiken.

[xFeverr]

Ah juist, ik dacht dat het een client applicatie was waar het over ging. Maar dat is het dus niet.

Er is nog een andere optie: de device code flow. Daarmee krijg je een code waarmee je in een browser, desnoods op een ander apparaat, kan inloggen op https://microsoft.com/devicelogin en vervolgens krijgt de applicatie alsnog de ID-, access- en refreshtokens binnen. Dit gebruiken wij bijvoorbeeld ook bij bepaalde tools die geen browser kunnen tonen (CLI tool, IoT-device) en toch namens een gebruiker iets moeten uitvoeren. Sommige CLI-tools van Microsoft, zoals bijvoorbeeld AzCopy, gebruiken ook die methode.

De service flow die jij aangeeft is toch meer bedoeld voor applicaties die namens zichzelf/de service iets doen en niet namens een eindgebruiker? Want dat gaat dan niet werken met een tooltje dat mail voor jezelf ophaalt, waar de device code flow dat dan wel kan doen.

Wij gebruiken die genoemde service workflow zodat onze backends toegang krijgen tot de juiste databases, opslag en andere services, en dat namens hunzelf: backendapplicatie x of y.

[Reactie gewijzigd door xFeverr op 22 juli 2024 13:21]

[HollowGamer]

Dat is waar Debian voor staat. Dan kun je beter kiezen voor een andere distro.

[swhnld]

Omdat hij een mens is met een eigen mening. En ongeacht of hij gelijk heeft of niet in zijn keuzes, grote partijen trekken zich daar niets van aan en stellen hun eigen koers.
Resultaat is dat je of met plugins gaat werken, of over moet stappen op een andere oplossing.

Mijn persoonlijke mening, Microsoft geeft dit soort wijzigingen lang tevoren aan over het algemeen, dus als je het wil heb je voldoende tijd om dat aan te passen en te implementeren.

[_JGC_]

Uit de FAQ:

I9. How can I use fetchmail with GMail/Google Mail?
Google has started pushing towards more complex authentication schemes based on OAuth 2.0 that require clients and users to jump through quite a few hoops, and use web browsers for signing in. If this hinders access to your account through fetchmail, you may need to turn on access for "less secure apps" at https://myaccount.google.com/lesssecureapps.
It is disputable whether an application that does not include web browsing capabilities or heavy-weight libraries is "less secure" as Google claims.

Het idee van de ontwikkelaar is dat je een volledige browser in Fetchmail moet bouwen om OAuth2 te implementeren. Dat is idd hoe je het aan kunt vliegen, maar er zijn tegenwoordig ook libs als liboauth of liboauth2 die dat voor je kunnen doen.
Er is bijvoorbeeld een Onedrive client voor linux die helemaal geen extra dependencies heeft anders dan libcurl, die geeft je gewoon een linkje die je moet plakken in je browser, inloggen met je account bij MS en dan heeft Onedrive een geldig token die alleen periodiek ververst hoeft te worden.

Het verschil tussen naam+wachtwoord en een Oauth2 token is dat een token beperkte geldigheid heeft en beperkt is tot wat het moet doen. Als jij een token voor toegang tot je mail genereert kan iemand die een geldig token steelt en die op tijd inzet bij al je mail. Stelen ze naam+wachtwoord kunnen ze bij alle Microsoft diensten net zolang tot jij erachter komt en het wachtwoord wijzigt (wat je vaak niet meer kunt, want ze passen het aan en veranderen het backup mailadres, account ben je kwijt)

[Mijzelf]

Er is bijvoorbeeld een Onedrive client voor linux die helemaal geen extra dependencies heeft anders dan libcurl, die geeft je gewoon een linkje die je moet plakken in je browser, inloggen met je account bij MS en dan heeft Onedrive een geldig token die alleen periodiek ververst hoeft te worden.

Heb je daar een linkje van? En hoe vaak is 'periodiek'?

[_JGC_]

https://github.com/abraun...ster/src/onedrive.d#L1178

Het is bij OAuth2 gebruikelijk om een geldigheidsduur mee te geven aan een token. Je kunt met de oude token steeds weer een nieuwe aanvragen. Hoe vaak dat moet is compleet afhankelijk van de implementatie, dat wordt server-side bepaald.

[air2]

Nee (mwah, beetje nee, want je hebt zeker wel een punt),

De client flow verplicht idd om met refresh tokens te werken en is bedoelt voor websites (en dus een browser)
De server flow is gericht op backend applicaties, vereist een certificaat of client secret en werkt anders.

De backend partij kan beide, of 1 van de 2 implementeren. Als je als mail programma dat op de achtergrond werkt, wil verbinden zou je eigenlijk de service flow moeten implementeren.

[Digibouter]

Super. Wat is een goede methode om outlook-calendar gegevens te kopiëren naar google-calendar?

[Cyberpuppy]

Geen

[jeanj]

Als je outlook (de echte client) hebt, koppel beide agenda's, maak een list view van degene die je wilt kopiëren en ctrl a, ctrl-c, selecteer de andere agenda, ctrl-v

zelf tussen ander mail systemen gedaan, maar het zou hetzelfde moeten werken voor jou

[Reactie gewijzigd door jeanj op 22 juli 2024 13:21]

[vanaalten]

Ah... binnenkort maar eens opzetten dan. Dank voor de uitleg & link!

[Scriptkid]

en daarmee verplaats je het beveiliging risico van de ene naar de andere locatie dus niet heel erg slim,

Je kunt dan beter overstappen naar iets wat volledig e2e pop3 modernauth of graph of outlook protocol snapt.

Er is een hele grote reden waarom we basic auth dicht zetten.

[the_stickie]

Als je het risico van publiek internet naar local host kan beperken , is er wel degelijk een serieuze winst op vlak van beveiliging. Met deze oplossing verlaat het wachtwoord je eigen computer nooit - dat is al heel wat!

[[Yellow]]

Er is ook een hele grote reden waarom je Fetchmail draait: al je email van al je accounts op 1 locatie aggregeren.
Dat kan niet op een andere manier helaas. (Tenzij je mail gaat forwarden).

Ik besef dat het dichtzetten van basic auth probeert te voorkomen dat je secrets ergens op moet slaan, maar dat zul je uiteindelijk toch ergens moeten doen. Juist om dit probleem te ondervangen waren app-passwords ooit bedacht maar die worden nu bij Microsoft uitgefaseerd!

Mijn grote bezwaar tegen dit soort 'want beveiliging' drogredenen is dat het resultaat is dat Microsoft dwingend op kan leggen hoe je de dienst gebruikt. En dat is ook precies de reden dat Fetchmail dit weigert te implementeren.

[Scriptkid]

Dat kan niet op een andere manier helaas

Power Automate ?

PowerShell ?

Any script langauge in a azure function ?

genoeg te verzinnen. Daarnaast moet je van POP en IMAP juist weg gaan dat zijn 30 jaar oude protocols met allerlei isseus in de moderne wereld

[Reactie gewijzigd door Scriptkid op 22 juli 2024 13:21]

[[Yellow]]

Tsja....En waar sla je de via PowerXXX opgehaalde mails dan op?
En hoe haal je ze, op een standaard manier, weer op in alle OSsen (Linux,Android,iOS,Windows,etc,etc)?

En welke issues met IMAP zijn er dan? Ik zie ze niet?

Als er al nieuwere standaarden zijn om email te lezen, dan zijn ze in ieder geval in geen enkel (oud en modern) OS geïmplementeerd.

[Reactie gewijzigd door [Yellow] op 22 juli 2024 13:21]

[Scriptkid]

email in HTTP is een API,

Hoe jij ze leest en waar jij ze opslaat en of wellke client jij gebruikt moet je zelf weten, het is platte data,

jij wilt alles consolideren in 1 data store dat moet je ook bepalen welke store dat is dat zouden zelfs txt files kunnen zijn.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 13:21]

[Xinnix72]

En omgekeerd, heb je daar een goede - liefst gratis - oplossing voor ? Een exchange 2010 server die zich moet kunnen connecteren via smtp met starttls. Liefst dus een smarthost die al dan niet lokaal geïnstalleerd wordt. Op dit moment worden 2 popmailboxen opgehaald en in een exchange mailbox gestoken, en wordt er mail gestuurd via de smtp van de provider ( smarthost ), maar die vereist nu starttls.

[TheMak]

Een ander vraagje. Ik heb ooit een 🆎 nnement afgesloten met outlook.com account. Kom ik er nog wel in met accountnaam en wachtwoord uit schriftje als ik al mijn apparatuur met tokens vervangen heb?

[dezejongeman]

wat ik mis in het artikel is, wat beide modellen zijn en waarom basic zoveel onveiliger is. nu kan ik natuurlijk google, copilotten, geminien of dergelijke. maar toch. het artikel is niet echt af zo.

[DonJunior]

Dit! Zelfs als niet digibeet heb ik geen idee wat het nu precies voor consequenties heeft.
Kan ik gewoon via de browser blijven inloggen, ik gebruik sowieso al MFA maar staat dat hier los van of juist niet? @JayStout Zou je hier wat meer uitleg kunnen geven?

[Reactie gewijzigd door DonJunior op 22 juli 2024 13:21]

[bhartman]

Uit het gelinkte artikel:

This means that after 2024 customers will need to run the latest versions of a supported browser to run Outlook.com.

Browser Minimum requirements to run Outlook.com:
Microsoft Edge (version 79 or later)
Chrome (version 79 or later)
Firefox (78 or later)
Safari (version 16 or later)
Opera (76 or later)
Operating System Minimum Requirements:
Windows OS: Windows 11, Windows 10, Windows Server 2022, Windows Server 2019, or Windows Server 2016
macOS: macOS Sonoma, macOS Ventura, and macOS Monterey
Linux: Outlook.com works in both Firefox and Chrome on Linux

[[Yellow]]

Basic Auth is een HTTP authenticatie en heeft dus alleen betrekking op inloggen via de browser. Dat kan nog steeds alleen moet je je browser met een OAuth2 token aan laten melden (en dus registreren als client in je Exchange server). Sterker nog, je hebt vrijwel altijd een browser nodig om een OAuth2 token aan te maken aangezien je de client goed moet keuren.

MFA staat los van Basic Auth maar valt onder wat Microsoft noemt 'Modern Authentication' en is in feite OAuth2. Ze gebruiken daar een andere term voor om het ons allemaal makkelijker te maken...

[Cergorach]

MS en naamgeving is altijd al heel problematisch geweest!

[SuperDre]

Uhh, nee dus, is niet alleen voor inloggen via webbrowser, maar is een basis methode om te authenticeren via http(s), en dat is dus vaak bij gebruik van webservice/webapi's.

[SunnieNL]

Je zou gewoon op het linkje naar het bron artikel kunnen klikken.
Denk niet dat het nut heeft dat Tweakers het hele bericht vertaald en dan hier plaatst.
Maar kort gezegd, als je MFA gebruikt, gebruik je het moderne protocol al. Basic auth is alleen gebruikersnaam en wachtwoord.

Wat niet goed in het artikel van Microsoft zelf staat is dat app passwords ook stoppen met werken (want geen MFA). Eigenlijk schakelt Microsoft alle mogelijkheden uit om zonder MFA nog in te loggen bij Outlook/hotmail. Dus ook de mail/calendar apps van Windows 10 kunnen niet meer gebruikt worden.

[SwerveShot]

Wat niet goed in het artikel van Microsoft zelf staat is dat app passwords ook stoppen met werken

Goede toevoeging. Dat vroeg ik me namelijk ook al af.

[William_H]

Volgens mij is dat wat betreft die app passwords niet waar. Dat is ook gewoon een token en kun je alleen aanmaken als je bent ingelogd in je account op Outlook.com

[SunnieNL]

in het originele artikel in de comments wordt het bevestigd. de app passwords zijn er juist gekomen om applicaties die de moderne methode niet ondersteunen wel een veilig wachtwoord te geven terwijl je zelf moderne authenticatie blijft gebruiken.
Dat je alleen kan aanmaken na inloggen maakt het niet een token. Het app wachtwoord wordt aan je account gekoppeld en daarom moet je inloggen.

[William_H]

Dus dat zou dan betekenen dat app-passwords niet meer werken.
Dan gaan een flink aantal mensen een probleem ervaren.

[SunnieNL]

ik gebruik app passwords niet voor email, alleen nog voor de x360.
ik denk niet dat veel mensen ze
voor email gebruiken eigenlijk.

[William_H]

Hieronder schreef ik het al, ik toevallig voor een app die niet werkt op een andere manier met de nieuwe authenticatie van MS. Wat zo gek is, is dat ik er met Google geen problemen mee heeft, en die gebruikt ook Auth2, maar heeft dat blijkbaar anders geïmplementeerd.

[Z-Dragon]

Als je via de browser werkt (webmail), heeft het geen consequenties. Verder kunnen alle gangbare e‑mailprogramma's ermee overweg. In het slechtste geval moet je je accountinstellingen aanpassen. Volgens mij ondersteunt Microsoft geen MFA i.c.m. basisauthenticatie, dus als je dat gebruikt, zit het al goed.

[michelr]

Eens, beetje extra duiding kan geen kwaad. Het lijkt erop dat de auteur iets heeft opgepend wat ie zelf ook niet helemaal begreep met "maakt gebruik van extra backendprocessen en tokens".

[dooiedodo]

Vooral omdat authentication headers teveel zichtbaar zijn en makkelijker op te pakken daardoor. Modern Auth is mooie marketing naam voor (onderneer) Oauht2. Hier mee regel je toegang door tokens af te geven voor de juiste applicaties en kan je tokens intrekken zodat die niet meer gebruikt kan worden voor toegang.
De applicaties krijgen zelf het user en wachtwoord combinatie niet meer te zien, waardoor je credentials dus niet meer overal en nergens staan.

beter inzicht:
https://www.simplilearn.c...ntication%20headers%20can

[Reactie gewijzigd door dooiedodo op 22 juli 2024 13:21]

[Sijmen]

> door tokens af te geven voor de juiste applicaties

Dit lijkt me nogal een probleem voor vrije software. Moet elke distro, elke packager, elke zelf-compilerende eindgebruiker zich registeren bij MS en goedkeuring afwachten?

[Cergorach]

Tokens zijn trouwens ook niet heilig en maken het voor de normale gebruiker extra ondoorzichtig.

Effectief is de nieuwe methode dat je een tijdelijke toegangspas krijgt bij receptie zodra je daar je username/password+MFA gebruikt. Vervolgens kan je dus overal daarna naar binnen met die tijdelijke toegangspas waar die toegangspas toegang tot heeft. Natuurlijk kunnen aanvallers die toegangspas/token gewoon klonen onder de juiste omstandigheden. Dan kan je een prima ww en MFA aan hebben staan, maar men gaat met de token aan de haal. Alleen het ww veranderen is dan niet voldoende (de kans is dan wel gewoon dat de volgende stap automatisch gebeurd door het systeem), je moet ook de tokens 'intrekken' (effectief blokkeren).

Die tokens kan men dmv. hacken/malware direct van je device plukken of door ergens tussen te gaan zitten (op bv. een netwerk). En hier is bijzonder lastig tegen te verdedigen... Bij een bedrijf met een dedicated security afdeling zijn daar tenminste mensen mee bezig om dat zo goed mogelijk te beveiligen. Bij kleine bedrijfjes die 1 of 2 ITers rond hebben lopen, moet je hopen dat ze er genoeg van begrijpen, er genoeg aandacht aan besteden en de tijd er voor hebben om het te goed te implementeren. Bij consumenten... Oef!

[michelr]

Token theft is een ding maar minder dan credentials. Daarom hebben we token binding (device-gebonden), denk alleen niet dat je dit in een consumentenplatform als outlook.com snel terug gaat vinden (gezien je dan eisen gaat stellen aan client). Vooralsnog, baby steps.

[Reactie gewijzigd door michelr op 22 juli 2024 13:21]

[Cergorach]

Natuurlijk heeft MS daar weer een andere naam voor: Token protection (Conditional Access), zit nog in preview en is nog heel erg beperkt op het MS365 platform (hele specifieke client eisen, hele beperkte software coverage, etc.).

Bron:
https://learn.microsoft.c.../concept-token-protection

[William_H]

Maar dat gaat over enterprise toch. @michelr had het er over dat dat voor consumenten niet echt geregeld is, hoewel je bijv. wel alle app passwords kan intrekken in 1 keer.

[IStealYourGun]

In een nutshell, voor modern authentication moet je client OAuth 2.0 ondersteunen en dat kan gerust over pop3 of imap. Meeste moderne clients (o.a. Thunderbrid) ondersteunen dit. Maar als je werkt met een oude client van voor het jaar 2020, is de kans groot dat die niet overweg kan met modern authentication en gaat die na 16 september niet meer kunnen verbinden.

[lenwar]

Het 'oude/onveilige' model, is 'gebruikersnaam en wachtwoord'. Dit is dus een platte authenticatiemethode, waarin de gebruikersnaam en wachtwoord naar de server worden opgestuurd. (in het slechtste geval iedere keer als je je mail ophaalt). Afhankelijk van je instellingen kan dit versleuteld worden opgestuurd.
Je gebruikersnaam en wachtwoord staan dus ten allen tijdens ergens op je computer opgeslagen. Mogelijk versleuteld. Maar wel zodanig dat ze lokaal ontsleuteld kunnen worden. (anders kan je computer het niet opsturen ). Dit is niet 'per se' heel erg onveilig, maar je voelt dat het beter moet kunnen in deze tijden.


Disclaimer: Onderstaande is heel oppervlakkig verwoord en deels incompleet, maar voor de leesbaarheid en bredere begrijpbarheid verwoord ik het even zo:

De 'moderne authenticatie' is op basis van OAuth2. Bij het aanmelden met OAuth2 wordt er een token op je computer gezet waarmee vervolgens wordt ingelogd. De token wordt in combinatie met nog wat andere data van de installatie gebruikt om daadwerkelijk in te loggen (unieke ID's van bijvoorbeeld (het verschilt een beetje per toepassing) een uniek ID van je Computer/besturingssysteem/software-installatie/enz./een combinatie van voorgaanden). Daar bovenop wordt de token ook nog is eens in de zoveel tijd ververst.
De daadwerkelijk authenticatie is losjes gebaseerd op publiekesleutel-authenticatie.

Dit alles heeft dus primair als voordeel dat je 'wachtwoord' (je token-combinatie) dus nooit over de lijn gaat en hij eens in de zoveel tijd vervangen wordt.

Edit: @DonJunior Je zou het heel losjes MFA kunnen noemen, omdat je computer/installatie een deel wordt van de authenticatie (wanneer de token er eenmaal is). (De computer/installatie zelf is dan de tweede factor, maar het heeft niets te maken met zaken als TOTP/enz. Dat is wel echt heel anders.)

[Reactie gewijzigd door lenwar op 22 juli 2024 13:21]

[DonJunior]

Thanks voor de duidelijke uitleg!! Wordt gewaardeerd!

[Z-Dragon]

Met basisauthenticatie wordt bij elke actie (ophalen, verzenden, enz.) je wachtwoord meegestuurd. Daarom moet het op je computer worden opgeslagen, wat betekent dat het daar ook uit gevist kan worden. Wie het in handen krijgt, heeft onbeperkte toegang tot je account.

Met 'moderne' authenticatie (OAuth2) log je direct in bij Microsoft zelf, en krijg je er een soort ticket (token) voor terug. Dat is om te beginnen gebonden aan de software waarvoor het bestemd is, geeft rechten op maat, en kan op elk moment worden ingetrokken zonder je wachtwoord te hoeven veranderen.

[Reactie gewijzigd door Z-Dragon op 22 juli 2024 13:21]

[Martinspire]

Dus iedereen moet even aan zijn digibeet-familie uitleggen dat ze toch eens wat veiliger moeten inloggen

[wildhagen]

Het zijn vaak juist digibeten die slachtoffer worden van aanvallen op authentication. Dus dat die nu beter beschermd worden lijkt me juist positief.

En zoals je kan lezen zijn clients als Outlook, Thunderbird etc al ondersteund met de nieuwe methode, en de meeste digibeten zullen vermoedelijk toch al op dat soort clients zitten. Die lopen dus nergens tegenaan.

En gelukkig heb je daar nog 3 maanden voor, mocht er toch nog actie nodig zijn. dus dat zou geen probleem moeten zijn. En je had het ook de afgelopen jaren al kunnen doen natuurlijk

[Siaon]

Digibeten worden nog eerder slachtoffer van phishing en het hebben van wachtwoorden als 'Welkom123'.

Dingen die nog steeds in de hand gewerkt worden door gekke wachtwoord eisen.

Maar goed, nu bijna alles wel in je mail moet, is het niet zo'n gek idee om dat wat beter te beveiligen. Bovenstaande is ook geen reden natuurlijk om andere veel voorkomende aanvalsvectoren niet af te sluiten.

Wat ik me nog wel afvroeg: zijn er daadwerkelijk nog veel mensen die op de oude authenticatiemanier zitten?

Wel vervelend dat alles opeens aan een telefoon gekoppeld moet worden...

[Reactie gewijzigd door Siaon op 22 juli 2024 13:21]

[dmantione]

Zeer veel, want wat Microsoft feitelijk doet is de POP3- en IMAP-protocollen wijzigen. Dus allerhande software die over tientallen jaren is geschreven houdt zich keurig aan het protocol, maar werkt opeens niet meer.

[_JGC_]

De protocollen blijven hetzelfde. Als jij verbindt met een IMAP server geeft die op het CAPABILITY commando een AUTH=LOGIN en/of AUTH=PLAIN voor login met username/wachtwoord. Microsoft geeft straks alleen AUTH=XOAUTH2 terug en de client moet dat ondersteunen.
Wikipedia: Simple Authentication and Security Layer

XOATH2 module voor SASL:
https://github.com/tarickb/sasl-xoauth2

Kwestie van de juiste modules installeren en configureren. Helaas is niet elke client uitbreidbaar via libsasl.

[BeosBeing]

Wel vervelend dat alles opeens aan een telefoon gekoppeld moet worden...

Absoluut

Er zijn heel veel Nederlanders en Belgen die wel e-mail hebben, maar geen mobiele telefoon, laat staan een smartphone. Ik ken een Belgische, inmiddels 90, die wel een mobiele telefoon heeft, zo'n klaptoestel voor ouderen, maar er niet mee overweg kan. (Ze kan wel overweg met de vaste telefoon, maar die heeft er dus door storingen van Telenet ongeveer 6 maanden uit gelegen).

Ook ken ik iemand, die moest op zijn werk als hij zijn kantoor verliet om in een constructie iets te checken of op te meten altijd een pieper meenemen. Vervolgens werd hij steevast, op het moment dat hij ergens bovenin een ladderkooi stond opgepiept, terug beneden 10 minuten later een vaste telefoon gevonden werd hem dan iets lulligs gevraagd, bv waar een bepaalde ontwerptekening lag. Uiteraaard lag die precies daar waar die hoorde, in de tekeningen-kast. Als na zijn vervroegd pensioen de mobiele telefoons gemeengoed werden heeft hij die altijd geweiged te gebruiken. Zijn vrouw had zo'n ding, dat was genoeg. Inmiddels neemt hij zelfs de vaste telefoon niet meer op.

En dan heb je ook van die mensen, die kopen een telefoon van onder de €250 en die laad opeens niet meer of start dan van de ene op de andere dag opeens niet meer op door een bug in een software-update of doordat de accu geen contact meer maakt.

[Cergorach]

Digibeten worden nog eerder slachtoffer van phishing en het hebben van wachtwoorden als 'Welkom123'.

Niet alleen digibeten! Je moet de systeembeheerders nog de kost geven die dat als standaard ww gebruiken, vaak voor nieuwe gebruikers, maar soms ook gewoon als standaard server ww...

Wat ik me nog wel afvroeg: zijn er daadwerkelijk nog veel mensen die op de oude authenticatiemanier zitten?

Het zou op het zakelijke vlak al vier jaar geleden uitgefaseerd worden en toen kregen we de pandemie en werd het allemaal uitgesteld. Maar goed ook, want veel bedrijven/software werkte daar nog niet fatsoenlijk mee. Sommige software bedrijven die met e-mail werken kwamen pas een jaar of twee na de initiële uitfaseringsdatum met een versie van hun software die eindelijk met Modern Authentication zou gaan werken, maar vaak nog vreselijk onstabiel. We hebben uiteindelijk voor een aantal processen zelf wat moeten maken.

Gebruik van een telefoon is puur deel van MFA (multi factor authentication), ik denk dat het duidelijk mag zijn dat authenticatie voor e-mail via e-mail niet de beste keuze is... Net als dat SMS niet de beste MFA strategie is. 99,99% heeft een smartphone, dus waarom daar moeilijk over doen? Het is niet alsof je elke keer een MFA code hoeft in te geven.

Bron:
https://learn.microsoft.c...ntication-exchange-online

[TheVMaster]

Misschien een moment om die digibeten dan te helpen om Passkeys (of een andere passwordless methode) te configureren voor je Outlook account.

[BeosBeing]

En zoals je kan lezen zijn clients als Outlook, Thunderbird etc al ondersteund met de nieuwe methode, en de meeste digibeten zullen vermoedelijk toch al op dat soort clients zitten.

Outlook 2016, Outlook 2013, Outlook 2010?

Die lopen dus nergens tegenaan.

De mwesten misschien niet, maar ik garrandeer je dat die er weldegelijk zijn. Ik verwacht zelfs, vanwege de oude 80/20 regel dus ongeveer 20% van alle gebruikers.
Ga er maar rustig van uit dat de mensen die Vista en 8 hebben overgeslagen ook 11 zullen overslaan, ongeacht hoe lang de release van 12 nog op zich laat wachten.

. En je had het ook de afgelopen jaren al kunnen doen natuurlijk

Als je geweten had dat Oauht2 überhaupt bestaat. Digibeten lezen geen Tweakers, en zelfs vele tweakers-lezers wisten het niet, lees de reacties hier maar.

[HollowGamer]

Correctie, het zijn juist bedrijven die vaak hun beveiliging niet in orde hebben.

Genoeg waarbij wachtwoorden worden gedeelt of hetzelfde zijn, geen wachtwoordmanager is (incl. controle erop), of waarbij dus data wordt opgeslagen zonder enige vorm van encryptie.

Tel gewoon het aantal incidenten recent op, en je ziet dat juist daar enorm veel winst te behalen is.

[FairPCsPlease]

Maar hoe moet ik na 16 september dan inloggen op webmail via de browser? Het artikel (https://techcommunity.mic...nforcing-our/ba-p/4164184) is daar helemaal niet duidelijk over. Ze hebben het erover dat oudere browsers niet meer ondersteund worden en verwijzen naar een Outlook App. Maar ik wil gewoon inloggen via een moderne Firefox browser, maar hoe moet dat dan, als wachtwoord niet voldoende is? Daar zeggen ze niets over.

[Ruthhl3ss]

Webmail via de browser gebruikt geen Basic Authentication. Dat is SAML/OAUTH2/OpenIDConnect gebaseerd. Dus je kunt prima je webmail blijven gebruiken.

Basic Authentication is de oudste vorm van authenticatie voor Exchange Web Services die nog gebruikt en niet meer veilig is. (Het is uiteraard niet de alleroudste vorm maar je snapt wat ik bedoel)

[Reactie gewijzigd door Ruthhl3ss op 22 juli 2024 13:21]

[FairPCsPlease]

Dank, dat is een geruststelling.

[DJanmaat]

Modern authentication in Exchange Online enables authentication features like multi-factor authentication (MFA), smart cards, certificate-based authentication (CBA), and third-party SAML identity providers. Modern authentication is based on the Active Directory Authentication Library (ADAL) and OAuth 2.0.

[The Zep Man]

Titel:

Microsoft stopt op 16 september met Basic Auth-protocol voor Outlook-gebruikers

Dat houdt dus niet in dat Outlook (de zakelijke applicatie uit Office) niet meer basic authentication ondersteunt. Het betreft enkel Microsoft's online mail, waarvan één dienst ook de naam Outlook draagt.

[DJanmaat]

In 365 is het er juist al veel eerder mee opgehouden.

[Reactie gewijzigd door DJanmaat op 22 juli 2024 13:21]

[Z-Dragon]

In 365 is het er juist al veel eerder mee opgehouden.

[Yggdrasil]

In Microsoft365 (de zakelijke variant) is dit al uitgeschakeld.
Zie https://learn.microsoft.c...ntication-exchange-online

[nightgold]

Toevallig was ik net aan het googlen geslagen omdat ik sinds 2 dagen problemen had met mijn Outlook accounts.

Ik heb dus enkele Outlook accounts die ik gebruik met de Windows mail client op mijn W10 PC.
Ik gebruik hier nog de "oude" mail client - niet die webversie die men binnenkort verplicht.
Sinds 2 dagen komen er hier geen mails meer binnen.

Met thunderbird hetzelfde probleem. Maar zonet Thunderbird ge-update en er komen terug mails binnen.
Windows mail kan ik niet "updaten" maar ik durf er geld op te wedden dat de "nieuwe versie" dit ook zou oplossen.

Ik weet niet zeker of dit hier mee te maken heeft ofdat het toeval is.
Maar ik hou me al vast voor de telefoontjes van senioren die in paniek slaan omdat er geen mails meer binnenkomen.

[William_H]

Wele even nieuwsgierig of app-passwords dan wel blijven werken.
Werk hier nog met een BlackBerry KEY2 met BlackBerry Hub, en die wordt niet meer geüpdatet, maar werkt nog wel met app-passwords om toegang tot MS Outlook webmail te ontvangen.
Gekgenoeg geen enkel probleem met GMail, terwijl die ook werkt met Oauth2

[HollowGamer]

Voor webdevelopers ook mooi om eens te kijken naar betere alternatieven.

[Yggdrasil]

In Microsoft365 (de zakelijke variant) is dit al uitgeschakeld sinds vorig jaar (men is 3 jaar geleden begonnen met informeren)
Zie https://learn.microsoft.c...ntication-exchange-online

[topio2]

Allemaal BS om je beter te kunnen volgen en je data. Veiligheid is allang een business model voor data geworden.