Příspěvky

301

Vývoj / Re:Ověření kódu přes webovou stránku

« kdy: 18. 02. 2019, 07:48:15 »

Je tu několik věcí:

1. Ověření – podpis nestačí, pokud se budou pokaždé podepisovat stejná data. Pak stačí pokaždé odpovědět stejným podpisem. Mělo by to být challenge-response – podepíšu (možná ještě nějak zfotmátovaná) unikátní data od klienta. Ten klíč pokud možno nepoužívat na nic jiného, jinak je to zdroj bezpečnostních problémů (zvlášť pokud tím budeme podepisovat cokoliv bez formátování).
2. Odposlech klíče – na to by mělo být good enough HTTPS. Jde vymýšlet i nějaké schéma podepisování, ale IMHO to je zbytečná komplikace.
3. Side channels – pozor na timing attack na serveru.
4. Použití téhož klíče na více strojích – tomu se bohužel těžko brání. V případě HW klíče lze (byť to není už tak snadné) použít třeba USBIP. Můžeme kontrolovat latenci, ale pak riskujeme, že odřízneme i legitimní uživatele, kteří mají třeba pomalejší stroj nebo jejichž virtualizace prodlužuje latenci na USB.
5. Úprava aplikace – můžeme mít super kontroly, ale je to k ničemu, pokud útočník třeba zneguje podmínku nebo nahradí klíč vlastním. Ideálně to chce inlineovat všechny relevantní knihovny, které použijeme pro kontrolu.
6. Ekonomie: Kolik se uživateli vyplatí investovat úsilí do překonaní ochran? Kolik se nám vyplatí investovat do (v rámci možností) do nepřekonatelnosti? Pár pirátů může vyjít levněji než ochrana silná tak, že nikdo nevěnuje dostatečné úsilí k jejímu překonání.

302

Odkladiště / Re:Kryptografický problém

« kdy: 07. 02. 2019, 19:23:03 »

V první řadě bych se zeptal, jestli se chcete dozvědět, jak to funguje, nebo jestli chcete šifrování a autentizaci. Radši bych totiž sáhl po hotovém řešení, jako třeba GnuPG. V kryptografii je dost případů, kdy člověk neví, že neví. A nejhorší na tom je, že to narozdíl od mnoha jiných případů není na první pohled vidět – vše funguje vpořádku. Až na to, že pak někdo zjistí, že toho funguje víc, než by mělo.

Dále je potřeba si ujasnit, jestli vůbec potřebujete asymetrickou kryptografii. Pokud ne, vyhněte se těmto komplikacím. Asymetrická kryptografie je pomalejší, takže se typicky kombinuje se symetrickou. Pak je ale nutné zvládnout správně použít obojí. Asymetrická kryptografie je také méně odolná kvantovým počítačům. V neposlední řadě tu bude asi komplikovanější password-based encryption.

Je dobře, že přemýšlíte nad autentizací – ověřením, že jste skutečně autorem obsahu. V asymetrické kryptografii na to slouží podpis, v symetrické tzv. MAC. Rozdíl je podobný jako u šifrování – na ověření MACu potřebujete stejný klíč jako na jeho vytvoření. A co se týče pořadí, šifrování a autentizace – vězte, že se u symetrických šifer používají jiné postupy než u asymetrických.

Ano, i u symetrické kryptografie potřebujete autentizovat. Pokud útočník nemá klíč, sice nemůže vytvořit zprávu from scratch, ale může (někdy i celkem snadno) zkoušet upravovat existující – vizte malleability. To někdy vede k zajímavým útokům, možná si vybavíte POODLE na SSL3.

Pokud se to budete snažit implementovat. Vlastními silami, čeká vás spousta dalších úskalí, například:

* Jaký zvolit mode of operation?
* Jak zvolit inicializační vektor?
* Když potřebujete náhodná čísla (což se stane velmi snadno), jak je správně vygenerovat?
* Když spočítám MAC pro ověření, jak ji správně porovnat? (Vizte timing attack.)
* U šifrování heslem: Jak správně odcodit klíč z hesla?
* Když potřebujeme dva klíče (jeden pro MAC a druhý pro šifru), lze použít tvakrát tentýž, nebo dva různé? Kde je vezmu?
* Seznam nemusí být kompletní.

