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

Door Robert Zomers

Redacteur

15-09-2022 • 11:48

84 Linkedin

Submitter: il_mostro

Reacties (84)

Wijzig sortering
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...
Reageer
Omdat: "Electron does not support encryption or protected file locations by default"
Reageer
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.
Reageer
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...
Reageer
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
Reageer
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?
Reageer
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
Reageer
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.
Reageer
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.
Reageer
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?
Reageer
Of iemand die de moeite neemt de schijf in een andere PC te steken
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
Die zou je bij verwerken van de token er uit kunnen halen of eventueel met api call ophalen
Reageer
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.
Reageer
Als je jwt niet past in een cookie, wat dan?
Reageer
Dan moet je je JWT aanpassen, en zeker niet je beveiligingsniveau degraderen.
Reageer
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.
Reageer
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/
Reageer
Oh ik zeg ook niet dat het een "goede" reden is, maar lijkt me wel 1 van de redenen.
Reageer
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.
Reageer
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?
Reageer
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...
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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 15 september 2022 15:50]

Reageer
Zo, die zinnen ga ik nog eens een paar keer lezen...misschien begrijp ik dan wat er staat
Reageer
Ow ik zie nu dat ik copy-paste twee zinnen door elkaar had gehaald. Woeps. Ik hoop dat het zo iets duidelijker is haha
Reageer
dan moet ik ze nog wel 25 keer lezen.....
Reageer
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
Reageer
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.
Reageer
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 tyrunar op 15 september 2022 11:57]

Reageer
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.
Reageer
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.
Reageer
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.
Reageer
Maken we ook gebruik van, maar is niet even handig als je ergens in het veld staat.
Reageer
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
Reageer
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.
Reageer
Als je voor basisbeveiliging geen geld hebt is het geen bedrijf maar een hobby.
Reageer
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..
Reageer
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.
Reageer
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...
Reageer
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 8)7 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.
Reageer
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.
Reageer
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...
Reageer
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.
Reageer
Een hele hoop bedrijven geven hun medewerkers een mobieltje met bijhorende databundel, die als hotspot kan fungeren...
Reageer
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.
Reageer
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.
Reageer
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?
Reageer
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.
Reageer
Hooggeplaatst persoon - gebruikt natuurlijk geen cafe / spooky wifi access.
Reageer
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).
Reageer
En daarom gebruiken we al meer als 10 jaar https overal.
Reageer
De verbinding van de elektron app naar de Teams server is wel versleuteld, het genoemde risico gaat puur om de locale opslag.
Reageer
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.
Reageer
WASM heeft de toekomst, dus lijkt me een prima uitgangspunt voor dergelijke cross-platform applicaties.
Reageer
"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 15 september 2022 11:56]

Reageer
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 15 september 2022 11:59]

Reageer
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
Reageer
Het ging over de desktop applicatie, die verdwijnt dus.

En de web app was er allang al (al is die nogal beperkt).
Reageer
ah, dat had ik gemist, thanks :)
Reageer
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 15 september 2022 12:09]

Reageer
Artikelen van meer dan een jaar oud ... dan heb ik er niet veel hoop op dat we dit gaan zien.
Reageer
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.
Reageer
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)
Reageer
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.
Reageer
Kleine typo "Het beveiligignsbedrijf" @Robert Zomers
Reageer
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.
Reageer
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.
Reageer
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.
Reageer
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.
Reageer


Om te kunnen reageren moet je ingelogd zijn

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ

Rapporteer misbruik van moderaties in Frontpagemoderatie.




Google Pixel 7 Sony WH-1000XM5 Apple iPhone 14 Samsung Galaxy Watch5, 44mm Sonic Frontiers Samsung Galaxy Z Fold4 Insta360 X3 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee