Microsoft bevestigt beveiligingslek in Teams door opslaan tokens in plaintext

De desktopapplicatie van Microsoft Teams slaat tokens lokaal op in plaintext; dat melden beveiligingsonderzoekers van het bedrijf Vectra. Het gaat om authenticatie-tokens, waarmee ingelogd kan worden op een account van een slachtoffer.

Vectra schrijft op zijn website dat het bedrijf het veiligheidsrisico in augustus ontdekte en heeft gemeld bij Microsoft. Het beveiligingsbedrijf noemt het een gevaarlijk beveiligingsrisico, omdat met de verkregen tokens ook op een account ingelogd kan worden als dat is beveiligd met tweetrapsauthenticatie. Zeker als de tokens van een hooggeplaatste medewerker binnen een bedrijf worden gestolen, kan de schade aanzienlijk zijn, aldus Vectra.

Volgens Microsoft is het niet zo'n groot risico, omdat een aanvaller toegang zou moeten krijgen tot het netwerk van het slachtoffer, meldt een Microsoft-woordvoerder aan Bleeping Computer. "De beschreven techniek komt bij ons niet in aanmerking voor een acute fix, omdat een aanvaller eerst toegang tot het netwerk van het slachtoffer moet krijgen. We waarderen wel dat Vectra Protect dit heeft geïdentificeerd en op een verantwoordelijke wijze heeft gemeld. We zullen overwegen dit mee te nemen voor een toekomstige productrelease". Tot Microsoft met een oplossing komt, adviseert Vectra om de browserversie van Microsoft Teams te gebruiken. Deze beschermt volgens het bedrijf beter tegen het lekken van de tokens.

Microsoft Teams

Reacties (84)

[Shirenzo]

Code plus alle uitleg hier te vinden:
https://github.com/bobbyrsec/Microsoft-Teams-GIFShell
https://medium.com/@bobby...t-teams-gifs-1618c4e64ed7

Have fun!

[Tjidde]

Buiten het feit dat het risico klein is.(aldus Microsoft)

Waarom zou je zo iets ooit als plaintekst opslaan? De enige reden die ik kan bedenken is voor dev redenen, een token makkelijk inzien en kopiëren kan voor ontwikkelreden handig zijn. Maar daarbuiten? Zeker met zo'n applicatie als teams...

[geenidee]

Omdat: "Electron does not support encryption or protected file locations by default"

[Tjidde]

Dat is toch geen goede reden? Er zijn genoeg manieren omdat toch te doen. Je kunt je applicatie zelf toch een encryptie methode laten uitvoeren.

[bartvb]

Hoe dan?
Je applicatie moet het weer kunnen ontsleutelen, dus waar laat je die sleutel dan? Als jouw applicatie de sleutel kan ophalen/genereren, dan kan een attacker die toegang heeft tot dezelfde data dat ook.

In dit geval moet een attacker toegang hebben tot de bestanden van de Teams applicatie. Als iemand al zoveel toegang heeft dan heb je al een groter probleem dan de tokens in de Teams app...

[Brahiewahiewa]

Nou, daar heeft Microsoft zelf de "secure store" voor ontwikkeld. Die wordt ook door IE en Edge gebruikt om wachtwoorden op te slaan. Nog steeds niet 100% waterdicht maar beter dan plaintext in een file

[bartvb]

Hoe beschermt de 'secure store' dan tegen een attacker die toegang heeft tot de disk?

Zolang je tijdens het starten van de Teams applicatie geen secret (wachtwoord/keycard/etc) in hoeft te geven lijkt mij dat de data te ontsleutelen is met alleen de informatie op de disk (of in ieder geval machine) zelf?

[Jan_V]

Als mensen toegang hebben tot de disk/systeem, dan is toegang krijgen een 'fluitje van een cent'.

Komt wel een beetje kennis bij kijken, maar Paula Januszkiewicz heeft het laten zien tijdens de keynote van Azure Lowlands. De volledige sessie kan hier worden gekeken (~1 uur): https://www.youtube.com/watch?v=fCOeOa9QaYc

[sprankel]

Secure store is een feature van Sharepoint en is geen feature van Edge zelf. Edge plaatst inderdaad zijn keys op de disks weliswaar niet in plain text.

Maar MS heeft duidelijk ingezet om al dat soort keys niet meer op de disk te hebben waar het inderdaad kwetsbaar blijft maar om ze te verhuizen naar de TPM en die als crypto provider in te zetten wat ook een van de redenen is dat een TPM verplicht is voor Win11. En nee dat is niet voor bitlocker, Win11 home edities ondersteunen zelfs geen bitlocker.

Echter is het nog afwachten op de verdere implementatie en API's om private keys effectief in de TPM te plaatsen.

[Brahiewahiewa]

De secure store verifieert of de gebruiker in kwestie de rechthebbende is. Andere gebruikers - zelfs als ze admin zijn - kunnen jouw secure store niet uitlezen.

[thof]

Permissies op het filesystem doen toch hetzelfde? Een bestand pas serveren als de gebruiker een rechthebbende is? Enige verschil zou dan kunnen zijn dat een admin daar dan ook bij kan?

[Brahiewahiewa]

Of iemand die de moeite neemt de schijf in een andere PC te steken

[wiezalditzijn]

Precies dit? Ik wil dit ook heel graag weten trouwens. Ik heb mij app op precies dezelfde manier gemaakt. In sta de JWT token lokaal op in localStorage.

[zenlord]

*kuch* Never store a JWT inside localStorage...

https://blog.logrocket.co...access%20to%20the%20token.

[Dykam]

Voor Electron-apps gelden wel andere regels dan voor webapps. En daarnaast vind ik die regel niet zo absoluut, het zal van het scenario afhangen.

Als je het als httponly-cookie kan opslaan, dan is dat goed, maar dat werkt niet altijd voor alle scenarios.

[zenlord]

In zoverre Electron.js het onmogelijk maakt voor de *tig "via NPM geinstalleerde libraries en scripts" om alle data in je localStorage te benaderen, ben ik het met je akkoord dat deze regel niet voor Electron-based apps zou gelden.

In ieder ander scenario is het géén goed idee om authenticatie tokens in localStorage te bewaren.

[WoutervOorschot]

Hier wordt genoemd dat je de token niet in javascript zou moeten kunnen uitlezen, echter staan in de token vaak ook de rollen die je krijgt met die token. Die wil je uit kunnen lezen in je javascript in het geval van een SPA/electron app, net zoals je dat in een native app zou doen.

[xleeuwx]

Die zou je bij verwerken van de token er uit kunnen halen of eventueel met api call ophalen

[zenlord]

Dan moet je authenticatie en authorisatie splitsen. De authenticatie token bewaar je NIET in localStorage, en met de authorisatie token doe je wat je wilt. Enkel jouw code leest de authenticatie code uit en geeft dan groen licht aan de rest van de app om op basis van de rollen in je authorisatie token groen licht of niet.

[Anoniem: 80910]

Als je jwt niet past in een cookie, wat dan?

[zenlord]

Dan moet je je JWT aanpassen, en zeker niet je beveiligingsniveau degraderen.

[graey]

De server genereert een token, versleutelt die, waarbij gebruikerinput zoals het wachtwoord (bijv) gebruikt wordt in de sleutel.
Lokaal wordt de versleutelde token opgeslagen, die alleen gebruikt kan worden met dezelfde gebruikersinput. Dan kan de versleutelde token lekken zonder gevaar.
In dit voorbeeld noem ik het wachtwoord als onderdeel van de versleuteling, maar dat kan ook iets lokaals zijn dat door het OS wordt aangeleverd, waarbij afhankelijk van de gekozen methode wel of niet gebruikersacties vereist zijn.
In het geval dat een aanvaller hier tussenkomt heeft hij dan niet alleen je teams-applicatie nodig, maar ook nog iets anders van jouw fysieke machine.

[Wouterie]

Nou, aangezien het de desktopapplicatie betreft neem ik aan dat ze dit probleem op een ander platform wel hebben weten op te lossen. Neem bijvoorbeeld de Android app. Verder ben ik niet echt thuis in Electron, de aanbeveling van de Vectra is: "If you must use Electron for your application, ensure you securely store OAuth tokens. One such method for storing secrets is to use the package KeyTar, which leverages local OS security mechanisms for secret management." https://cameronnokes.com/...lectron-with-node-keytar/