Jinak i pokud použijete hotové řešení, nabízí se pár otázek:

* Pokud jde o soubor, jehož obsah se může měnit, jak si můžete být jisti, že máte tu poslední verzi?
* Pokud takovýchto souborů máte více, nemůže je útočník třeba prohodit?
* Pokud takovýchto souborů máte více a nějak spolu souvisejí, že jak zjistíte, že třeba jeden zmizel nebo jeden je starší a další novější?
* Seznam nemusí být kompletní.

303

Vývoj / Re:Čo sa stalo s WebAssembly?

« kdy: 07. 02. 2019, 13:41:29 »

Asi se celkem shodneme, až na jednu věc: Jde o WebAssembly v dnešním stavu. Pokud podle svých plánů doplní podporu věcí jako GC a reference na JS objekty, mohou padnout některé dnešní nevýhody a může se z toho stát zajímavý target pro transpilery. Ale to už je otázka budoucnosti, z hlediska otázky, proč se to nepoužívá moc dnes je to celkem irelevantní.

SEO – to záleží a sem bych to netahal. S webasm je to stejný problém jako s JS a má to snad úplně stejná řešení.

Python – no, nevím. Co jsem viděl Linuxové binárky Pythonu 3.{6,7}, jsme v řádu MiB. Přijde mi, že tady nasbíráte různé zmiňované nevýhody a ještě to ani nebude moc rychlé.

304

Vývoj / Re:Čo sa stalo s WebAssembly?

« kdy: 06. 02. 2019, 20:59:32 »

Wasm má své výhody i nevýhody. Pokud chcete portovat třeba LaTeX do JS, je to dobrý nástroj. Pokud chcete napsat „obyčejnou“ webovou stránku, která bude komunikovat se serverem a zobrazovat nastylovaný text a obrázky, může to mít spíše nevýhody.

Podrobněji: WebAssembly (aspoň zatím) nemá garbage collector: https://github.com/WebAssembly/proposals/issues/16 Při portování Cčkového kódu do WA je to úplně jedno. Pro velkou část webových stránek to je překážka: Buď bude potřeba spravovat paměť ručně (opravdu to chcete?), nebo k tomu musíte přibalit i nějakou knihovnu pro GC. Celkově bych pak čekal (nejen kvůli té knihovně pro GC) objemnější výsledný JS. Znamená to, že se stránka bude déle načítat (to uživatel může pocítit). Pokud ta stránka ale bude provádět spíše network-bound operace (což je IMHO celkem časté), čas vykonávání JS můžeme zkrátit třeba i o 90 %, ale uživatel to nepozná.

Pro koncového uživatele tedy čekám většinou spíše zhoršení. Má to výhody pro programátora? IMHO moc ne. Dnes je spousta transpilerů, takže programátor má i bez wasm spoustu možností. Webasm ty možnosti může rozšířit. Dokud ale bude obtížné si držet reference na nativní DOM objekty, hitparáda to nebude. Dovedu si představit nějaký workaround, ale jestli podobnou šílenost někdo někde implementoval…

Jak jsem psal výše, výjimky se najdou. LaTeX – máme existující kód (benefit pro programátora), který můžeme díky webasm spustit rychleji (benefit pro uživatele) a který nepotřebuje přístup k DOMu (odpadá nám nevýhoda). Tady to může stát za to. Kolik takových případů ale máme? To IMHO jejich počet odpovídá využití webasm.

305

Odkladiště / Re:Prolomení hesla na Gmail

« kdy: 18. 01. 2019, 21:59:44 »

Jak často zadáváte na telefonu toto heslo? Typické je zadávat heslo k účtu Google jen hned po vytažení z krabice, pak je v telefonu uložený token (heslo AFAIK ne). Je-li tomu tak, pak by hypotéza o leaku kompromitovaným telefonem vyžadovala mít telefon kompromitovaný ještě před zadáním hesla, maximálně krátce po zadání hesla (může chvíli zůstat v RAM). Ale mohl jste mít důvod to udělat jinak (např. nákup v aplikaci) nebo jste se možná přihlašoval na ten dražební portál.

Budu-li brát ten e-mail doslova, ten někdo se zřejmě pokoušel přihlašovat heslem, nikoli tokenem, který je uložený v telefonu. Hypotéza s roamingem pak ale nedává smysl.

