Byly vyhlášeni vítězové a zveřejněny vítězné zdrojové kódy (YouTube, GitHub) již 29. ročníku soutěže International Obfuscated C Code Contest (IOCCC), tj. soutěže o nejnepřehlednější (nejobfuskovanější) zdrojový kód v jazyce C.
Evropská komise předložila evropský balíček pro technologickou suverenitu, tedy soubor opatření, která mají posílit kapacity EU v oblasti polovodičů, umělé inteligence, cloudu a open source. To Evropě pomůže stát se lídrem v oblasti umělé inteligence, posílit její digitální autonomii a vytvářet podmínky pro udržitelnější digitální budoucnost.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána v nové major verzi 5.
Byla vydána nová verze 9.7 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled novinek, vylepšení a oprav v poznámkách k vydání.
Vývojáři webového prohlížeče Ladybird dnes oznámili, že mění způsob vývoje. S blížícím se vydáním alfa verze přestávají přijímat veřejné pull requesty. Všechny otevřené veřejné pull requesty budou uzavřeny. Tým nedokáže garantovat bezpečnost AI generovaných pull requestů.
OpenLogi (GitHub) je open source náhrada aplikace Logi Options+ pro přizpůsobení myší od společnosti Logitech. Zatím běží pouze na macOS.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za květen (YouTube).
Úřad pro ochranu osobních údajů řeší desítky stížností na jednotné měsíční hlášení zaměstnavatele, které stát spustil počátkem dubna. Systém, jenž má firmám odlehčit od desítek formulářů, nejenže výrazně zatížil jejich účetní oddělení, ale docházelo v něm i k únikům osobních dat zaměstnanců k firmám, kde nepracovali. Podle ministerstva práce a sociálních věcí stála za problémem technická chyba. „Incident se týkal několika stovek
… více »Byla vydána (𝕏, Bluesky) nová verze 22.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
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:
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...
...jen nevím, ze kterého roku ty vánoce byly zamýšleny.
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.
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.
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.
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ů.
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.
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).
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é.
"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.