[geenidee]

Oh ik zeg ook niet dat het een "goede" reden is, maar lijkt me wel 1 van de redenen.

[Skit3000]

Sowieso kan je elke encryptie in Electron-apps omzeilen door gewoon de javascript developer tools te openen waarna je overal bij kunt waar de app zelf bij kan, inclusief tokens die zijn opgeslagen met encryptie (plus alle methoden om dat weer te decrypten). Daarnaast moet je als je lokaal iets wilt kunnen encrypten en decrypten, ook lokaal de sleutel(s) hebben, waardoor dat altijd een zwak punt blijft.

Microsoft heeft (deels) gelijk door te stellen dat de impact laag is omdat een aanvaller al toegang moet hebben tot het lokale netwerk, want zodra iemand in je computer kan kunnen ze sowieso al meekijken met alles wat je doet.

[svane]

Dat staat inderdaad in het artikel. Maar als ik even zoek op de site van Electron.

Allows access to simple encryption and decryption of strings for storage on the local machine.

This module protects data stored on disk from being accessed by other applications or users with full disk access.

Dit lijkt me precies wat je nodig hebt. Mis ik hier iets?

[Irsu85]

Nou, dan voeg je toch gewoon een AES library ofzo toe en sla je de geencrypteerde (via die AES library) key toch op in plain text? (zit je natuurlijk wel weer met de key van de key, maar je kan misschien ook iets anders dan AES gebruiken). Ik ben nu een java app aan het maken die wachtwoorden moet opslaan, dat hoeft niet geencrypt, gewoon een bcrypt (scrypt of SHA256 kan ook) library toevoegen en de hashes in plain text opslaan...

[Blokker_1999]

Er is een groot verschil tussen hashing en encryptie. Wat jij doet is hashing. Dat is een 1-way manier om een wachtwoord op een veilige manier op te slaan. Maar je kan van die gehashte waarde nooit het origineel gaan terughalen.

Voor een authenticatietoken veilig op te slaan moet je het geencrypteerde ook weer kunnen ontsleutelen. Je hebt dus een private key nodig om alles mee te versleutelen en achteraf te ontsleutelen. Nu is je token wel veilig opgeslagen, maar waat ga je die sleutel opslaan? Niet vergeten, je moet die sleutel ook weer kunnen uitlezen.

Dat is het probleem waarmee men zit. De app moet altijd terug aan de data kunnen. En een aanvaller heeft al toegang nodig tot jouw systeem om tot aan die data te komen en kan dus vermoedelijk alles al uitlezen. Al zit deze gewoon te wachten totdat jouw Teams het token nog eens nodig heeft waardoor het alsnog heel kort in geheugen bestaat.

[CAPSLOCK2000]

Waarom zou je zo iets ooit als plaintekst op slaan?

Omdat encryptie weinig zin heeft als je geen manier hebt om de sleutels apart op te slaan en veilig te houden. Een groot slot op de deur heeft weinig zin als de sleutel aan een haakje naast de deur hangt.

Soms kan je nog ergens komen door een sleutel te genereren uit het wachtwoord van de gebruiker of zo iets maar dat is ook niet altijd mogelijk of zinnig.

Als algemeen principe is er nog wel iets voor te zeggen om alles maar altijd te encrypten, ook als je key er bij moet geven. Je weet nooit wat er in de toekomst mis gaat en welke dat er op een of andere manier lekt. Dan kun je hopen dat je versleutelde data wel lekt maar de sleutel niet.

Overigens zijn er wel oplossing voor dit probleem zoals de HSM-chips die veel moderne systemen hebben. Maar ook die hebben hun beperkingen want de gebruiker moet er uiteindelijk wel gebruik van kunnen maken. Als de gebruiker het kan dan kan software het ook. Zelfs als de key technisch gezien niet uit zo'n HSM kan lekken betekent het niet dat je data ook niet kan lekken, op enig moment moet die toch onsleuteld (kunnen) worden.

[kftnl]

Waarom zou je zo iets ooit als plaintekst opslaan? De enige reden die ik kan bedenken is voor dev redenen, een token makkelijk inzien en kopiëren kan voor ontwikkelreden handig zijn.

