Vládní CERT upozorňuje (𝕏) na kritické zranitelnosti v produktech VMware: CVE-2026-59309, CVE-2026-59310 a CVE-2026-47876. Zranitelnosti v VMware vCenter umožňují vzdálenému útočníkovi se síťovým přístupem obejít autentizaci a získat neoprávněný přístup k vCenter, případně zneužít directory traversal ke spuštění libovolného kódu na vCenter.
Společnost Coinkite upozorňuje na bezpečnostní chybu svých hardwarových kryptopeněženek Coldcard. Jedná se o kritickou chybu v generování náhodných čísel (RNG). Místo hardwarového generátoru náhodných čísel (TRNG) byl omylem používán softwarový fallback (PRNG).
Představena byla nová linuxová distribuce Shadowfetch Linux. Na rozdíl od mnoha nováčků, které nabízejí převážně jiné téma a výběr softwaru, tato distribuce založená na Debianu Testing s desktopovým prostředím KDE Plasma 6.6, klade lokálně běžící umělou inteligenci do centra svého desktopového zážitku.
Max Leiter v roce 2019 zkusil zprovoznit X server na iPadu (iOS). Nyní se k tématu vrátil a s pomocí LLM a balíčkovacích nástrojů Procursus rozběhl desktop s X11 i Waylandem. Jeho balíčky jsou dostupné v repozitáři xiOS.
Společnost Google Cloud dnes oznámila, že její infrastruktura a služby byly oficiálně zařazeny do Katalogu cloud computingu vedeného Digitální a informační agenturou (DIA). Tato certifikace potvrzuje, že infrastruktura a služby Google Cloud splňují přísné bezpečnostní a regulační požadavky České republiky pro provoz cloudových služeb ve veřejném sektoru.
Vůbec poprvé v historii se stát při testování digitálních služeb obrací na širokou veřejnost. Digitální a informační agentura (DIA) a Ministerstvo vnitra zvou občany k zapojení do zátěžového testu eDokladů, které od loňského podzimu prošly optimalizací aplikace a posílením infrastruktury. Test proběhne 13. srpna ve 13:00 a pro jeho úspěch bude potřeba zapojení několika desítek tisíc občanů. Zapojení do testu je zcela dobrovolné a úkol
… více »FireDragon je webový prohlížeč, doposud založený na Floorpu, jednom z forků Firefoxu s větším důrazem na ochranu soukromí a přizpůsobení uživatelského rozhraní. Spravuje ho člen komunity distribuce Garuda Linux. Nové vydání verze 13 opouští Floorp a přechází přímo na Firefox s patchi z LibreWolfu a vlastními úpravami. Dostupný je také na Flathubu.
picogame (GitHub) je malý 2D herní engine pro mikrokontroléry jako RP2040, čip uvnitř kapesní konzole Picopad. Hru napíšeš v Pythonu a vyzkoušíš ji v prohlížeči nebo desktopovém simulátoru. Až bude hotová, zkopíruješ ji na podporovanou desku. Na začátku nepotřebuješ C, sestavení firmwaru ani hardware.
Multiplatformní prohlížeč elektronických knih KOReader byl vydán ve verzi 2026.07 "Sailing Walrus". U PDF souborů s SMask lze vyčistit pozadí. Přibyla podpora Kobo v5 nebo základní podpora OPDS 2.0.
Společnost Valve sponzoruje a společnost Collabora portuje RADV (open source Vulkan ovladač pro AMD GPU z projektu Mesa) na Windows.
Nešifrované HTTP
| by mělo zmizet |
|
4% (260) |
| je postačující, dokud nejsou přenášena důvěrná data |
|
96% (6819) |
Celkem 7079 hlasů
Vytvořeno: 23.4.2015 11:44
Tiskni
Sdílej:
23.4.2015 11:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
23.4.2015 23:39
Petr Tomášek | skóre: 39
| blog: Vejšplechty
jednocipy niesu taky problem, ARMy s linuxom uz vobec a ked pouzivas nieco ako ESP8266, tak si ho preproxujes a zasifrujes cez domaci router, aj tak vacsinou nema to male zariadenie ani verejnu IP...
9.5.2015 19:47
Petr Tomášek | skóre: 39
| blog: Vejšplechty
7.5.2015 23:04
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
23.4.2015 13:29
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
...jen nevím, ze kterého roku ty vánoce byly zamýšleny.
8.9.2015 09:34
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Chtělo by to checkboxy.
Zmizení nešifrovaného HTTP by bylo pěkné, ale zatím to není proveditelné, zejména z toho důvodu, že HTTPS není o moc bezpečnější. Problém je v tom, jakým certifikátem je možné komunikaci zabezpečit – v prohlížečích jsou i podivné CA a každá autorita může podepsat cokoliv.
Navíc většina browserů křičí při self-signed certifikátu a u některých (zrovna u Mozilly) není úplně jednoduché povolit spojení se serverem, kterému certifikát např. vypršel. Takže majitel webu musí solit a starat se.
7.5.2015 23:10
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Takže majitel webu musí solit a starat se.Majitelé webů, a to i těch hodně navštěvovaných, se často nestarají
Zmizet úplně nemusí, ale je třeba si uvědomit, že spousta informací, které samy o sobě důvěrné nejsou, v agregované podobě už nebezpečí představují – proto má smysl chránit i zdánlivé banality jako, o čem si člověk čte, co hledá na mapě, jaké si hledá spojení v jízdním řádu atd.
1.5.2015 01:18
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
To je pravda. V případě třeba nejaky-protistatni-blog.wordpress.com to hraje celkem velkou roli. Ale v případě Wikipedie, zpravodajských serverů nebo portálů se širším zaměřením se šmírák nic podstatného nedozví. Zatímco v případě nešifrovaného HTTP vidí, které konkrétní články si čteš a co zadáváš do vyhledávače.
7.5.2015 23:11
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
16.5.2015 22:33
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Hlavně by to chtělo změnit chování prohlížečů – zatímco samopodepsané HTTPS vypadá strašidelně a běžný uživatel se k takovému obsahu jen tak nedostane1, zatímco u nešifrovaného HTTP prohlížeč žádné varování nezobrazí2 a uživatel má pocit, že je všechno v pohodě – i když je to ve skutečnosti horší než to samopodepsané HTTPS, které odstaví alespoň pasivní3 odposlouchávače (třeba na WiFi nebo když si nějaký síťař pustí tcpdump, nachytaná data uloží a pak se povalují různě na discích nebo dále šíří),
[1] v horším případě si vytvoří návyk, že je potřeba kliknout tady a potom támhle, a bude to dělat kdykoli na něj ta hláška vyskočí – i třeba při přístupu do banky nebo k e-mailu
[2] kdysi se možná zobrazovalo varování při prvním odeslání formuláře přes HTTP, že data můžou být odposlechnuta
[3] nezasahují do komunikace a nedělají MITM
Hlavně by to chtělo změnit chování prohlížečů – zatímco samopodepsané HTTPS vypadá strašidelně a běžný uživatel se k takovému obsahu jen tak nedostane, zatímco u nešifrovaného HTTP prohlížeč žádné varování nezobrazíSes posral, ne? To by pak Mozilla nemohla inkasovat úplatky od důvěryhodných čínských soudruhů.
3.5.2015 10:06
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
4.5.2015 17:22
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| 上海
Přijatelná alternativa k heslům moc neexistuje.
Takže bych začal tím, že aplikace1, do které uživatel zadává heslo2, se k němu nebude distribuovat nezabezpečenou cestou3.
[1] u webů typicky JavaScript
[2] které se klidně na klientovi může zahashovat a server se ho za normálních okolností – pokud aplikaci cestou nikdo nepozmění – nedozví
[3] nešifrované/nedůvěryhodné HTTP
Přijatelná alternativa k heslům moc neexistuje.Challenge-response auth. Asymetrická kryptografie.
).[1] když už tu důvěryhodnost nedokáže posoudit uživatel, tak aspoň důvěryhodný z pohledu provozovatele služby/aplikace – který má přístup k datům uživatelů, a ti mu tudíž musí věřit tak jako tak
nebo můžou mít zase heslo, ze kterého se odvodí klíčPřesně tak. Rozdíl je v tom, že se to heslo neposílá na server - takže není možné aby nastal ten populární případ údivu „jé, já jsem serveru poslal své heslo a on ho teď zná, to je ale zlý server!“
Jak víš, že se to heslo neposílá na server nebo někam jinam, když ti ten JavaScript přišel po HTTP a kdykoli se ti mohla nainstalovat nová verze (takže i když jsi tu starou četl, je ti to celkem na nic)?
V čem je rozdíl jestli pošlu seed nebo hash?Záleží na tom jak ten seed/hash počítáš…
Replay tím stejně neodstraním a pokud tam je sůl nebo čas, tak už je to celkem běžná forma challenge/response.No vždyť o to mi jde.
protože nemáme uživatelsky příjemný a univerzální způsob jak pracovat s heslem chráněnýma čipovkamaI RSA/ECDSA odvozené z hesla je mnohem lepší než současný způsob.
Vzpomínám si, že jsem četl o protokolu na přihlášení přes nezabezpečený kanál, kde server nikdy nedostal heslo v čitelné formě (ani v db, ani při přihlášení), ale už si nevzpomínám jak se ten protokol jmenoval.SCRAM, ale ten mi přijde překomplikovaný. Jsou jednodušší cesty.
9.5.2015 20:07
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Vzpomínám si, že jsem četl o protokolu na přihlášení přes nezabezpečený kanál, kde server nikdy nedostal heslo v čitelné formě (ani v db, ani při přihlášení), ale už si nevzpomínám jak se ten protokol jmenoval.
Ono by úplně stačilo upravil HTML standard tak, aby se přidal nový typ formulářového pole který by heslo hashoval v prohlížeči, který by případně dostal za parametr "sůl" a na server by to posílalo jen čistý hash. Něco ve stylu:
<form> <input type="hashed-password" hash-method="sha512" hash-encoding="base64" salt="GxzoEm+ce3s8z2VLpQzz4CSh5awdC0xc07fJ0o/r"> <input type="submit"> </form>
To je pravda – součástí soli by měla být i doména serveru a jméno uživatele případně i název služby (na doméně jich může být víc).
10.5.2015 14:39
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Co když si na svém ďábelském webu nastavím stejnou sůl jako mi vrátí AbcLinuxu a získaný hash prostě použiju?
V tom případě by Abclinuxu bylo opravdu debilní, kdyby si poslanou sůl nepoznamenalo do databáze (nejlíp s dalším identifikátorem, např. IP adresou klienta nebo tak něco) a nechalo si vnutit sůl jinou...
A taky to neřeší replay a přihlášení uloženým hashem z uniklé databáze.
Replay to řeší, pokud se zajistí pokaždé jiná sůl, viz výše.
V tom případě by Abclinuxu bylo opravdu debilní, kdyby si poslanou sůl nepoznamenalo do databáze (nejlíp s dalším identifikátorem, např. IP adresou klienta nebo tak něco) a nechalo si vnutit sůl jinou...Jak to pomůže?
Replay to řeší, pokud se zajistí pokaždé jiná sůl, viz výše.A jak pak budeš na serveru porovnávat jestli je to heslo správné? Při registraci dostaneš hash(mojeheslo+666), při dalším přihlášení hash(mojeheslo+999), úplně jiné hodnoty, neporovnatelné.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
7.5.2015 07:27
24.4.2015 13:15
6.5.2015 20:38
25.4.2015 00:06
25.4.2015 16:20
6.5.2015 15:02
"login:realm:heslo", takže server sice zná hash který by mohl zneužít k přihlášení jménem uživatele na jiný server, ale jen pokud ten server bude mít totožný realm.
Nejlepší na tom je, že webové prohlížeče i webové servery Digest podporují - stačí použít ne-basic .htpasswd autentizaci Apache - AuthType Digest.
viz podrobný (praktický) popis
.
Nešifrované HTTP by bylo svým způsobem OK, kdyby bylo aspoň kryptograficky podepisované, aby koncový uživatel mohl ověřit, že skutečně čte původní informace zveřejněné na nějakém webu. Dnešní nešifrované HTTP bohužel znamená, že se s informacemi může stát cestou cokoliv a koncový uživatel nemá možnost na to přijít.
17.7.2015 21:48
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
25.8.2015 12:28