Zeptám se, jak moc důsledně u toho dražebního portálu používáte HTTPS? Jakou má ten portál známku na ssllabs.com? Jak moc důsledně kontrolujete, že se přihlašujete skutečně na https://accounts.google.com (resp. https://tendrazebniportal.example.com) a ne na třeba https://accounts.goggle.com?

Jak moc by někdo mohl mít důvod jít cíleně přímo po Vás (tzn. nespokojil by se s jinou řadovou obětí)?

306

Hardware / Re:Bolest při psaní na mechanické klávesnici

« kdy: 09. 01. 2019, 10:37:22 »

Zdvih je trochu otázka. Když je malý, budou prsty tvrdě narážet, zatímco u red/brown se můžete zastavit sami.

S vysokým zdvihem může být jiný problém: Klávesnice jako taková bude relativně vysoká, ale nebudou tomu odpovídat podpěry pod ruce. Pokud člověk nebude držet ruce ve vzduchu, bude mít zápěstí špatně zalomené. Samozřejmě to není problém vysokého zdvihu jako takového, ale je na to potřeba si dát pozor.

307

Hardware / Re:Bolest při psaní na mechanické klávesnici

« kdy: 08. 01. 2019, 18:02:39 »

Je to tady tato? https://m.alza.cz/hyperx-alloy-fps-red-mechanical-gaming-keyboard-d4653522.htm

Na čem jste psal předtím? Měnil jste nějaké zvyky?

O co opíráte ruce? Na notebooku to lze vedle touchpadu (vím, není to ideální), ta klávesnice vypadá, že k sobě žádnou opěrku v balení nemá. Já si kdysi řekl, že budu ruce držet ve vzduchu a opěrku nepotřebuju, reálně jsem si je opíral o stůl a rychle to začalo bolet… Vyřešil jsem to dřevěnýma deskama. Xah Lee doporučuje spíše vysoký ručník: http://xahlee.info/kbd/keyboard_problems.html

308

Server / Re:Jak surfovat na webu, který nemá doménu, ale jede na VirtualHost

« kdy: 04. 12. 2018, 09:17:42 »

Jen jedna poznámka k HTTPS: teoreticky by se to mělo chovat z pohledu prohlížeče stejně, ale na doménu, kterou nevlastníte, těžko dostanete certifikát od public CA. Reálně tu jsou pak asi dvě možnosti, u kterých je ale potřeba dobře vědět, co děláte:

a. Mít nedůvěryhodný (např. self-signed) certifikát, odkliknout výjimku a ideálně ji schválit trvale. To asi nechcete radit běžným uživatelům (ale těm asi ani nebudete radit hosts…). Pokud například ve Firefoxu (a asi i jinde, ale tam si nejsem jistý) schválíte výjimku trvale, funguje to jako takové TOFU (trust on first use) – při změně certifikátu nebo veřejného klíče (nejsem si 100% jistý) to bude spojení brát za nedůvěryhodné. Navíc můžete zkontrolovat hash. V podstatě jako u SSH. (Nemůžete se spolehnout na serial number, to si útočník ve svém certifikátu může zvolit libovolně.)
b. Vlastní CA, kterou nainstalujete na všechny relevantní počítače. Teoreticky možné, pak je ale potřeba privátní klíč střežit jako oko v hlavě – taková CA totiž může (pokud to neomezíte) podepisovat nejen certifikát k Vašemu webu, ale i libovolný jiný. Vlastní CA navíc má volnější pravidla, například se pro ni nevyžaduje certificate transparency. Záměrně nebudu linkovat žádný návod, tady to chce dobře vědět, co děláte, ideálně to míť jen v omezeném testovacím prostředí. Možná by se dalo omezit platnost na nějakou vlastní TLD, kterou byste si sami zvolili.

309

Studium a uplatnění / Re:Jaká je moje cena po střední.

« kdy: 22. 10. 2018, 07:15:41 »

K nevýhodám volné nohy:

