Příspěvky

4816

Studium a uplatnění / Re:Java nebo .NET pro budoucí freelancing?

« kdy: 15. 07. 2015, 18:27:00 »

V Javě je toho napsaného víc a má širší záběr (můžete si vybrat, zda programovat software pro mobilní telefony nebo bankovní backend). Na druhou stranu po C# (předpokládám, že tohle myslíte pod .NETem - ASP.NET nebo VB.NET je zase něco dost jiného) je teď myslím větší poptávka - protože Javu dnes "umí každý".

Pokud si vybíráte první zaměstnání, může zkusit hledat obojí a podle toho si udělat představu, jaká je asi tak poptávka. Ale o tom, jak to bude za pár let nebo třeba někde jinde, nezjistíte nic.

A pokud se na to první zaměstnání teprve chcete připravovat, napište si něco v obou jazycích. Pro mne je u čerstvého absolventa důležité, zda má s programováním nějakou zkušenost a tedy ví, do čeho jde (nějaký semestrální projekt je minimum). A pak aby měl zkušenost s nějakým mainstreamovým procedurálně-objektovým jazykem (Java, C++, C#, Python, PHP, Object Pascal...), aby bylo jasné, že je kompatibilní s potřebným způsobem uvažování. Jestli pak umí Javu nebo C# je mi jedno, protože stejně ve skutečnosti neumí ani jedno :-) Umí v daném jazyce akorát kódovat, a to se snadno naučí i v jiném.

4817

O serveru Root.cz / Re:Nelze se přihlásit přes OpenID

« kdy: 15. 07. 2015, 18:04:43 »

Já jsem to tedy už delší dobu nezkoušel, ale řekl bych, že to není "opět", ale že to nefunguje celou dobu od minulého hlášení. To, že jsem tady přihlášený, je dané jenom tím, že si mne v tomhle prohlížeči Root pamatuje.

4818

Sítě / Re:Nestandardní maska sítě 255.255.254.0

« kdy: 11. 07. 2015, 08:46:51 »

Nebude potřeba přepsat masku ve všech zařízeních v siti?

Pokud ta zařízení nepotřebují komunikovat s těmi novými IP adresami, tak ne. A správně by to mělo fungovat, i kdyby to potřebovala - ale to už záleží na tom, zda jednotlivé implementace IP stacku nejsou moc pokažené.

4819

Vývoj / Re:PHP + jquery - relacni promenne

« kdy: 06. 07. 2015, 17:25:23 »

Session předpokládám máte identifikovanou pomocí cookie. Posílá se ta cookie s tím AJAX požadavkem? Nevím z hlavy, zda ji tam prohlížeč přibaluje automaticky, nebo zda je nutné to udělat ručně.

4820

Vývoj / Re:SHA 512 dostačující?

« kdy: 06. 07. 2015, 08:20:13 »

Pánové, dost jste to tady zaneřádili. To, že někdo nerozumí počítačové bezpečnosti, není důvod k posměchu. Ani pokud se snaží vytvořit bezpečnostní systém - pokud se včas zarazí, a buď si to dostuduje, nebo začne spolupracovat s někým, kdo tmou rozumí, nebo toho nechá. Ale teď tady na vážně a dobře míněné rady navazují ironické komentáře, které tedy tazateli rozhodně neusnadní pochopení, v čem je problém.

4821

Vývoj / Re:SHA 512 dostačující?

« kdy: 05. 07. 2015, 20:15:36 »

500 znaků je nesmyslně mnoho, pokud to ale třeba omylem pošleš uživateli

Myslím, že to nechce posílat uživateli omylem, ale záměrně...

4822

Odkladiště / Re:Deaktivacia sluzby Google Analytics_ANO al. NIE?

« kdy: 05. 07. 2015, 18:27:01 »

Samozrejme že sa to dá ovplyvniť, napríklad Google Analytics môžem v prehliadači zakázať.

Což vám velmi pomůže v případě, kdy data do GA odesílá přímo server...

Ne, ovlivnit shromažďování dat v Google Analytics nemůžete, můžete maximálně zakázat JavaScriptovou variantu sběru dat. Což bude na spoustu webů fungovat, ale vy nedokážete zjistit, na které. No a zrovna internetové bankovnictví by z bezpečnostních důvodů nemělo používat vložený JavaScript, ale právě odesílání měřících dat ze serveru.

4823

Vývoj / Re:SHA 512 dostačující?

« kdy: 05. 07. 2015, 18:23:12 »

Chyba v navrhu implementace zatim neni (doufam)

Vzhledem k tomu, že nemáte jak poznat,kdyby tam chyba byla, je to tvrzení celkem bezpředmětné.

pokud tvrdite ze 500 znaku je zbytecne moc tak jsem naprosto spokojeny

To je právě chyba.

Chci jit trosku dal a vyzkouset novy zpusob.

Tento "nový způsob", kdy je na serveru uložen pouze otisk hesla, se používá naprosto běžně. Šifrovaná komunikace, kdy šifrují koncové body a zprostředkovatel klíče nezná, je také běžná - a na rozdíl od vašeho řešení je normální, že server ani klíče znát nemůže, protože si je vygenerují přímo uživatelé na svém zařízení. Takhle funguje třeba šifrovaný e-mail.

Jde mi o to kdyz dojde jakykoli organ a bude chtit data tak aby dostal jen zasifrovana data a otisk tohoto kodu.

Proti policii to fungovat bude, protože ta musí postupovat podle zákona a nemůže vám ten systém jednoduše hacknout, i když by to bylo nesrovnatelně jednodušší, než o něco žádat.

4824

Vývoj / Re:SHA 512 dostačující?

« kdy: 05. 07. 2015, 17:18:43 »

Pro šifrování komunikace se obvykle nepoužívá asymetrická kryptografie, protože je pomalá. Používá se podstatně rychlejší symetrická kryptografie s tím, že se na začátku vytvoří náhodný klíč, a pouze ten se vymění pomocí asymetrické kryptografie.

Heslem se obvykle označuje něco, co si má uživatel pamatovat. Pětisetznakové si nebude pamatovat nikdo, takže to spíš bude klíč, který bude někde uložen - takže bude záležet spíš na tom, jak bezpečné bude to úložiště. Navíc je dost možné, že to pětisetznakové heslo se ani nepoužije celé. Útoku hrubou silou (hádáním hesel), pokud je jinak implementace správná, brání už hesla s nízkou desítkou znaků, takže pětisetznakové heslo nesvědčí o super zabezpečení, ale o neznalosti autora a tím pádem nejspíš o slabém až žádném zabezpečení.

Veřejné a soukromé jsou klíče, certifikát je podepsaný dokument, který ověřuje vazbu mezi veřejným klíčem a nějakými informacemi (typicky "privátní klíč příslušející k přiloženému veřejnému klíči má v držení osoba XY"). SHA-512 je hash, který se může použít pro vytvoření toho certifikátu. Pro šifrovanou komunikaci ale certifikát nepotřebujete, ten slouží pouze k tomu, abyste nemusel znát předem veřejný klíč protistrany. Např. v případě SSH komunikace nepotřebujete žádný certifikát, protože znáte rovnou veřejný klíč serveru. V případě HTTPS by bylo nepraktické, kdybyste si musel ke každému serveru bezpečnou cestou opatřovat veřejný klíč, proto se tam používají certifikáty - veřejný klíč vám pošle sám server spolu s certifikátem, a vy si podle certifikátu ověříte, že klíč patří opravdu tomu, s kým chcete komunikovat.

Certifikát tedy nijak nesouvisí s luštěním komunikace. Falešný certifikát by bylo možné použít jedině tak, že byste komunikoval s někým jiným, než s kým chcete (a s ním byste si dohodl to heslo pro symetrické šifrování - dotyčný by tedy nic neluštil, prostě by dešifroval jemu známým klíčem).

Závěr - SHA-512 je dostatečný hash, 4096 bitů je dostatečná délka RSA klíče, 500 znaků je nesmyslně dlouhé heslo, nicméně celý systém nebude zabezpečený vůbec nebo jen velmi málo, protože tam budou chyby v návrhu i v implementaci.

Počítačová bezpečnost se nedá dělat způsobem, že použijete něco silného a nevíte ani proč ani jak - v případě počítačové bezpečnosti musíte mít správný nástroj, ale také musíte velice dobře vědět, jak ho použít. Jako příklad lze uvést třeba nedávno dokončený audit TrueCryptu - prakticky nikdo nepochyboval o tom, že algoritmy používané TrueCryptem jsou bezpečné. Bez auditu kódu ale nikdo nedokázal říci, zda se používají bezpečným způsobem. Audit TrueCryptu dělali odborníci, přesto jejich výstupem bylo "jen" konstatování "těchhle pár věcí je nešikovných ale na bezpečnost by to nemělo mít přímý dopad, jinak jsme si žádného problému nevšimli". Kdyby bezpečnost záležela jenom na tom, jaké používáte nástroje, veškerý audit TrueCryptu by bylo "používá silné šifry: ano", a tím by byl audit hotov.

4825

Odkladiště / Re:Deaktivacia sluzby Google Analytics_ANO al. NIE?

« kdy: 03. 07. 2015, 21:10:41 »

Google Analytics je služba pro monitorování návštěvnosti webu. O jejím nasazení rozhoduje správce příslušného webu, vy jako uživatel to nijak neovlivníte. S přihlašováním do internet bankingu to nemá vůbec nic společného.

4826

Distribuce / Re:Minimalistická distribuce

« kdy: 21. 06. 2015, 09:42:14 »

Gentoo na Atomu je jiste hodnotny napad. To aby si tam rozjel distribuovanou kompilaci a dohodil tam k tomu nejakou pekne tlustou masinu, aby to pro vsechny ty plecky stacla kompilovat.

Ano, Gentoo není potřeba kompilovat na cílovém stroji. Nerozumím tomu "pro všechny ty plečky" - zkompiluje se to přeci jenom jednou, vůbec nezáleží na tom, na kolika cílových stanicích se pak balíček použije.

4827

Distribuce / Re:Minimalistická distribuce

« kdy: 21. 06. 2015, 08:10:05 »

Gentoo a dejte si tam jenom ty balíčky, které potřebujete.

4828

Vývoj / Re:Vlákna - Java

« kdy: 20. 06. 2015, 17:27:32 »

Ne, když zavoláte notify(), probudí se tím některé vlákno, které předtím na stejném objektu zavolalo wait(). Na zámky to ale nemá žádný vliv, zámek pořád drží vlákno, které zavolalo notify() (protože držení zámku je podmínkou volání notify()) a probuzené vlákno na tento zámek čeká. Přičemž to, že bylo vlákno probuzeno z wait() jej při čekání na zámek nijak neupřednostňuje před jinými vlákny čekajícími na tentýž zámek.

Pokud vlákno 2 předběhne vlákno 1 a zavolá notify() v okamžiku, kdy ještě nikdo nezavolal wait(), proběhne notify() na prázdno (nic neudělá, resp. vyšle zprávu k probuzení, která nikoho nezajímá, takže se zahodí). Vlákno 2 pak dokončí synchronizovaný blok, čímž uvolní zámek a může pokračovat vlákno 1. To získá zámek, začne provádět synchronizovaný blok, vyhodnotí podmínku a zjistí, že hodnota je nastavena, tudíž vůbec nevstoupí do cyklu a nevolá wait(). Rovnou vypíše "Predana hodnota", shodí příznak nastavení hodnoty a informuje případné čekající vlákno.

Na tomhle příkladu je vidět, že wait()/notify() má málo možností. Ten příklad bude fungovat, pokud máte jen dvě vlákna, jedno zapisující a jedno čtecí. Pokud budete mít víc vláken, může nastat třeba případ, že jedno vlákno čte, druhé čeká na čtení a třetí čeká na zápis. První vlákno přečte hodnotu a probudí některé z dalších dvou vláken - klidně to ale může být to druhé čtecí vlákno, které zjistí, že hodnota není nastavená a znovu se uspí. A pak už nikdo další nezavolá znovu notify(), takže ta tři vlákna budou čekat donekonečna. Přitom by stačilo probudit to třetí vlákno, které chce zapsat. Řešením je místo notify() použít notifyAll(), které probudí všechna vlákna. Ta vlákna, která chtějí číst, zjistí že není co, a znovu se uspí, a to zapisovací vlákno zapíše a zase probudí všechna čekající vlákna. Jak je vidět, je to lepší než předchozí případ (nedojde k uváznutí programu), ale není to efektivní, protože zbytečně probouzíte i vlákna, která stejně nebudou moci nic udělat. Ve skutečnosti tam totiž máte dvě podmínky - některá vlákna čekají na to, až bude hodnota nastavená (aby ji mohla přečíst), jiná vlákna čekají, až bude prázdná (aby tam mohla zapsat novou hodnotu). Když použijete zámky z java.util.concurrent.lock, můžete si k jednomu zámku navěsit kolik podmínek chcete a při změně stavu nějaké podmínky probudit jenom jedno vlákno, které čeká na splnění právě téhle podmínky.

4829

Vývoj / Re:Vlákna - Java

« kdy: 20. 06. 2015, 16:37:53 »

Vlákno 1 získá zámek (monitor) pro this. Následně zavolá wait(), což způsobí, že vlákno 1 ten zámek uvolní a uspí se. Následně vlákno 2 získá zámek pro this, zavolá notify(), tím probudí některé z čekajících vláken, například vlákno 1. Vlákno 1 ale  tu chvíli nedrží zámek od this, drží ho vlákno 2. Vlákno 1 tedy čeká na uvolnění zámku, a teprve když vlákno 2 zámek uvolní, získá ho vlákno 1 (nebo kterékoli jiné vlákno, které na ten zámek čeká - vlákno 1 prostě bude na zámek čekat tak dlouho, dokud ho nedostane).

Jinak v dnešní době je lepší používat třídy z balíku java.util.concurrent a java.util.concurrent.locks, dává vám to mnohem víc možností.

4830

O serveru Root.cz / Re:Podmínky použití roota - realita vs praxe?

« kdy: 04. 06. 2015, 07:28:04 »

Pokud například někdo má veřejnou IP adresu a k ní připojený záznam se jménem, pak jeho IP adresa je osobním údajem.

To se ale evidentně netýká anonymních příspěvků v diskusi, protože tam je pouze ta IP adresa, žádné další údaje, podle kterých by mohla být identifikována konkrétní osoba, se tam neukládají.