Er is nog een andere Dev reden binnen grote techbedrijven, als je het gewoon als tekst opslaat heb je daar weinig discussie over met security in de zin van dat je dan duidelijk aangeeft dat het geen doel van je is die token te beschermen tegen anderen op de disk. Als je gaat encrypten dan zal die key ergens moeten worden opgeslagen en krijg je beveiligingsmensen over je heen over dat wat je doet niet veilig is, dat het geen zin heeft wat je doet, dat het kraakbaar is, etc.

Als je aangeeft dat je dit als soort obfuscation doet als 'baat het niet dan schaadt het niet' dan zul je daar vaak weinig begrip voor krijgen.

[Mimiix]

Is dit niet vrij simpel te mitigaten door de token (sneller) te laten verlopen? Normaliter zijn volgens mij tokens maar een uur geldig binnen Azure.

[Cergorach]

Afhankelijk van welke security features je heb draaien zal er ook bij een hoop organisaties een alarm afgaan omdat het account wordt gebruikt vanaf een onbekende/niet standaard locatie.

Ik vraag me ook af hoeveel access je hebt met die token.

[Blokker_1999]

Maar ondertussen heeft de aanvaller wel een token dat geldig is, en van zodra het token verloopt, en de aanvaller heeft nog steeds toegang, kan die gewoon het nieuwe token komen ophalen.

[segil]

Een applicatie krijgt na een succesvolle authenticatie een refresh token die een x aantal dagen geldig is. Met deze token kan een applicatie een access token aanvragen die 1 of 2 uur geldig is (weet ff niet zo gauw welke vd 2). Met deze access token kan de applicatie toegang krijgen tot de benodigde resources. Na die 1-2 uur moet een nieuwe access token worden aangevraagd met de refresh token. Dit is transparant voor de eindgebruiker. Bij het verlopen van de refresh token zal de gebruiker opnieuw moeten authenticeren. Om welke token het hier gaat weet ik niet.

[MiesvanderLippe]

Tsja. Lokale toegang of fysieke toegang zonder full-disk encryption. Op dat moment moet je er sowieso vanuit gaan dat er stront aan de knikker is.

[StraightOn.NL]

Nou zo ken ik er nog een; niet perse een beveiligingslek, maar wel een design-flaw mijn inziens.

Teams - Private Channels: De informatie daarvan is zichtbaar via SharePoint Search wanneer het Team, waarbinnen je Private Channel leeft, lid is van een Hub die standaard viewers heeft.

Of die viewers uberhaupt via Hub Permission Sync enabled zijn, (binnen de Teams-site of het Private Channel) doet er niet toe...de permissions worden toch gesynct zonder dat je dit kan zien in de UI. Erg leuke casus gehad hierover met Microsoft...

[Reactie gewijzigd door StraightOn.NL op 23 juli 2024 03:47]

[paulwump]

Zo, die zinnen ga ik nog eens een paar keer lezen...misschien begrijp ik dan wat er staat

[StraightOn.NL]

Ow ik zie nu dat ik copy-paste twee zinnen door elkaar had gehaald. Woeps. Ik hoop dat het zo iets duidelijker is haha

[keesg]

dan moet ik ze nog wel 25 keer lezen.....

[laurens0619]

Volgens Microsoft is het niet zo'n groot risico, omdat een aanvaller toegang zou moeten krijgen tot het netwerk van het slachtoffer,

Bij netwerk denk ik aan lan/wifi maar in deze context bedoelt microsoft waarschijnlijk toegang tot (het fileysteem van) de computer.
Ja euh dat is wel ff iets anders, als een hacker daar zit dan kan die het op genoeg andere manieren je office365 sessie stelen

[joost00719]

De beschreven techniek komt bij ons niet in aanmerking voor een acute fiks, omdat een aanvaller eerst toegang tot het netwerk van het slachtoffer moet krijgen

Lekker handig. Even met de wifi verbinden in een café, en je teams word gehackt...
Of misschien zelfs collega's die zich als jou voor gaan doen, want die zitten immers op het zelfde netwerk.

[Anoniem: 421923]

als de IT-afdeling zijn werk goed heeft gedaan, kan je niet zomaar op de laptop van je collega komen, ook al zit je op hetzelfde netwerk.

[Reactie gewijzigd door Anoniem: 421923 op 23 juli 2024 03:47]

[the_stickie]

Logon restrictions is een mogelijke configuratie, maar één die ik in de praktijk niet veel ben tegengekomen.
Wat ik vaker zie is een vorm van auditing/log collection om te zien wie op welke devices aanmeldt.
Wat belangrijker is, is dat je naast de rechten om aan te melden ook nog rechten nodig hebt om de nodige bestanden te zien. Die (tokens) zitten in de profile folder van de gebruiker, waar een andere gebruiker by default niet aankan.

[batjes]

Je kan als IT afdeling nog zo je best doen, maar als mensen hun wachtwoorden noteren op post-its of in schriftjes. Dan houd het al snel op.

2FA kan je wel overal gaan verplichten, maar het is vrij normaal de IP adressen van je locatie(s) te whitelisten zodat men op kantoor niet om de haverklap 2FA hoeft in te voeren/accepteren.

En het ligt er maar net aan om welke collega's je het hebt, ik kan als ITer op elke laptop inloggen met mijn admin account en iedereens mappen openen. Dit kunnen we wel dicht zetten, maar het is ook gewoon nodig voor mijn werkzaamheden.

[Androo]

Dan zou ik even ga nadenken over LAPS bijvoorbeeld.
Wij kunnen met GEEN account, op meerdere computers inloggen en admin rechten hebben.

Tegenwoordig is dit bijna een must.
Gebruik je het zelfde account om ook op servers in te loggen? Dan zou ik snel gaan nadenken over priveledge accounts.

[batjes]

Maken we ook gebruik van, maar is niet even handig als je ergens in het veld staat.

[weeraanmelden]

Passwordless
Je laat een medewerker via TAP code een FIDO2 token registeren en dan Windows Hello for Business gebruiken voor de lokale logon.
en MFA voor high risk accounts en logons.

Als je ze het wachtwoord niet geeft, dan kunnen deze niet opschrijven

[Byron010]

Dat is een grote 'als' bij een wereld met zo enorm veel bedrijven en ook veel kleinere bedrijven die geen geld hebben voor uitgebreide systeembeheer, netwerkbeheer en cybersecurity.

[Frame164]

Als je voor basisbeveiliging geen geld hebt is het geen bedrijf maar een hobby.

[FateTrap]

Is dit artikel niet één van de talloze bewijzen dat de meeste bedrijven redelijk slechte basisbeveiliging hebben?

Zoom en Teams zijn twee van de populairste technologiën voor video conferenties, maar zowel Teams als Zoom hebben vele veiligheidsproblemen en andere bedenkelijke problemen gehad. Voor windows kan je de source code niet inkijken en berust je veiligheid dus uiteindelijk op blind vertrouwen. Is dat basisbeveiliging?

Windows Computers Were Targets of 83% of All Malware Attacks in Q1 2020 https://www.pcmag.com/new...alware-attacks-in-q1-2020

Maar de meeste bedrijven blijven windows gebruiken hoewel er veel andere stabielere en goedkopere alternatieven zijn. Dus ik heb de indruk dat bedrijven niet echt serieus bezig zijn met basisbeveiliging.

Jitsi Meet heeft veel minder beveiligingsproblemen gehad en geeft altijd al veel beter beeld en geluid dan wat MS Teams en Zoom de laatste 5 jaren durfden te leveren..

[Tjidde]

Wat er vaak gebeurd, bij begin van bedrijf regelen ze van alles. Laten ze een IT bedrijf wat dingen doen.

Echter kijken ze daarna er nooit meer naar om.

Maar ik ben het met je eens je bent als bedrijf verplicht om een minimale beveiliging te regelen. Ik wil niet weten hoeveel kleine bedrijfjes slecht met hun beveiliging omgaan. Een schildersbedrijf met een man of 10 personeel. Ik zou niet raar staan de kijken als de eigenaar (of iemand met veel rechten binnen de organisatie) een wachtwoord heeft die niets voorstelt zonder MFA.

Dan heb ik het nog niet over simpele fouten op een website, die ooit 1x is gemaakt in Wordpress met PHP versie 6 ofzo. Waar als je een 5minuten tijd neemt overal bij kan.

[S-1-5-7]

