Euro-Office (Wikipedie) je evropský fork open source kancelářského balíku OnlyOffice. Za forkem stojí koalice firem IONOS, Nextcloud, Eurostack, XWiki, OpenProject, Soverin, Abilian a BTactic. Cílem je zajistit digitální suverenitu Evropy a snížit závislost na neevropských platformách. Projekt vznikl mimo jiné v reakci na nedávné uzavření cloudové služby OnlyOffice. OnlyOffice obviňuje Euro-Office z porušení licenčních podmínek. Na možné problémy upozorňuje i Collabora Online. Jednostranná změna licence není v pořádku.
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Během akce Arduino Days 2026 byl publikován Arduino Open Source Report 2025 (pdf) a oznámeno 7 nových produktů kompatibilních s deskou UNO Q (Arduino USB-C Power Supply, USB-C Cable, USB-C Hub, UNO Media Carrier, UNO Breakout Carrier, Bug Hopper, Modulino LED Matrix).
Google v pátek spustil v Česku Vyhledávání Live. Tato novinka umožňuje lidem vést plynulou konverzaci s vyhledávačem v češtině. A to prostřednictvím hlasu, nebo prostřednictvím toho, na co ukážou svým fotoaparátem či kamerou v mobilu. Rozšíření této multimodální funkce je možné díky nasazení Gemini 3.1 Flash Live, nového hlasového a audio modelu, který je od základu vícejazyčný, takže umožňuje lidem po celém světě mluvit na vyhledávač přirozeně a v jazyce, který je jim nejbližší.
Jsongrep je open-source nástroj, který efektivně prohledává JSON dokumenty (editovat je neumí). Kompiluje regulérní jazyk dotazu do podoby deterministického konečného automatu (DFA), díky čemuž prochází strom JSON dokumentu pouze jednou a je v tom tedy rychlejší než jiné nástroje jako jsou například jq, JMESPath nebo jql. Jsongrep je napsaný v programovacím jazyce Rust, zdrojový kód je dostupný na GitHubu.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
Byla vydána beta verze Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.04 LTS mělo vyjít 23. dubna 2026.
Jenže já se na to dívám z pohledu správce systému. Zkusím jiný příklad: v souvislosti s GDPR budou firmám hrozit za únik osobních údajů pokuty v řádu desítek milionů. Opravdu pak necháš člověku co např. vyřizuje objednávky v e-shopu, který má přístup k databázi s stovkami tisíc uživatelů, zvolit si heslo, jaké on uzná za vhodné? Když to heslo nějakdo zneužije, maximálně ho pak můžeš vyhodit a chtít p něm 4,5 násobek jeho hrubé mzdy.Nebylo by lepší tohle řešit dvoufaktorem? Například tokenem jako Yubikey? Tu tisícovku bych za to asi dal v tomhle případě.
Mimochodem, když mi stránka odmítne heslo, na truc volím '11qq!!QQ' to se snadno píše a má vysokou šanci projít podmínkami, co si programátoři navymýšleli.Tohle nemohl vymyslet programator, ale musel to byt nejaky manazersky debil, ktery nema ani znalosti, ani respekt k znalostem ostatnich. Nejaky takovy ten typ, co by jinak delal u kolotocu, nebo v teplakove bunde a zlatem retezu prodaval ojetiny, ktere jsou "po duchodkyni co s tim vubec nejezdila, pane" a byl by schopen presvedcit i sam sebe, ze ten plech na kapajici olej proste k dobremu auto patri.
A ty rady jako "doporučujeme zvolit jako heslo čtyři náhodná česká slova"Kolik lidí by si asi dalo heslo
čtyřináhodnáčeskáslova? :)
Přihlašování pomocí jiné služby problém neřeší .Přihlašování pomocí jiné služby řeší problém pro uživatele, protože si nemusí pamatovat mnoho složitých hesel, ale stačí mu jedno. I když to nedává správci žádnou záruku, že to bude bezpečnější, v důsledku to dost možná bezpečnější bude.
A blokování účtů je taky problém, robot klidně může po odblokování vyzkoušet zase další hesla a tak třeba na několik hodin zablokovat všechny účty v systému.To je tak zoufale malá představivost, že se mi fakt chce brečet.
11qq!!QQ výše), nebo zadá něco tak složitého, že si to nebude schopný zapamatovat. Password managery používají jen technicky zdatnější uživatelé a navíc je opravdu nelze považovat za optimální. V běžném kancelářském prostředí si to lidi napíšou někam na papírek, pošlou si to sami sobě e-mailem apod. Namítat, že to stále eliminuje přístup zvenčí a bez např. fyzického přístupu k notesu s poznámkami a hesly to účel plní, je bláhové. Implementací těch opatření, které jsem zmínil výše (logování historie přihlášení, blokování podezřelých IP adres, nebo vícefaktorová autentizace), je mnohem bezpečnější, uživatelsky pohodlnější a je to rezistivní i vůči přístupu zevnitř, tj. do systému se tajně nepřihlásí ani kolega nebo uklízečka.
Namítat, že průnikem do systému v důsledku slabého hesla lze způsobit obrovskou škodu, za kterou zaměstnanec neručí, je opět chybná úvaha – zaměstnanec by to super-bezpečné heslo mohl někomu říct a situace bude naprosto stejná. Tedy je potřeba to řešit jinak.
omezení přihlášení podle IP adresy, nebo rovnou jen z určité sítě (je třeba volit dle okolností)Třeba u systémů typu Datové schránky nebo kde uživatel přistupuje z dynamických IP?
logování historie přihlášeníNic neřeší, pokud ty logy někdo nebude realtime kontrolovat a problémy řešit
vícefaktorovou autentizaciSouhlas, ale ne vždy jde použít a i pak je stejně nutné řešit bezpečnost hesla, jen ne tak intenzivně.
Formulář při vyplňování hesla má fungovat nějak tak, jak naznačil mirefek.Dokážete tohle udělat třeba ve Windows?
Za slabé heslo vždy nese vinu uživatel, a to i v případě, že to prošlo (často neskutečně primitivním) filtrem, který si retardovaní „programátoři“ navymýšleli.Vinu nese provozovatel systému, on to bude muset řešit (špatná pověst, pokuta GDPR, atd.) O tom to celé je.
Namítat, že průnikem do systému v důsledku slabého hesla lze způsobit obrovskou škodu, za kterou zaměstnanec neručí, je opět chybná úvaha – zaměstnanec by to super-bezpečné heslo mohl někomu říct a situace bude naprosto stejná. Tedy je potřeba to řešit jinak.Stejně tak může někomu poslat půjčit svůj token s druhým faktorem. Proto insiderovi se moc bojovat nedá.
Třeba u systémů typu Datové schránky nebo kde uživatel přistupuje z dynamických IP?Jistě. Hodně pomůže omezit přístup ze zahraničí a ze známých anonymizérů, pokud to uživatel explicitně nezmění (podobně, jako se bance předem oznamuje cesta do zahraničí). Mimochodem, u dynamické IPv4 adresy se typicky mění jen poslední dva bajty. I kdyby daný provider měl těch rozsahů víc a přiděloval je naprosto náhodně, tak jich bude omezený počet, a whitelist by stále byl uskutečnitelný. Ne, že by to bylo zvlášť praktické.
Nic neřeší, pokud ty logy někdo nebude realtime kontrolovat a problémy řešitOpět zoufale malá představivost a nezkušenost. Ty logy si kontroluje sám uživatel. Z existujících služeb to umí např. Facebook – tam je hlavním nedostatkem to, že je to zahrabené někde v nastavení a většina lidí o tom neví. Mělo by to být víc na očích. Dále pak třeba Google, který při každém novém přihlášení posílá e-maily.
Souhlas, ale ne vždy jde použít a i pak je stejně nutné řešit bezpečnost hesla, jen ne tak intenzivně.Lze ji použít téměř vždy. Bezpečnost hesla si řeší uživatel.
Dokážete tohle udělat třeba ve Windows?Jako kus JavaScriptu, který při pravděpodobně slabém heslu zobrazí varování, ale umožní uživateli na vlastní riziko pokračovat? Ano.
Vinu nese provozovatel systému, on to bude muset řešit (špatná pověst, pokuta GDPR, atd.) O tom to celé je.Provozovatel systému stěží může nést vinu za to, že si uživatel zvolil slabé heslo, které někdo po pěti pokusech uhodl a přihlásil se.
Stejně tak může někomu poslat půjčit svůj token s druhým faktorem. Proto insiderovi se moc bojovat nedá.Bojovat se dá přinejmenším tím logováním historie přihlášení (a v krajních případech inteligentním systémem učícím se „office hours“ uživatele, délku sezení, aktivitu, vzorce chování apod.). Samotnému průniku do systému to (technicky) nezabrání, ale pomůže jej to alespoň zpětně odhalit. Zároveň to ale plní preventivní úlohu – s vědomím, že se na to přijde a bude se to vyšetřovat, si to část „útočníku“ rozmyslí (a druhá si dá větší pozor; ale stále je to obecně výhodnější situace než to nemít vůbec). Mimochodem: Pokud se jedná o firemní účet a vinu v konečném důsledku nese zaměstnavatel, pak má právo do nastavení hesla mluvit. To už je jejich věc. Ale primitivní pravidlo na počet a skupiny použitých znaků (nebo dokonce jeho pravidelné změny) nebude nikdy dobrý nápad. To už je mnohem lepší třeba ten Yubikey, který navrhuje Bystroushaak. Pokud už by fakt bylo nutné s nějakou takovou politikou přijít, protože bys měl firmu plnou sekretářek, které prostě nedokážeš přimět k tomu, aby si nastavili rozumná hesla, tak bych uvažoval nad nějakou heuristikou. Více slov, převést je do základního tvaru a podle Markovovo řetězců natrénovaných na daný jazyk určit pravděpodobnost, že se slova vyskytnou v daném pořadí (přičemž by to měl být zdánlivě nesmysl, tj. pravděpodobnost by měla být co nejnižší). Jenže tím se část té entropie v podstatě ztrácí – validní věty jako „Dobrý den, pane počítači.“ najednou nebudou platným heslem. Jak moc velkou má útočník šanci uhodnout celou jednu libovolnou větu? U hesel se říkalo, že nemáte volit jména domácích mazlíčků apod. Tady by asi lidi mohli mít tendence volit věty jako „můj pes je ťapka“ – potíž je v tom, že to heslo může být naprosto bezpečné v případě, že dotyčný žádného psa nemá a bude implementovaná ochrana proti bruteforce útokům (viz JiK) a není to natolik profláklý pattern, aby každý útok začínal s tímhle typem věty pro všechna běžná jména psů. Mimochodem: Bylo by bezpečné heslo, které střídá malá/velká písmena a speciální znaky a je to cheat do nějaké hry, která se pár dnů po implementování naší skvelé security-policy masově rozšíří a bude to za chvíli zrovna tak profláklé, jako dnes jsou IDDQD a IDKFA? Hmmm...
Copak je problem detekovat vic nez 5-7 opakovanych pokusu neuspesnych o prihlaseni? behem treba 1 minuty, a dat uzivateli pak na 30 nebo 60 minut ban?To bude mít uživatel radost, až se kvůli nějakému vtipálkovi nepřihlásí, protože dostal ban!
Nebudeš blokovat účet, ale přístup z dané adresy.To už je jiné téma.
Další možnost: Server bude před každým pokusem o přihlášení vyžadovat vyřešení výpočetně těžké úlohy. Legitimnímu uživateli to na pár desítek vteřin / jednotky minut zatíží CPU, ale přihlásí se. Útočníkovi to na druhou stranu útok výrazně komplikuje/prodražuje a server to nic nestojí – ověření úlohy by bylo levné a nemusí ani držet otevřené spojení, lze to dělat bezstavově.Tohle je dost zajímavá myšlenka, o které sem předtím ještě nikdy neslyšel. Díky, budu nad tím přemýšlet.
Jako náhradu navrhl, že by se měla měla kontrolovat minimální entropie (třeba 50 bitů) a slovník zakázaných hesel.Realistický příklad: jsem BFU a vysvětli mě teďka jaký heslo si mám teda vymyslet
V jedné diskuzi jsem narazil na koment, že požadavek na 90 dní vychází z dokumentu CSC-STD-002-85 z roku 1985, kde doporučuje změnu po 90 dnech, protože 1200 baudovým modemem trvá 60 dní uhádnout 8 znakové heslo. Jiný důvod pro to prý není. Nebo se plete?8znakové heslo (ASCII písmena a číslice) představuje 209×109 kombinací. To by bylo nereálné za tak krátkou dobu cracknout (musel bys dělat zhruba 42 pokusů za milisekundu).
Kromě toho si nejsem jistý, zda režie requestu bude natolik stabilní, aby timing attack měl šanci na úspěch. Bylo by potřeba umět to rozlišit s přesností jednotek instrukcí (vykonaných na cílovém stroji).To ti odfiltruje statistika.
C.3 Password Lifetime All other things being equal, the shorter the lifetime of a password, the fewer the number of guesses that can be made and thus the greater the degree of password security. As stated in 4.2.2.1, the maximum password lifetime should not exceed one year.Výpočet uhádnutí 8 znakového hesla je uveden dále.
R is set at 8.5 guesses per minute (guess rate possible with 300-baud service)
Tiskni
Sdílej: