Názory k článku
Electronový klient MS Teams ukládá autentizační tokeny jako text
-
Filip JirsákStříbrný podporovatelTo není chyba. Všechny programy, které si pamatují přístup někam (tj. hesla, klíče apod.) i když program ukončíte, a nevyžadují po vás při příštím spuštění heslo, ty údaje ukládají někam na disk buď jako otevřený text, nebo jako ekvivalent otevřeného textu – data jsou sice zašifrována, ale klíčem, který je zase někde uložen na disku, buď v aplikaci nebo v nějaké konfiguraci.
Třeba prohlížeče takhle mají uložená hesla v interním správci hesel, pokud není chráněn hlavním heslem.
Ono to totiž na Linuxu/Windows/MacOS jinak nejde – nejde správný dešifrovací klíč vyčarovat z ničeho, a na těchto systémech neexistuje žádné úložiště, které by bylo určené jenom pro danou aplikaci a nikdo jiný by se do něj nedostal.
-
Není to tak úplně pravda. Linux/Gnome má nějaký ten keyring, do kterého se ukládají hesla a aplikace je tam mohou cpát také. Nejsem si teda jistý, jak je řešení to úložiště klíčenky, ale jelikož je to navázané na login uživatele, tak by to mohlo být alespoň šifrované jeho heslem do systému. Když se podívám do té své klíčenky, tak tam má uložené věci Remmina (RDP/VNC/whatever klient), Nextcloud, nějaké profily Network Manageru a nějaký záznam je tam i od chromia, takže se domnívám, možná mylně, že chromium tímhle klíčem šifruje ty svoje uložená hesla.
Jak je to u ostatních OS netuším, vybavuju si matně, že MacOS něco takového má taky, u Windows nevím vůbec...
-
Podle meho je nestastne pouzivat stejne heslo jak k prihlasovani do systemu tak sprave klicenky hesel. Uz jen proto, ze mnohdy heslo k pocitaci uhodne na treti pokus i decko. A to kolikrat i ve firme. Kde take hrozi vetsi riziko prozrazeni hesla k uctu. Dalsi veci je, ze pokud pripadny zajemce o vase pristupy tusi kde hledat, staci mu pockat si, az opustite pocitac (a ruku na srdce, kolik lidi jej pri svem odchodu poctive zamyka?). Minimalne se muze dostat na ucty a sluzby chranene prave hesly v te integrovane klicence.
Za me je znacka ideal oddelena klicenka ala pass. Je to sice o neco mene "user friendly" (jedovaty usklebek), ale jednak je k jejimu pristupu potreba jine heslo a jednak se nikam automaticky nevyplnuje. A kdyz je potreba zas potvrdit heslem.
-
> k prihlasovani do systemu tak sprave klicenky hesel. Uz jen proto, ze mnohdy heslo k pocitaci uhodne na treti pokus i decko.
a vieš mi vysvetliť aký je rozdiel medzi heslom do systému a do keyringu? Však to môže byť zhodne string s rovnakými pravidlami. Absolútne nedáva zmysel že by heslo do systému malo byť ľahšie uhádnuteľné než heslo do keyringu. V mojom prípade by si ho teda určite neuhádnul, pretože to heslo je náhodne vygenerované o dĺžke 20 znakov, obsahujúc malé, veľké písmená, čísla, špeciálne znaky, medzeru a ešte aj znak, ktorý som pred nedávnom ani nevedel ako na klávesnici napísať.
16. 9. 2022, 15:21 editováno autorem komentáře
-
Pokud má někdo heslo do počítače, co uhádne i děcko, bude ho mít i do té klíčenky... a ruku na srdce, externí aplikaci, do které se cvaká nějaké heslo při každém přístupu, většina lidí používat nebude...
(Já třeba vyjma tohohle používám i ten keepass, s dalším heslem a klíčem, jiným než do systému... ale taky úplně upřímně ho mám nastavený tak, že zůstává odemčený pořád (a ano, ten počítač doopravdy zamykám, když jdu od něj pryč), protože bych se jinak udatloval, kdybych při každém přístupu k heslům tam měl cvakat heslo (navíc těch databází tam mám několik, takže nacvakat heslo do hlavní, v ní najít heslo k té druhé, ...)).
-
Nic to ale nemění na pointě, že by heslo do klíčenky a heslo do systému nemělo být stejné. Mělo, pokud nejste dostatečně paranoidní.
Za mě už jsem ve firmě viděl skype virus, který po kliknutí na odkaz zaslaný "od kamaráda", stáhnul trojana, a ten prosvištěl všechno co mohl... všechna známá místa, kam aplikace ukládají data. (firefoxy, chromy, explorery, registry od winscp, putty, uložené terminal session atd...) a odeslal je do světa.Od té doby nikam nic neukládám. Z tohoto pohledu je tedy hodně (hodně, hodně) vhodné, mít heslo k takovéto utilitě oddělené od systémového přihlášení.
-
macOS má na to systémového správce hesel a certifikátů Keychain Access.app, která má přesně tohle na starosti.
Chápu, že vývojáři zvláště ti, co nerozumí OS pro které programují a jsou odstíněny desítkami abstrakcí (a píší v JavaScriptu [sorry nedalo mi to]) tohle nevidí a uložit cokoliv na disk je prostě jednodušší a „prostě multiplatformní“.16. 9. 2022, 13:54 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Ve skutečnosti jsou MS Teams electronová aplikace, takže to používá standardní prostředky webového prohlížeče, který je v té aplikaci zabalený. Ten autentizační token je totiž uložen jako úplně obyčejná cookie v SQLlite databázi. Cookie je to proto, aby se to automaticky přibalovalo k HTP požadavků - a ta cookie je HTTP only, takže technicky Microsoft Teams klient o té cookie ani neví, nemá možnost ji číst natož ji odmítnout. Ale chápu vaši námitku, kterou očekávám, že přece server je také od autorů Teamsů.
Mimochodem to znamená, že úplně stejně se chovají všechny elektronové aplikace. Což málokoho zajímá, ale Teamsy jsou od Microsoftu, takže si kde kdo rád kopne.
No a ta databáze cookie má v sobě sloupečky value a encrypted_value, přičemž se používá ten nešifrovaný. Aktuální verze prohlížečů postavené na Blinku už mají jenom ten šifrovaný sloupeček, takže je otázka, proč je to v Elektronu jinak. Jednak v Elektronu není úplně nejnovější jádro, takže je možné, že je tam prostě jádro z doby, kdy se na šifrování cookies na disku teprve přecházelo. Také je možné, že byla podpora klíčenek z Elektronové verze prohlížeče prostě vyhozena, protože je to kód závislý na platformě, dost specifický, a nepředpokládalo se, že by měl v electronových aplikacích velký význam. Nezapomínejme, že Electron původně vznikl (pod jménem Atom Shell) jako framework, ve kterém byl napsán textový editor - a je potřeba mít velkou fantazii, aby si někdo představil, že v podstatě GUI framework pro textový editor bude potřebovat ukládat šifrované cookies.
-
Já si s chutí kopnu do jakékoliv Electron aplikace, protože Electron je prostě bullshit. Psát desktopové aplikace v prohlížeči, který se pak přibaluje je nejenom overkill, ale způsobuje to problémy, na které kvůli abstrakci/abstrakcím nelze dohlédnout viz přesně tento problém.
To že MS použil Elektron pro Teams je prostě, chybný výběr technologie.
Mimochodem právě MS se snaží Elektronu zbavit a nahradit ho svým řešením (i v Teams), ale moc mu to nejde (viz Teams 2.0). -
Filip JirsákStříbrný podporovatel
Kopat si můžete, jak chcete. Což nic nemění na tom, že je to jeden z mála způsobů, jak psát desktopové multiplatformní aplikace. Je to v dnešní době zdaleka nejjednodušší způsob, a když ta aplikace existuje i jako webová aplikace, je to ještě daleko větší úspora.
Spousta desktopových aplikací by bez Electronu vůbec neexistovala. Tak pokud se vám ty aplikace nelíbí, prostě si představte, že ta aplikace vůbec neexistuje, nepoužívejte ji – a budete to mít stejné, jako kdyby Electron neexistoval.
Já bych se místo dštění síry na Electron zabýval tím, proč neexistuje něco lepšího, než Electron, když je Electron taková hrůza.
Jinak souhlasím s tím, že renderovat GUI aplikace pomocí jazyka pro formátování dokumentů je padlé na hlavu. Vyndat ten renderer z prohlížeče, vyndat z něj javascriptový engine a osamostatnit ho, a pak ten osamostatněný engine a prohlížeč zase poslepovat dohromady a psát desktopové aplikace v tom je padlé na hlavu na třetí. Ale to není chyba těch technologií, je to chyba toho, že nikdo neudělal nic lepšího. -
Protože to je požadavek na létající ponorku, buť to umí létat nebo plavat nebo ani jedno z toho. Můžu mít společné jádro a potom platformově závislá rozhraní, dohromady multiplatformí aplikaci. Nebo obludu která jde nějak spustit všude při nejhorším přez nějaký emulátor ovšem potom můžu jen těžko využít přednosti jednotlivých platforem zato budu určitě sdílet nedostatky. Že by pak některé aplikace pro desktop neexistovali? Vždyť vlastně v žádné desktopové verzi neexistují, akorát jdou jako by dektopově spustit, stejně jako hry s přibaleným dosboxem. Někdy to stačí, ale jako systémové řešení s efektivním využitím zdrojů?
-
Internetové aplikace je takový zajímavý novodobý trend. Problém je v tom, že firmy, které mají deset tisíc uživatelů/stanic z nichž je 99% bfu bez možnosti instalovat si vlastní aplikace, či je jakkoliv aktualizovat na novější verze, buď musí vyřešit distribuci podnikové aplikace na všech těchto 10tis zařízení, nebo použít nějakou aplikaci v prohlížeči.
Navíc některé společnosti vás ani na desktop nepustí. Respektive poustí, po té co každá verze aplikace prochází tři měsíce bezpečnostním auditem... a někdy třeba taky neprojde.Tedy buď udržovat desktop aplikaci v chodu se všemi neduhy které to přináší. Na 80% se to udělá samo skriptem, k 15% musí někdo zajít, dotáhnout to ručně přičemž zbylých 5% se úplně zhroutí a je nutná kompletní přeinstalace. To vše musí udělat admin, který má potřebná oprávnění a navíc to musí udělt co tři měsíce (kdy vychází nové verze). Přičemž kdykoliv může nějaký antivir nebo nějaké vnitřní bezpečnostní oddělení prohlásti aplikaci za nebezpečnou a nedovolit ji instalovat - např. kvůli log4j zranitelnosti, kterou nemáte zapnoutou, ale oni tomu nevěří atp...
A nebo to bude nějaká "hnusná" elektronová aplikace, o kterou se nikdo nemusí starat.
-
Jen doplním, že narozdíl od mnoha jiných Electronových aplikací má webová verze Teams má své využití. Např. když spolupracujete s více firmami a desktopová neumí víc jak jeden účet (webovou můžete mít v různých prohlížečích, v každém s jiným přihlášeným účtem). A taky se přidám: proč někdo teda nepřijde s něčím lepším než Electron? PS: Microsoft přepisuje náročné části Teams do nativního kódu (C/C++) a má i odlehčenou verzi Teams Lite.
-
Trochu upřesním situaci na Windows (jinde to bude určitě podobné), aplikace může použít Data Protection API (C-čkové funkce CryptProtectData a CryptUnprotectData) pro zašifrování tokenů, hesel, klíčů apod, které pak uloží na disk.
K šifrování a dešifrování takto uložených dat se používá klíč odvozený od přihlašovacích údajů k Windows účtu. To má výhody a nevýhody: Jedno heslo/pin/obličej/FIDO token/smart card chrání všechna ostatní hesla, stejně jako u různých klíčenek a správců hesel. Jiný uživatel (Windowsí uživatelský účet, například na stejném počítači třeba v doméně) nemá přístup k mému klíči. Data lze dešifrovat i po vypnutí aplikace (tady např. MS Teams), i po vypnutí počítače. Jakákoli aplikace spuštěná pod stejným uživatelským účtem může data dešifrovat, takže třeba i virus, to ale platí i pro různé FireFoxy a KeePassy. Data nelze dešifrovat vyndáním hard disku z počítače a otevřením v jiném počítači, nebo odesláním zašifrovaného souboru jinam (bez znalosti Win přihlašovacích údajů a možná i trusted platform modulu, u toho TMP si nejsem jistý).
-
Filip JirsákStříbrný podporovatel
Tak se nám tu sešel pěkný výčet technologií, které vůbec nic neřeší. Ano, máme tu různé technologie, které umožňují jakékoli aplikaci uložit heslo a pak jakékoli jiné aplikaci to heslo zase získat. Což je přesně to, co jsem psal na začátku – jedna možnost je heslo/klíč uložit v otevřeném tvaru, takže půjde získat úplně bez práce; nebo ho trošku schovat, třeba zašifrovat klíčem, který bude uložený hned vedle, v aplikaci, nebo nějak podobně.
Klíčenka odemykaná uživatelským heslem je chráněná proti tomu, kdyby někdo získal jenom disk, nebyl v běžícím systému – ale proti takovému útoku chrání lépe šifrování disku, které ochrání i další citlivé údaje, ne jen hesla.
Pokud by se někdo myslel, že klíčenka vydá heslo/klíč jenom té správné aplikaci – na Linuxu/Windows/MacOS není na úrovni OS zaručená identita aplikace. Klíčenka nemá jak zjistit, zda o heslo žádá „ta správná“ aplikace. Což poznáte např. podle toho, že aplikaci zaktualizujete, tj. je to jiná aplikace, ale klíčenka jí heslo stejně bez problémů vydá. A co se asi stane, když vám tu aplikaci „zaktualizuje“ útočník?
-
Čítaj čo tu píšeme... pretože kecáš nezmysli, o ktorých nič nevieš.
Žiadne heslo ku keyringu v počítači v čitateľnej podobe nemám uložené.
> Klíčenka odemykaná uživatelským heslem je chráněná proti tomu, kdyby někdo získal jenom disk, nebyl v běžícím systému
A v čom je to ako problém? Jednoducho stačí aby keyring bol otvorený v rámci systému ale stále môže byť neprístupný pre jednotlivé aplikácie... navyše môžeš ju mať dokonca nastavenú tak že po každom použitý sa automaticky zamkne, a že bude poskytovať len heslo ku konkrétnej aplikácii. Navyše, aj keby tomu tak nebolo a aplikácia by bola škodlivá, nie je to jedno? Však si to heslo škodlivým správaním získa aj inými spôsobmi než z keyringu?
16. 9. 2022, 15:32 editováno autorem komentáře
-
Na to, aby ta klíčenka vydala heslo aplikaci, je pořád potřeba trochu více, než mít read only přístup na disk. Ano, pokud si tam někdo už pustí nějaký proces pod svým uživatelem, tak ho nezachrání. Ale dovedu si představit hromadu jiných zranitelností, díky kterým je možné číst soubory na filesystemu, ale na získání hesla z klíčenky je to málo.
(Ono když už tam běží infikovaný proces pod daným uživatelem, tak nepomůže ani třeba ten keepass, protože tomu procesu stačí v tu chvíli monitorovat schránku a má to heslo taky...)
-
Filip JirsákStříbrný podporovatel
Jenže tohle je úplně špatný přístup k bezpečnosti. „Dovedu si představit, že když ten lupič bude na vozíčku, ruku v sádře, šátek přes oko a bude neděla a banka bude zavřená, tak tu banku nevyloupí“. Ne, bezpečnost se opravdu neřeší tak, že si představím co nejneschopnějšího útočníka.
Například pro spoustu uživatelů bude stačit možnost číst soubory z disku i na prolomení té klíčenky. Protože prostě mají tak slabé heslo, že ho hrubou silou uhádnete.
Zajímalo by mne, jestli třeba takový Firefox používá pro ukládání uživatelských dat (cookies, local-storage apod.) ty funkce zajišťující alespoň šifrování klíčem uživatele. Dříve se dal uživatelský profil ve Firefoxu přenášet mezi počítači prostým kopírováním soubor, to už dnes nejde? Pokud to jde, pak jste na tom při použití Teams ve Firefoxu úplně stejně, jako při použití té Electronové aplikace.
-
Ve chvíli, kdy si uživatel pustí na počítači nějaký závadný proces, tak se může stát hromada škod a těžko tomu lze zabránit... ale upřímně, říkat, že tohle je špatný přístup k bezpečnosti, který zamezí alespoň poměrně velkému počtu zranitelností a na druhou stranu obhajovat, že je úplně v pohodě mít ty nešifrovaná data na disku, protože když si tam uživatel pustí proces, co je z té klíčenky dostane a protože má stejně blbé heslo, co každý uhodne, to jde tak trochu proti sobě :-)
-
Filip JirsákStříbrný podporovatel
Co jde proti sobě? Pokud uživatel spustí pod svým účtem závadný proces, klíčenka ho neochrání. Klíčenka (s dostatečně silným heslem) ho na rozdíl od nešifrovaného souboru ochrání, pokud útočník bude mít možnost číst libovolné soubory z disku uživatele, ale nedokáže spouštět procesy.
A teď si řekněme, jak časté jsou zranitelnosti umožňující číst libovolný soubor uživatele, které ale neznamenají spuštění útočníkova kódu. Opravdu je to v porovnání se spuštěním útočníkova kódu tak častý případ, aby dávalo smysl extra se proti tomuto útoku chránit? Já si to nemyslím, protože podle mne je těch případů „vzdáleného čtení“ velmi málo.
-
Filip JirsákStříbrný podporovatel
Ono je hlavně dost hloupé, že je schválen příspěvek, jehož první půlka je ničím nepodložený osobní útok a druhá je off topic.
-
Statistiky na to nemám, takže ano, nemůžu posoudit, jestli se vyplatí nebo nevyplatí na tenhle jeden případ dělat extra ochranu. Taky je pak ještě otázka, jak jsou u těch electronových aplikací nastavena oprávnění - pokud ten soubor s cookies má read pro všechny, tak stačí, když ty soubory na disku bude moci číst i cokoliv jiného pod jiným uživatelem.
Pokud si uživatel pustí závadný proces na svém systému, tak jak jsem psal, ani ta heslová klíčenka s dostatečně silným heslem ho nezachrání. Protože uživatel to typicky z ní pak kopíruje přes clipboard, což už zase ten spuštěný proces může monitorovat (tedy je to ve výsledku stejně na prd, jako ta klíčenka v gnome)
-
Filip JirsákStříbrný podporovatel
Ty soubory MS Teams jsou v domovské složce uživatele, která má oprávnění
0700. Pokud by do ní měl oprávněníxněkdo jiný, byl by to daleko větší problém, než jeden čitelný token.Použití klíčenky by bylo takové, že v ní má aplikace uložený šifrovací klíč, a získá ho bez zásahu uživatele. Jde o to, že komunikační aplikaci jako MS Teams typicky chcete nastartovat automaticky po přihlášení, abyste mohl přijímat notifikace. A nikdo nechce po přihlášení zadávat hesla do X komunikačních programů. Proto všichni řeší, jak to udělat bez zásahu uživatele. Což právě nejde moc bezpečně udělat, když všechny aplikace běží pod stejným uživatelským účtem, takže se mohou navzájem ovlivňovat nebo podvrhnout svou identitu.
-
Filip JirsákStříbrný podporovatel
To, že zamezíte přístupu na nadřazeném adresáři, je základní koncept unixových oprávnění. Jinak by jen s oprávněními uživatel-skupina-ostatní těžko mohla fungovat spolupráce více uživatelů. Home je specifický tím, že tam je počet dalších uživatelů nula, ale proč to řešit jiným způsobem, když ten obecný funguje také?
-
> Ne, bezpečnost se opravdu neřeší tak, že si představím co nejneschopnějšího útočníka.
> Například pro spoustu uživatelů bude stačit možnost číst soubory z disku i na prolomení té klíčenky. Protože prostě mají tak slabé heslo, že ho hrubou silou uhádnete.
rovnako sa nerieši bezpečnosť tak že si predstavíte najneschopnejšieho usera.... alebo od dnes nebudeme v autách inštalovať bezpečnostné pási, airbagy, pri cestách nebudú dopravné značky a nebudú zákony a neviem čo, lebo jeden človek si medzi airbag a svoje telo dal nôž nasmerovaný na svoje telo, nezapol si pás, rozjel sa 300km/h a napálil schválne do zdi a umrel? A tým argumentuješ že Airbag, bezpečnostný pás, dopravné značky atď sú zbytočné?
16. 9. 2022, 17:09 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
rovnako sa nerieši bezpečnosť tak že si predstavíte najneschopnejšieho usera
Ale řeší. Protože se řeší vždy ta horší varianta. Když totiž vyřešíte horší variantu, máte pokrytou i tu lepší.A tým argumentuješ že
Ne, to je váš úplně zcestný příklad. Já jsem nic takového netvrdil. -
Takže nedáva logiku zamykať auto alebo dom, však niekto môže sa vlámať aj tak, možno rozbiť sklo, alebo rovno prekopať sa do domu.... Zaujímavá úvaha...
Počítať s najhoršou variantov nedáva logiku, lebo takej sa prakticky zabrániť nedá... ak používateľ urobí čokoľvek aby bezpečnosť sabotoval, tak tomu fakt nepomôže nič. A neexistuje pojem "úplne eliminované riziko"... a vlastne v takom prípade je čo bezpečné? Čo ak je škodná priamo v systéme, čo ak priamo v hardwary, a čo ak si v matrixu a škodná je rovno v tvojom mozgu? (to neurážam, myslím ako príklad).. jak ty ako človek vieš tomu zabrániť? Nijako... Cieľom nieje úplná eliminácia rizika, ale zredukovanie.... zredukovanie na toľko aby pre útočníka bol daný target "nazaujímavý". Tzv. keby napadnutie stroja stálo viac než čo z toho získa, tak sa útočník ani taký systém neskúsi napadnúť (zväčša, nehovorím že je to pravidlo, záleží čo je cieľom útočníka, či zisk alebo výzva). Všeobecne ale každá prekážka, ktorá obmedzuje útočníka je plusom pre zabezpečenie.
-
Filip JirsákStříbrný podporovatel
Takže nedáva logiku zamykať auto alebo dom, však niekto môže sa vlámať aj tak, možno rozbiť sklo, alebo rovno prekopať sa do domu.... Zaujímavá úvaha...
Hlavně se nezapomeňte pochválit, jakou zajímavou úvahu jste napsal. Já na ní nic zajímavého neshledávám. Auto nebo dům se zamyká proto, že ukrást zamčené auto je výrazně složitější, než ukrást odemčené auto. To samé s domem.Počítať s najhoršou variantov nedáva logiku, lebo takej sa prakticky zabrániť nedá...
Počítá se s nejhorší variantou, u které ještě předpokládáte, že se útočníkovi vyplatí.Všeobecne ale každá prekážka, ktorá obmedzuje útočníka je plusom pre zabezpečenie.
Ne, tohle je právě při zabezpečování ta největší chyba. Někdo vrší a vrší další chabé překážky, přitom kdyby věnoval stejnou energii pořádnému zabezpečení, dosáhl by daleko lepšího zabezpečení. Každá překážka, která je stejně slabá nebo ještě slabší, než jiná překážka v řadě, je k ničemu, je to jenom plýtvání zdroji. -
Filip JirsákStříbrný podporovatel
Škoda, že tu radost, že jste něco pochopil, nedopřejete ostatním i vy. Problém je v tom, že když má útočník přístup k uživatelově účtu, obelstít uživatele tak, aby mu nepomohla ani klíčenka, je triviální. Když to chcete přirovnávat k zamykání auta, je to jako kdybyste měl na výběr dvě dobře střežené garáže, obě na stejné úrovni zabezpečení, v obou by byl hlídač – ale hlídač v jedné garáži by trval na tom, že mu musí každý při odjezdu pokynout rukou. A vy byste tvrdil, že tahle garáž je mnohem lepší, protože když útočník překoná všechny nástrahy zabezpečení té garáže, pořád ještě musí překonat vrátného pokynutím ruky.
-
[Filip Jirsak]
K sifrovani disku - Ano, ale to se vyplati jen tam kde, takove riziko realne hrozi. Doma kvuli nekolik slozkam s pornem se urcite sifrovani nevyplati, ale kdyz je nekdo paranoik - proc ne?* Zas na druhou stranu, ukrast disk napr ve firme muze byt samo o sobe znacne rizikove. Mnohem nenapadnejsi a jednodussi muze byt ukrast pristup. A jak jsem psal vyse, zazil jsem uz dost firem kde meli nastavenou bezpecnosti politiku moc benevolentne, nebo zas az moc prisne. Oba extremy pripadnemu "zlodeji" vsak nahravaji do karet.K vydani klice. To je o tom co jsem se snazil rici vyse. Obecne se da rici ochrana, nebo chcete-li bezpecnostni politika - vzdycky znamena nejaka omezeni. V tomto pripade radeji vybirat potrebny klic v potrebnou dobu a sam jej predat do dane aplikace. Jenze jak jste mohl cist : "kdo to bude delat?" No, jo ale pak at nechodeji brecet.
Bezpecnost i vazeni rizika by se meli delat s rozumem. Strach (paranoia) a lenost jsou spatni radci.
* Myslim, ze domacim desktopum vic hrozi nebezpeci utoku ze site, nez to ze nekdo odcizi hadr. Tedy pokud nejste generalni reditel nadnarodniho zbrojarskeho koncernu....
16. 9. 2022, 21:54 editováno autorem komentáře
-
>Pokud by se někdo myslel, že klíčenka vydá heslo/klíč jenom té správné aplikaci – na Linuxu/Windows/MacOS není na úrovni OS zaručená identita aplikace. Klíčenka nemá jak zjistit, zda o heslo žádá „ta správná“ aplikace.
Tak právě na macOS je identita a integrita aplikace řešená digitálním podepisováním a notarizací aplikace.
Ale navíc vám prozradím, že do klíčenky můžete uložit COKOLIV, takže třeba zašifrované heslo už vaší aplikací. Takže, kdo by ho chtěl použít musí vědět, jak daná aplikace toto heslo před uložením do klíčenky šifruje.
-
Filip JirsákStříbrný podporovatel
Tak právě na macOS je identita a integrita aplikace řešená digitálním podepisováním a notarizací aplikace.
Jenže to se týká jen aplikaci instalovaných oficiálním distribučním mechanismem. Zrovna Microsoft Teams se ale neinstalují ani přes AppStore.Takže, kdo by ho chtěl použít musí vědět, jak daná aplikace toto heslo před uložením do klíčenky šifruje.
Ano, to je ukázkový příklad Security through obscurity, což je obecně považováno za špatný způsob „zabezpečení“. Přičemž když už někdo zvolí tuto cestu, nepotřebuje k tomu žádnou klíčenku.Ale je to stejné, jako s hashováním hesel – z hlediska PR je nejlepší data takhle nějak jednoduše zašifrovat klíčem zapsaným natvrdo ve zdrojovém kódu aplikace. Předejde se tím těmhle článkům „ó hrůza, aplikace ukládá klíč v otevřeném tvaru“, bezpečnost se tím nijak významně nezvýší a implementačně je to jednoduché. Nákladově to nejde za bezpečnostním týmem ale za marketingovým :-)
-
>>Tak právě na macOS je identita a integrita aplikace řešená digitálním podepisováním a notarizací aplikace.
>>Jenže to se týká jen aplikaci instalovaných oficiálním distribučním mechanismem. Zrovna Microsoft Teams se ale neinstalují ani přes AppStore.Nikoliv. To se od macOS 10.15 týká VŠECH aplikací.
Pokud nějaká aplikace není podepsaná a notarizovaná, vyskočí na uživatele upozornění, že jde o nedůvěryhodnou aplikaci.Teams nelze nahrát do AppStore právě z důvodu, že je Electron-based.
19. 9. 2022, 12:38 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Týká se to VŠECH aplikací, s výjimkou těch, kterých se to NETÝKÁ.
Nevím zda se to týká jen aplikací instalovaných do /Applications, instalovaných z balíčku nebo kterých přesně. Zato ale vím, že když si vyrobím v home spustitelnou binárku, té se to netýká.
-
Gatekeeper má viacero fičúr - podpis, sandbox, hardening, notarizácia. Pre každú binárku niektoré fičúry môžu byt povolené, niektoré nemusia. Aplikácie, ktoré nie sú podpísané, majú svoj život trocha ťažší, napríklad je používateľ pri prvom spustení buzerovaný a musí explicitne potvrdiť, že ju naozaj chce spustiť (to je ten pravý klik na aplikáciu - spustiť - potvrdiť spustenie).
A potom, bez ohľadu či je podpísaná alebo nie, je odoslaný hash binárky do Apple a vráti sa info, či je možné ju spustiť alebo nie. Zase, dá sa z toho dostať von, keď používateľ dá aplikácii práva "Developer Tools".
-
Smazaný profil
To Jirsak: To jste nikdy nevidel zadnou aplikaci na hesla se sifrovanou databazi, ktera se odemkne jen po zadani master hesla? Linux i mac maji take klicenky chranene heslem a dokonce uz i windows se pomalu zacinaji inspirovat a maji jakouz takouz obdobu.
A nevim co je tak nebezpecnyho a nedomysleneho na tom, ze kdyz chci, aby se software prihlasil, tak se autorizuu v trezoru a heslo se vyplni.
To se neda vubec srovnavat s tim, ze MS Teams uklada tokeny jako obycejny text.
Je videt, ze jako vzdy nevite o cem mluvite… protoze v tech klicenkach se k heslu nedostane kdekdo, ale jen to co zna master heslo. -
Filip JirsákStříbrný podporovatel
To jste nikdy nevidel zadnou aplikaci na hesla se sifrovanou databazi, ktera se odemkne jen po zadani master hesla?
Jasně, vůbec o takové možnosti nevím, proto jsem ji také ve svém komentáři zmínil.protoze v tech klicenkach se k heslu nedostane kdekdo, ale jen to co zna master heslo
Jasně, takže vy nějaké aplikaci (třeba teoreticky těm MS Teams) řeknete master heslo ke své klíčence, ta aplikace si pak z klíčenky vezme jenom svoje heslo a svatosvatě vám odpřisáhne, že žádné jiné heslo z klíčenky určitě nevytáhne. Takhle nějak jste si to představoval?Je videt, ze jako vzdy nevite o cem mluvite…
No, zatím to vypadá, že vy jste nikdy žádnou softwarovou klíčenku neviděl. -
> protoze v tech klicenkach se k heslu nedostane kdekdo, ale jen to co zna master heslo
Jasně, takže vy nějaké aplikaci (třeba teoreticky těm MS Teams) řeknete master heslo ke své klíčence, ta aplikace si pak z klíčenky vezme jenom svoje heslo a svatosvatě vám odpřisáhne, že žádné jiné heslo z klíčenky určitě nevytáhne. Takhle nějak jste si to představoval?áno, pretože môžeš mať viacero sväzkov, a master heslo odomkne len jeden zväzok, ak to máš tak nakonfigurované, a teda aplikácia aj tak nebude mať možnosť si zobrať iné heslo (resp. heslá z iných zväzkov, ale len z toho jedného konkrétneho zväzku, ak si teda vytvoríš osobitne zväzok len pre software od Microsoftu, tak iné aplikácie než tie od Microsoftu k tomu nebudú mať prístup a naopak software od Microsoftu nebude mať prístup k iným zväzkom)...
navyše aplikácie si neberú heslá, ono to nie je tak že aplikácia číta z keyringu, ale naopak, password manager ponúka heslá aplikáciám. Tzv. heslo si nepýta aplikácia, ale dostane jedno konkrétne z keyringu.
16. 9. 2022, 17:54 editováno autorem komentáře
-
KateStříbrný podporovatel
ta aplikace si pak z klíčenky vezme jenom svoje heslo a svatosvatě vám odpřisáhne, že žádné jiné heslo z klíčenky určitě nevytáhne
Tohle třeba řeší org.freedesktop.portal.Secret
-
Filip JirsákStříbrný podporovatel
Ano, pokud aplikace běží v nějakém kontrolovaném prostředí, které je schopné zaručit identitu aplikace, tam takovéhle věci mohou fungovat. Proto jsem psalo o Linuxu/Windows/macOS. Třeba na Androidu nebo iOS je operační systém schopen zajistit identitu aplikace, takže tam aplikace může mít výhradní přístup k něčemu. Na desktopových OS jsou také taková prostředí. Ale když si někde nainstaluje MS Teams do domovského adresáře, není žádná šance, jak zjistit, jestli MS Teams, který chce přístup k datům příště, je ten správný MS Teams (jenom třeba zaktualizovaný), nebo je to podvodná aplikace.
16. 9. 2022, 19:15 editováno autorem komentáře
-
V Linux vs Android ako package manager vs Google play store je istým spôsobom to isté? Rovnako dôveryhodné zdroje aplikácií?
Ale hájiť nepoužívanie keyringu resp. password managera, lebo je tu možné že aplikácia je podvrhnutá je ako keby som odstránil hasiace prístroje z miestnosti, lebo ak sa oblejem benzínom a zapálim a nebudem sa hasiť a nikto nebude okolo, tak umriem, a kvôli tomu tvrdiť že hasiaci prístroj je zbytočný / nijako nepomáha je fakt nezmysel.
-
Filip JirsákStříbrný podporovatel
V Linux vs Android ako package manager vs Google play store je istým spôsobom to isté? Rovnako dôveryhodné zdroje aplikácií?
Rozdíl není ve správci balíčků, ale ve fungování operačního systému. Na linuxu se (obvykle) všechny aplikace spouští pod jedním uživatelem, takže aplikace nemá žádné "svoje" soubory. Třeba soubory prohlížeče (nebo electronových Teamsů, což je to samé v bledě modrém) může číst třeba kalkulačka nebo jakýkoli jiný program. Naproti tomu na Androidu má každá aplikace svůj vlastní účet, takže má svoje soubory, které nikdo jiný číst nemůže. Pak jsou sdílená úložiště, přes která si aplikace mohou vyměňovat soubory (např. dokumenty), ale k tomu už je potřeba speciální oprávnění. A ještě vyšší oprávnění je potřeba pro možnost lézt do souborů jiných aplikací (což může potřebovat třeba správce souborů - a většina uživatel nemá důvod něco takového používat).Pak je tu samozřejmě pořád problém s tím, co je jedna aplikace - aby identita aplikace byla zachována napříč aktualizacemi a zároveň nebylo triviální ji podvrhnout. V tom je opět rozdíl, že u běžného mobilu je Play STore nebo APple STore jediný způsob, jak dostat aplikaci do systému, zatímco na linuxu je spousta aplikací, které (z rozumných důvodů) správce balíčků obcházejí.
Ale hájiť nepoužívanie keyringu resp. password managera
Nic takového jsem ovšem já nepsal. Navíc mezi správcem hesel a klíčenkou je velmi podstatný rozdíl - v případě správce hesel je to uživatel, kdo iniciuje získání hesla, v případě klíčenky je to aplikace a je snaha dělat to co nejméně rušivé. -
Skutočne? Napríklad SNAPs môžu čítať len a len z adresára, ktorý mu poskytne skrz environmentálnu premennú s názvom $SNAP_DATA, jehož hodnota je zvyčajne niečo ako /var/snap/hello-world/common a v takom prípade aplikácia `hello-world` nevie zapisovať do žiadneho adresára, ani zo žiadneho čítať s výnimkou práve toho jedného. Viem to lebo som to sám implementoval už v desiatkách aplikácií... samozrejme SNAP môže čítať aj iné adresáre v prípade že mu nastavíš plugs a slots na prístup k FS. Alebo ak je SNAP nainštalovaný s `--classic` prepínačom. Ale to už musí explicitne urobiť používateľ. Istým spôsobom je to podobné Androiďáckemu Play, pretože plugs a slots sú v podstate obdoba manažmentu oprávnení, kedy máš oprávnenia nutné, a dobrovoľné.. tie nutné vidíš aké sú a ak nová verzia vyžaduje nové nutné oprávnenie tak je o tom používateľ upozornení a musí to odsúhlasiť, než môže v aplikácii pokračovať (ak sa rozhodneš že nechceš dať kalkulačke prístup k sieti či FS, tak to proste odmietneš), a dobrovoľné je čo sám môžeš ako používateľ aplikácii povoliť bez toho aby to aplikácia pýtala (zvyčajne nie je moc dôvod k tomu, s výnimkou keď to umožní nejakú pridanú funkcionalitu)
Podobné je to u Flatpak, kde máš namespace v tvare com.github.autor.app_name. A taktiež izolujú kam môže aplikácia sahať. Prístup má len k adresárom ~/.var/app/$FLATPAK_ID a $XDG_RUNTIME_DIR/app/$FLATPAK_ID. A podobne ako u SNAPu máš plugs a slots, tak vo Flatpaku máš Portals, pričom nad konfiguráciou má zas kontrolu používateľ.
U deb/apt/dpkg a rpm/dnf existujú taktiež mechanizmi ako zamedziť aplikácií čítať mimo zvolených adresárov, či pristupovať k rôznym komponentám/rozhraniam systému.
Rozhodne to nie je tak ako to tvrdíš ty.
17. 9. 2022, 12:17 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Ano, skutečně. Protože běžný uživatel linuxu nemá většinu aplikací nainstalovanou přes Snap nebo Flatpak.
-
Aspoň si to prečítaj celé... hovoril som aj o deb/apt/dpkg ako aj o rpm/dnf, aby som povedal bližšie tak u apt/dpkg máš tzv. profily, a síce defaultne sa inštaluje do core s plným oprávnením, aj tak môžeš hocikedy vytvoriť profil, ktorý bude mať obmedzené oprávnenia (ak to tak nakonfiguruješ) ako aj je možné sandoboxovať balíčky rôznymi inými riešeniami, trebárs FireJail (aj s AppArmor podporou).
Zas sa len vyhováraš a ani nečítaš čo píšem... Sám furt napádaš iných za to že druhú polovicu nedočítal a robíš to isté...
Inak k SNAP a Flatpak, nevidím dôvod prečo by bežný používateľ to nepoužil, ak chce mať sandboxované balíčky a bezpečnosť...
zas riešime skupinu ľudí, čo jazdia na aute 300km/h a tvrdíš že dopravná značka obmedzujúca rýchlosť je k ničomu, lebo však šofér môže tú rýchlosť prekročiť.
-
Ne, že bych chtěl pana Jirsáka hájit protože s ním se bavit skutečně moc nemá cenu jakkoliv jeho názory zrovna na tuhle problematiku mi výjimečně nepřijdou úplně mimo, ale problém ve vaší tezi spočívá, domnívám se, v tom " nevidím dôvod prečo by bežný používateľ to nepoužil, ak chce". Běžnému uživateli alespoň tak, jak ho znám já jsou totiž nějaké sandboxované balíčky a bezpečnost jedno jak placatej šutr.
A to nevyřeší žádný keyring ani nic jiného. Je to hezký příklad toho, že základem bezpečnosti (pokud nechcete sklouznout do toho šíleného androidového fašismu) jsou prostě uživatelé, co vědí, která bije.
-
BobTheBuilderStříbrný podporovatelBěžnému uživateli alespoň tak, jak ho znám já jsou totiž nějaké sandboxované balíčky a bezpečnost jedno jak placatej šutr.
Běžnej Franta Uživatel vůbec netuší, o co jde, a k čemu by to bylo dobré. Takže si to ani nezapne a kdyby ho k tomu někdo přiměl, zjistí, že se mu práce zkomplikovala a rychle od toho uteče.
Pokud by v systému měla být bezpečnost takto udělána, musí být nevypnutelná. Tomu se snad blíží IpadOS. Má to ovšem trošku vadu, předávání dat mezi aplikacemi je komplikovanější a tvůrcům to projde snad jen u Applu. A tam to je, řekl bych, značnou překážkou ve snaze iPadem nahradit běžný notebook.
Nicméně použití nějakého keyringu pro ukládání by mělo být samozřejmostí všude - i když to jde na vrub spíš vývojářům než operačním systémům.17. 9. 2022, 16:53 editováno autorem komentáře
-
Ako blbec nevyzerám, lebo o tom práve hovorím... Linux ani nedovolí vytvoriť root účet bez hesla by default... a teda ani do GNOME či KDE keyringov, ktoré sú práve viazané na login... a minimálne Ubuntu to heslo vyžaduje,.... dá sa odstrániť len tým že použije určité príkazy v terminály a zmení pár konfiguračných súborov, čo je práve sabotáž... to fakt nevedome človek neurobí. Rovnako nevedome človek nenainštaluje aplikáciu (akúkoľvek, nie len škodnú).
-
Filip JirsákStříbrný podporovatel
Ako blbec nevyzerám, lebo o tom práve hovorím... Linux ani nedovolí vytvoriť root účet bez hesla by default...
Linux (jádro) nedovolí vytvořit root účet bez hesla? Jak jste na to přišel? Ono linuxové jádro podle vás root účet nějak vytváří?Pokud má uživatel perfektně prověřené všechny aplikace, které používá, a ještě je má oddělené, aby jedna aplikace nemohla číst data jiné aplikace - jak jste psal výše - čemu pak vadí to, že aplikace má nešifrovaný klíč uložený mezi svými daty (která nemůže ani nechce číst nikdo jiný)?
-
"Linux (jádro)..."
zas a znova... z kontextu je jasné že hovorím o GNU/Linux a nie o jadru.... Ešte som aj zmienil Ubuntu.... ale ešte sa nestalo že by si v diskusii schválne neslovíčkaril a nesnažil sa nájsť chybu vo formulácii vety, len aby si si presadil svoj názor.
Asi musím písať takto:
"
Ako blbec nevyzerám, lebo o tom práve hovorím... GNU/Linux (operačný systém, resp. väčšina distier, nie jadro samotné) ani nedovolí vytvoriť root účet (resp. účet s názvom root) bez hesla (resp. s prázdnym políčkom pre heslo) by default... a teda ani do GNOME či KDE keyringov, ktoré sú práve viazané na login (heslo)... a minimálne Ubuntu to heslo vyžaduje,.... dá sa odstrániť len tým že použije určité príkazy v terminály (softwarovom, nie hardwarovom) a zmení pár konfiguračných súborov (vo filesysteme), čo je práve sabotáž... to fakt nevedome človek neurobí. Rovnako nevedome človek nenainštaluje aplikáciu (akúkoľvek, nie len škodnú).
"Už lepšie? Už sa chápeme?
-
Filip JirsákStříbrný podporovatel
zas a znova... z kontextu je jasné že hovorím o GNU/Linux a nie o jadru....
Bylo jasné, že jste napsal hloupost – já jsem jen vstřícně vůči vám předpokládal tu menší hloupost. Dobře, takže vy jste myslel GNU/Linux, což zase neznamená vůbec nic, ale vy tím myslíte všechny linuxové distribuce. Jenže se opět mýlíte – není pravda, že by se všechny linuxové distribuce chovaly stejně.Ešte som aj zmienil Ubuntu....
Ubuntu jste zmínil v jiné souvislosti. A to, že něco dělá Ubuntu, opravdu neznamená, že to tak dělají všechny distribuce.ale ešte sa nestalo že by si v diskusii schválne neslovíčkaril a nesnažil sa nájsť chybu vo formulácii vety, len aby si si presadil svoj názor.
Ono jde spíš o to, že píšete o věcech, kterým nerozumíte. Takže vaše nepřesné tvrzení je nepravdivé, akorát se pak složitě dobíráme toho, v čem přesně je nepravdivé.Už lepšie? Už sa chápeme?
Chápeme se od začátku – píšete o něčem, čemu nerozumíte.rootúčet, tedy účet suid=0, se totiž nijak nevytváří – ten účet je zadrátovaný přímo v jádru. Vy jste asi myslel to, že Ubuntu při standardní instalaci nedovolí pokračovat, dokud účtu root nenastavíte heslo. Což je ale něco úplně jiného, než jste napsal.Už to chápete?
-
KateStříbrný podporovatel
Některé distribuce se už začínají k Flatpaku (V případě Ubuntu Snapu) jako k defaultnímu zdroji aplikací přiklánět, mimo jiné právě kvůli vyšší bezpečnosti, kterou může poskytnout (A současně to je pohodlnější pro distributory uzavřených aplikací, MS Teams se k tomu vyloženě nabízí). Pokud vím, větší kontrolu nad aplikacemi je možné zařídit i na Macu a Windows, i když ta prostředí neznám tak dobře.
Jasně, asi se neubráníme tomu, aby aplikace měly nějaký fallback pro uchování secrets. Ale začít používat i mechanismy, které operační systémy poskytují, pokud jsou k dispozici, by bylo fajn.
Jinak i tak preferuju použití centrální klíčenky před souborem pohozeným kdoví kde. Pak se se nemůže tak snadno stát, že nějaký secret leskne omylem při tvorbě zálohy nastavení a podobně.
19. 9. 2022, 17:01 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Ale začít používat i mechanismy, které operační systémy poskytují, pokud jsou k dispozici, by bylo fajn.
Ony se začínají používat, jenom to zkrátka nějakou dobu trvá – zejména když se to musí řešit pro každý OS zvlášť, v Linuxu ještě pro každé DE zvlášť a kdo ví, jestli se to neliší i napříč distribucemi.Navíc v tomhle případě je to věc Electronu. Vzhledem k tomu, že jsou to HTTP only cookies, aplikace ani nemá možnost to změnit, pokud se nemá změnit komunikační vrstva (kterou zase mohou používat i jiní klienti).
Jinak i tak preferuju použití centrální klíčenky před souborem pohozeným kdoví kde. Pak se se nemůže tak snadno stát, že nějaký secret leskne omylem při tvorbě zálohy nastavení a podobně.
S tím souhlasím. Akorát že to, že to tak není, podle mne není důvodem vydávat o tom zprávičku jako o chybě. Ani tady, ani na Arstechnica. Řeší se to jenom proto, že je to aplikace od Microsoftu. -
Tohle ani pořádně vyřešit nejde pokud chcete mít pohodlí v automatickém přihlášení. Aby to nějak fungovalo, musel by OS poskytnout přes API klíčenku, která by byla někde uložená (hw čip, šifrovaný soubor), ale vydala heslo jen autorizované aplikaci a na správném stroji a tady je zase problém jak poznat že se jedná o tu správnou aplikaci a ne někoho jiného? Leda ji podepsat klíčem z OS/TPM? Netuším.
Pokud někdo o něčem spolehlivém ví, sem s tím. -
Filip JirsákStříbrný podporovatel
Netuším, jak jste přišel na to, že prý nemám rád macOS. Každopádně tu vidím třeba v adresáři
/opt/homebrewskripty a binárky, o kterých si nemyslím, že by byly podepsané. Microsoft Teams nejsou instalované z AppStoru, ale jsou alespoň spořádaně nainstalované v/Applications, takže věřím, že systémový správce hesel může ověřit, co se spustilo. Jenže je to Electronová aplikace, navíc zrovna MS Teams mají možnost rozšiřování pomocí pluginů, takže jsem přesvědčený o tom, že chování té aplikace se může změnit, aniž by se změnil jediný bit na mém disku.No a protože Electronové aplikace jsou založené na jádru prohlížeče, proč se nepodívat přímo na prohlížeč? Ten soubor, kde jsou tokeny pro MS Teams, je obyčejná SQLlite databáze s cookies, stejná, jakou používají prohlížeče Chrome a další. Ty mají v aktuálních verzích hodnoty cookie šifrované, na MacOS se používá právě systémová klíčenka. A existují samozřejmě i utility na jejich dešifrování, které si samozřejmě přístup k té klíčence musí vyžádat. Jedna taková utilita je třeba zde: https://github.com/bertrandom/chrome-cookies-secure a vidíte tam i snímek obrazovky, jak vypadá ten dotaz na uživatele, zda chce povolit přístup ke klíčence. Byl by takový problém pro útočníka celé tohle spustit z procesu, který se nebude jmenovat "node", ale třeba "Microsoft Teams"? Nebo když někdo použije tenhle nástroj a zvolí "Always Allow", mají od toho okamžiku ke klíčence Chrome přístup všechny aplikace spouštěné pod node.
A to se celou dobu bavíme o MacOS, což je jednolitý systém, autor aplikace se může spolehnout na to, že tam bude ta jediná systémová klíčenka, systémová klíčenka se zase může spolehnout na to, jak vypadají podpisy aplikací, pokud jsou nainstalované standardně do systému "the Apple way". Na linuxu je to daleko rozmanitější, klíčenek je víc, způsobů podepisování aplikací je víc...
-
Filip JirsákStříbrný podporovatel
Myslím si to proto, že tam žádný podpis nevidím
Vyrobil jsem binárku hello-world, který do konzole vypisuje "Hello World!". V terminálu jsem zadal příkaz
./hello-worlda do konzole se vypsalo: "Hello World!" Já bych to považoval za úspěšný pokus, vy ne? -
Osobně MS Teams nepoužívám, většině školám bych raději doporučil Jitsi. Vlastně ani pořádně nechápu, proč MS Teams existuje, měl jsem tu čest MS Teams používat... a znovu už prosím ne.
Opravdu daději Jitsi.
1. Spustit to lze na všem.
2. Je to stabilnější, rychlejší.
3. Není to bezpečnostní díra do počítače a nucení vyzrazovat data o studentech MS. -
Filip JirsákStříbrný podporovatel
Jitsi je ovšem jenom zlomek funkcionality MS Teams. Jitsi je nástroj pouze pro videohovory, MS Teams má chat (jako Slack), sdílení souborů a dokumentů, kalendář a spoustu dalších věcí, které se dají doplnit pomocí pluginů.
Že je Jitsi stabilnější a rychlejší se podle mne říct nedá – v době Covidu-19 jsem zkoušel hodně různých programů pro videokonference a Jitsi mi přišel subjektivně nejméně spolehlivý, nejvíc lidí mělo problém připojit se nebo nefungoval zvuk nebo obraz. Ale zkušenosti se asi můžou dost lišit, všechny tyhle nástroje na videohovory jsou dost závislé na konfiguraci sítě i daného zařízení.
-
L.Stříbrný podporovatel
Jako obvykle, řešení od MS je to nejhorší dostupné, ale z nějakého záhadného důvodu se prosadí :-/
-
Záhada jen pro neznalé :-)
Když školy mají O365 zdarma a učitelé objeví, že si mohou svou přípravu doma udělat na svém windows notebooku (hle: majoritní OS) a navíc žáci mají také najednou přístup k zadání i z domova (hle: majoritní OS), tak není divu, že se k tomu použije teams a ne např. Zoom. Protože by to byla zbytečná dovjí agenda... -
To je ovšem spíš smutné než cokoliv jiného. Protože Teams patří co se UI/UX týká mezi nejstrašnější kusy softwaru, keré jsem kdy používal (musel) a co se týká funkcionality, taky to není žádný zázrak; celkem pravidelně se mi stávalo, že mi zničehonic sletěly a podobně. Jako jo, je pravda, že co se videohovorů týká, patří k těm spolehlivějším, to ano. Je to ovšem, jak jsem jednou náhodou zjistil v pulseaudiu, tím, že je to dobře zabaléné jádro od Skype.
-
L.Stříbrný podporovatel
Ano, pokud jsi zkoušel jen Teams, tak jsou to nejlepší, co jsi zkoušel. Jinak je to hnus fialovej. Zlatej Slack.
-
Ptal jsem se v nekolika firmach. Obvykla odpoved byla: vedeni to zakoupilo. No a proc to vedeni zakoupilo? Protoze to uz meli v pocitaci spolu s Officy, znali to a po jinych moznstech se nepidili.
Teams je hnus fialovy. Mam poruznu vice uctu, ale nikdy nevim do ktereho se zrovna prihlasuju, protoze v tom maji bordel. Uzivatelske rozhrani je hruza, jednou je enter odeslani prispevku, jindy je enter novy radek, silene to zere ramky (dekuji elektrone) a z podivnych duvodu nemuzu posilat soubory.