Als ik het goed begrijp moet je toegang hebben tot het filesystem om de token te bekijken. Standaard is Windows zo geconfigureerd dat dit niet zomaar mogelijk is zonder de firewall te configureren en het hebben van een geldige gebruikersnaam & wachtwoord. Het is zelfs 'vrij moeilijk' om binnen Windows SMB open te zetten voor ongeauthenticeerd gebruik...

[Djerro123]

Dit is juist een zeer kleine 'als', je kant echt niet zomaar op een andere (Windows) computer rondneuzen als je op hetzelfde Wi-Fi netwerk zit Daarvoor hoef je niet eens één systeembeheerder te hebben, dit kan bij default niet. En zonder toegang tot het file systeem, kan je niet bij het token komen.

[bartvb]

Net even door het bronartikel gebladerd maar het lijkt erop dat je toegang moet hebben tot het lokale filesystem. Daar staan die tokens in plain text.

[Cergorach]

Ik mag hopen dat zelfs met een bagger IT afdeling je op het hart wordt gedrukt dat je niet met de bedrijfslaptop verbonden mag worden met dergelijke wifi netwerken. Dat je daar niet naar luistert is jou issue! Net als dat de IT afdeling ook slechts pas na x minuten inactiviteit je systeem locked, kunnen ze er niets aan doen als jij je PC niet locked en even na de WC gaat in een cafe...

Collegae die zonder toestemming elkaars accounts hacken/gebruiken hebben een hele grote kans om ontslagen te worden! Of erger...

[jmvdkolk]

Als de IT afdeling er vanuit gaat dat medewerkers niet connecten met public Wi-Fi dan leeft de IT afdeling in een fantasie wereld. De enige manier om enigzins te voorkomen dat er contact gemaakt wordt met public Wi-Fi, is iedere laptop met een SIM met onbeperkte data uitrusten zodat er weinig reden is om met public Wi-Fi te willen verbinden.

[Cergorach]

Een hele hoop bedrijven geven hun medewerkers een mobieltje met bijhorende databundel, die als hotspot kan fungeren...

[jmvdkolk]

Dat heb ik. En ik moet regelmatig alsnog op public Wi-Fi in hotels omdat de mobiele ontvangst niet goed genoeg is. Hetzelfde op vliegvelden.

[Blokker_1999]

Natuurlijk mag dat wel, waarom zou dat niet mogen? Je moet als bedrijf ook je beveiliging gewoon in orde hebben. Goede always-on VPN gebruiken en de nodige beveiligingsoftware op de laptop.

[Cergorach]

Ik zie VPN ook niet als alles fixer. Maar je heb wel een heel sterke mening hier, wat lost een VPN hier dan exact niet op?

[Alfa1970]

Het probleem waar het artikel over gaat wordt niet opgelost door het gebruik van een VPN als het gaat om websites die publiek toegankelijk moeten zijn.

Wanneer de site niet publiek toegankelijk is, dan lost een VPN nog steeds het probleem niet op want via de VPN is de site bereikbaar en dus blijft de kwetsbaarheid bestaan.

En als het gaat om de reactie op de post, nl. iemand die z'n laptop open laat staan, dan nog gaat de VPN niet helpen omdat die net als de laptop gewoon nog open staat.

Een VPN zorgt voor een relatieve beveiliging van de communicatie tussen twee eindpunten.
Als echter op een van de eindpunten zich een probleem bevindt, dan wordt dat probleem niet door de VPN opgelost.
De verbinding is er nog steeds, het eindpunt is nog steeds bereikbaar, en de kwetsbaarheid kan nog steeds worden misbruikt.

[g_v_rijn]

Hooggeplaatst persoon - gebruikt natuurlijk geen cafe / spooky wifi access.

[walteij]

Nee, die gebruikt de WiFi van het Hilton hotel, van de skylounge op Schiphol, waar net zo goed rogue accesspoints geplaatst kunnen worden (misschien wel makkelijker vanwege het groot volume aan mensen dat daar voorbij komt).

[Anoniem: 1301524]

En daarom gebruiken we al meer als 10 jaar https overal.

[RogerDad]

De verbinding van de elektron app naar de Teams server is wel versleuteld, het genoemde risico gaat puur om de locale opslag.

[Ventieldopje]