* absence dovolené – to není nevýhoda, to je holý fakt, který je potřeba započítat při porovnávání příjmů mezi volnou nohou a zaměstnáním. Když budu mít o něco (kdysi jsem to spočítal na tuším 6 % až 7 %) vyšší příjem, vydělá mi to na neplacenou dovolenou. Je ale nutné zajistit, aby vše v tu dobu fungovalo.
* abcence nemocenské – podobné, jen komplikovanější. Může řešit finanční rezerva nebo pojištění.
* Nejdůležitější mi přijde, že na volné noze jste pánem svého času, což přináší i nutnou zodpovědnost. Do ceny si musíte zakalkulovat i to, že nějakou část času budete mít režii. U zaméstnání je to věc vedení, na volné noze je to vaše věc. Stejně tak když se neodhadne množství práce, v zaměstnání máte placený přesčas nebo padla (a pokud tomu šéf nechce rozumět, může si hledat nového zaměstnance…),  na volné noze je to vaše starost. A podobně dovolená – po tu dobu je nutné buď nebýt potřeba, nebo mít někoho místo sebe. V zaměstnaní je to starost vedení (měl by vás někdo být schopen nahradit) a vám maximálně neschválí dovolenou v době, kdy jste hůře  postradatelný. Na volné noze je vaše starost si nevzít dovolenou v nevhodný okamžik.

K VUT FIT:Tam prý především nebudete mít moc času na práci ke škole. Na druhou stranu, u MUNI FI nebu práci ke škole jako celkem potřebný doplněk – ale čas na to nejspíš budete mít.

310

Studium a uplatnění / Re:Pojistka na blbost pro IT admin

« kdy: 14. 10. 2018, 15:29:58 »

Pojišťovna je v podstatě taková morbidní sázkovka, kde si sázíte na vlastní neštěstí. Pokud se vám stane předem definovaná nešťastná událost, pojištění „vyhrajete“, jinak propadá pojišťovně.

Stejně jako klasická sázkovka, i pojišťovna si bude hledět, aby na pojištění statisticky vydělala. Pokud si myslíte, že na pojištění statisticky vyděláte vy, pak doporučuju:

* pročíst výluky
* uvědomit si, že zdaleka ne každá pojistná událost znamená nejvyšší možné plnění
* započítat případnou spoluúčast
* ujistit se, že nemáte v plánu pojistný podvod

2K mě samozřejmě nezabijou, ale přijde mi to zbytečné. Statisticky na tom prodělám. Ušetřím si papírování, čtení výluk atd.

311

Studium a uplatnění / Re:Pojistka na blbost pro IT admin

« kdy: 14. 10. 2018, 13:18:38 »

Pokud někdo má 100k/měs a žije od výplaty k výplatě, pak ano, takové pojištění může být vhodné. Ale upřímně, pak je problém asi někde jinde.

I s výrazně nižším příjmem je možné (a vhodné) si udělat nějaké rezervy, které pokryjí i různé další nečekané životní situace. Stejně se na všechny asi nepojistíme, případně můžeme být nemile překvapeni výlukama.

Pojištění má smysl tam, kde by následky mohly být likvidační. Zaplatit 4.5násobek průměrné hrubé mzdy (nebo kolik to je) mě sice poněkud naštve, ale nesloží. Invalidita může potrápit i finančně, tam to má smysl, ale asi ne na první stupeň. A pro miliardáře možná ani pojištění invalidity smysl nemá.

312

Studium a uplatnění / Re:Pojistka na blbost pro IT admin

« kdy: 13. 10. 2018, 22:03:24 »

Ironicky, u 100K mzdy to pojištění až takový význam nemá. Sice jde o vyšší částky, ale o to dražší taky asi bude pojištění… A člověk se 100K mzdou by neměl mít problém našetřit si adekvátní rezervu. To člověk s 20K měsíčně na tom asi bude hůř…

313

Studium a uplatnění / Re:Pojistka na blbost pro IT admin

« kdy: 13. 10. 2018, 16:55:50 »

V první řadě si doporučuji ujistti, že skutečně chcete pojištění, a co od něj případně chcete:

1. Jak velkou škodu by to případně mělo krýt?
2. Jak velký problém by to pro mě byl? Do jaké částky to prostě pokryju z rezerv?

Škoda za 30 000 CZK pro mě osobně spadá do „naštvalo by to, ale zaplatil bych to“. Škoda za milion by už mohla být problém. (I když, jako zaměstnanec mám ručení omezené nějakým násobkem příjmu, takže na ten milion se asi ani nedostanu…) Různí lidé to mohou mít nastaveno různě podle situace – nejen příjmy, ale i výdaje a plány.

Pokud by případné plnění pouze řešilo situaci, kdy mě to naštve, ale prostě bych to zaplatil bez problému ze svého, nemá pojištění moc smysl. Radši si částku ušetřenou za pojištění odkládat a navýšit si tím rezervy pro případ potřeby. Pojišťovna chce pochopitelně vydělat, takže cena pojistného bude taková, že na tom statisticky vydělá. Pokud máte jiný pocit, pak se nejspíš buď mýlíte, nebo se chystáte na pojistný podvod (no offence).

Pokud by pojištění krylo nějaké zásadnější riziko, pak má smysl. Snažil bych se ale o něco se spoluúčastí, sice klesne případné pojistné plnění (i pravděpodobnost – budete-li mít spoluúčast 50 000 CZK a škodu za 30 000 CZK, za pojišťovnou s tím nepůjdete…), ale zase se sníží pojistné, a o to víc si můžete odkládat do svých rezerv.

Zjednodušeně řečeno, spoluúčast ideálně až do částky, kdy to bez problému pokryju z rezerv, zlevní to pojištění. Jinak to povede ke dražší pojistce, než potřebujete. Pokud spoluúčast <= krytá částka, pojištění nedává žádný smysl.

314

Distribuce / Re:Gentoo: má ještě pro někoho smysl?

« kdy: 09. 10. 2018, 07:44:44 »

Gentoo vyžaduje hlavně počáteční investici, pak umí fungovat relativně bezúdržbově (necháte nainstalovat aktualizace a ono se to typicky prostě provede). Nejsem si teď jist s updaty kernelu, ale snad i ty jsou vyřešeny dobře. Bylo celkem stabilní, což byl můj důvod pro migraci z Archu.

Snížení nároků je fajn, ale kompilovat kvůli tomu všechno, to za to IMHO často nestojí. Ušetříte něco málo času CPU za běhu (ani to nejspíš nepoznáte, zato updaty přes noc nebo na pozadí ano), něco na disku (zato ale budete navíc potřebovat kompilátory a hlavičkové soubory na kdeco) a něco v RAM (kterou ale budete potřebovat při kompilaci).

Možnost ořezat závislosti je teoreticky fajn z hlediska eliminace bezpečnostních rizik, nebo aspoň na eliminaci nejistých situací, kdy mám v systému zranitelnou knihovnu, ale snad se nepoužívá, takže je to snad OK, ale jist si nejsem. Pokud ale máte univerzální systém (nikoli systém do kanceláře používaný na přesně vymezenou sadu úloh), dost možná tam stejně nahrnete ± všechno, takže tato výhoda bude minimální.

Velký výběr ebuildů a snadná vlastní kompilace: Celkem ano, ale třeba Debian a deriváty jsou v tomto přinejmenším zdatná konkurence.

Kdy bych to doporučil? Napadají mě dva případy:

a. Chcete se naučit s Linuxem (ale něco už znáte). Gentoo není rocket science, ale ani nevede za ručičku jako Ubuntu, kdy nemusíte ani vědět, jaký používáte filesystém.
b. Některá ze zmíněných výhod do konkrétní situace padne výjimečně dobře. Možná nějaký hodně specifický stroj, kde potřebuju z různých důvodů (bezpečnost/úložiště) osekat systém. Možná něco embedded typu Raspberry Pi. (A možná taky ne, protože takový Raspbian bude dostatečně dělaný specificky pro konkrétní HW…) Možná nějaká hromada výpočetních strojů (zkompiluju jednou, deploynu X-krát). Dost možná v daném scénáři bude praktické kompilovat na jiném než cílovém stroji.

315

Hardware / Re:Lenovo ThinkPad bezpečný?

« kdy: 06. 10. 2018, 22:47:24 »

Co u mě nahlodává důvěru v Lenovo nejvíc: automatická instalace crapware do čistého OS: https://www.techdirt.com/articles/20150812/11395231925/lenovo-busted-stealthily-installing-crapware-via-bios-fresh-windows-installs.shtml

Ano, na Linuxu se vás to asi týkat nebude, ale z hlediska důvěry je to asi celkem jedno.