En zo draaien ze ook mooi de nek om van de Windows desktop applicatie. Die voor Linux ontwikkelen ze ook al niet meer binnenkort (ook al promoten ze hem nog wel). En dat terwijl het gewoon om een goedkope Electron app gaat.

Die hele ervaring was al niet best maar ze maken er nu wel echt een potje van.

[hottestbrain]

WASM heeft de toekomst, dus lijkt me een prima uitgangspunt voor dergelijke cross-platform applicaties.

[juiced01]

"Die voor Linux ontwikkelen ze ook al niet meer binnenkort" Is dit een aanname of is dit echt zo? Zou voor veel Linux gebruikers wel jammer zijn op 't werk...

" Die hele ervaring was al niet best maar ze maken er nu wel echt een potje van. " Absoluut, de app is niet best

[Reactie gewijzigd door juiced01 op 23 juli 2024 03:47]

[GekkePrutser]

Nee dit is echt zo.

https://www.reddit.com/r/...client_on_linux_is_being/

Of: https://news.ycombinator.com/item?id=32678839

Dat het geen link is van MS zelf komt doordat ze deze info niet gepubliceerd hebben op hun site maar per email aan admins hebben gestuurd.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 03:47]

[Brahiewahiewa]

Nee dit is echt zo...

Nee, dit is niet zo. De Linux desktop applicatie gaat er per 30 december uit. Maar er komt een web-app voor in de plaats. Dus het is niet zo dat het Linux platform ineens zonder Teams komt te zitten

[GekkePrutser]

Het ging over de desktop applicatie, die verdwijnt dus.

En de web app was er allang al (al is die nogal beperkt).

[juiced01]

ah, dat had ik gemist, thanks

[bush]

Er gaan al een tijdje geruchten dat Microsoft werkt aan een volledige nieuwe teams app die niet langer op electron is gebaseerd.
https://tomtalks.blog/mic...ectron-for-edge-webview2/
en
https://blog.devgenius.io...ing-electron-9e081757f9db

[Reactie gewijzigd door bush op 23 juli 2024 03:47]

[Blokker_1999]

Artikelen van meer dan een jaar oud ... dan heb ik er niet veel hoop op dat we dit gaan zien.

[hottestbrain]

Als je een stabiele applicatie wil uitbrengen die voor miljoenen gebruikers geschikt is duurt dat langer dan een jaar, vooral als je die met backwards compatibility tóch van de grond af aan opnieuw gaat opbouwen.

[himlims_]

moment dat je die teams app opstart, wordt mijn laptop al gelanceerd richting de maan vanwege cpu-load. holy crap wat een in-efficient en ram-vretende tool (en dan wordt er nog niet eens een video verbinding gestart)

[rc_enzo]

Het is een matige keuze m.b.t. beveiliging geweest ja, maar dat heeft in principe niks te maken met het gebruik van Electron in de basis. Het lijkt me heel onwaarschijnlijk dat ze van desktop applicaties af zouden stappen.

[viool123]

Kleine typo "Het beveiligignsbedrijf" @Robert Zomers

[Robert Zomers]

Dank voor het melden! We hebben hier trouwens een speciaal forum voor dat scherp in de gaten wordt gehouden door de redactie, dus meldt dit soort dingen vooral daar voor een snelle fix.

[Raymond Deen]

Aiaiai, vind het toch wel beschamend dat je op je eigen platform nog niet eens de features weet te gebruiken om dit soort banale fouten te voorkomen.
Ben benieuwd of we er ooit nog achter gaan komen hoe dit kon gebeuren.

[The Zep Man]

Aiaiai, vind het toch wel beschamend dat je op je eigen platform nog niet eens de features weet te gebruiken om dit soort banale fouten te voorkomen.

De Teams client is gebouwd op Electron, wat niet Microsoft's eigen platform is.

Dat is overigens nog steeds niet echt een goed excuus.

[Raymond Deen]

Ook omgesmurfde webapps kun je prima veilig bestandjes laten opslaan. Plain text dingen laten opslaan die direct gebruikt kunnen worden om bij beveiligde omgevingen te komen is gewoon héél erg slecht. Teams als zakelijke collaboration tool is sowieso al niet echt heel sterk, maar dit is geen goeie reclame.