Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 260 261 [262] 263 264 ... 375
3916
Vývoj / Re:Hašování uživatelských hesel
« kdy: 16. 06. 2017, 16:41:35 »
Pokud má někdo na to, aby vykradl databázi a vůbec začal smysluplně luštit hesla, stejně s největší pravděpodobností začne právě u klienta, kterého rozebere na součástky a začne si dělat představu, co tím chtěl básník říct a co může očekávat.
Pokud se ke klientovi dostane. Dnes se velice často používají webové aplikace, kde je klientem databáze webový server – a už bylo velmi mnoho úniků dat z databáze, kdy útočník nic jiného než data z databáze neměl.

Samozřejmě, pokud by to byla klient-server aplikace, kdy uživatelská aplikace přímo přistupuje k SQL databázi, to je něco jiného, tam nemá smysl globální hash do klienta ukládat. Ale u takové aplikace je otázka, zda má vůbec smysl řešit zabezpečení na takové úrovni, že se budou solit a hashovat hesla.

3917
Vývoj / Re:Hašování uživatelských hesel
« kdy: 16. 06. 2017, 09:15:08 »
V ideálním případě by hash hesla měl vzniknout už u klienta a server by se nehashované heslo neměl nikdy dozvědět. Ale budu řešit současný reálný stav, kdy se na bezpečnost kašle.

Sůl bych raději generoval v aplikaci, máte pak víc pod kontrolou její parametry, např. jak bude náhodná. Také omezíte prostředí, kde se heslo vyskytuje jen v otevřeném tvaru (bude to jen vaše aplikace, databáze otevřené heslo nikdy neuvidí).

Dále, když chcete hesla zabezpečovat tímhle způsobem, bych doporučil kombinovat dvě soli – jednu náhodnou individuální pro každé heslo (která bude uložená spolu s tím heslem), a druhou globální, která vůbec nebude uložená v databázi. Pokud by pak došlo k úniku dat z databáze, nemůže útočník hádat heslo ani jednoho vybraného uživatele, protože mu bude chybět ta globální sůl. (Samozřejmě to není všespásné, pokud útočník získá administrátorská práva na serveru, kde běží aplikace i databáze, získá jak databázi tak globální sůl. Ale bohužel jsou překvapivě časté úniky, kdy útočník získá jen data z databáze.)

Také bych doporučoval ukládat si k heslu a soli i ID „algoritmu“, kterým jste to vytvořil (klidně jen pořadové číslo verze). To vám umožní v budoucnosti plynule změnit třeba hashovací algoritmus, globální hash nebo prostě celý způsob, jak „hesla“ ukládáte.

3918
Server / Re:Zjištění, jak dlouho existuje emailová adresa
« kdy: 14. 06. 2017, 11:28:56 »
Ne. Ona totiž e-mailová adresa fakticky ani neexistuje – pouze poštovní server pro danou doménu přijímá či nepřijímá e-maily pro zadanou e-mailovou adresu. Někdy se také používá doménový koš, že všechny e-mail pro neznámé adresy padají do jedné schránky. Každopádně ten poštovní server může pro danou e-mailovou adresu jednu hodiny e-maily přijímat, další hodinu ne, a další hodinu opět ano. Nebo dokonce může e-maily pro danou adresu přijímat jenom od někoho, zatímco ostatním bude tvrdit, že takovou adresu nezná.

3919
Nechápu, k čemu směřuje dotaz – i PGP/GPG používá šifrování veřejným klíčem. Jinak šifrování veřejným klíčem je obvykle implementováno tak, že se zvolí náhodný klíč, tímto klíčem se zašifrují vstupní data symetrickou šifrou, a k tomu se připojí onen vygenerovaný náhodný klíč zašifrovaný veřejným klíčem.

Nezná někdo nějaký komprimační program který dokáže jednoduše použít na soubory public key ?

V unixovém světě se často používá koncepce, že jeden program dělá jednu věc. Takže soubory spojíte do jednoho tarem, pak je zkomprimujete třeba pomocí xz nebo bzip2 a nakonec zašifrujete pomocí gpg nebo openssl.

3920
Sítě / Re:Proxy pro https
« kdy: 09. 06. 2017, 08:03:28 »
Role, které ho ani nepřímo nepotřebují ke své práci, ho mají kompletně blokovaný
Mohl byste aspoň naznačit, jaké role to jsou? Dneska je na internetu prakticky všechno, a co tam ještě není, u toho se řeší, jak to dělat „pohodlně přes internet“. I ten poslední podržtaška podle mne někdy potřebuje něco přeložit, stáhnout si nějaký návod, formulář, najít ordinační dobu závodního lékaře, jeho adresu nebo spojení k němu. Opravdu by mne zajímalo, zda existují role, které internet k práci nijak nemohou využít, nebo zda je to „sice jim to trvá dýl, ale nakonec si nějak poradí i bez internetu“.

3921
Sítě / Re:Proxy pro https
« kdy: 08. 06. 2017, 17:22:54 »
Kazdopadne problem blokace facebook a streamovacich sluzeb je obrobvsky. Jak donutite aby lidi ve firme necuceli na videa?
Dáte jim práci ;-)

At si ctou na netu, ale jak zacnou volat lidi, ze jim nejdou stahnout emaily, protoze nejaky dement ve vyrobe ma zaple full hd video z youtubu, ksichtbook, ... to je na posrani.
To chápu, ale to je myslím úplně jiný problém. Řekl bych, že to mnohem lépe řeší QoS a omezování rychlosti déletrvajících spojení. Pokud někdo bude běžně používat web ke své práci, žádné omezení nepozná. Teprve pokud začne něco stahovat nebo streamovat, dané spojení se mu zpomalí (čímž se zároveň efektivně dosáhne toho, že nebude blokovat linku ostatním). A nemusíte řešit, které všechny weby máte zakazovat – prostě ať bude streamovat  nebo stahovat odkudkoli, nikdy tím nezahltí linku.

A i pokud byste chtěl blokovat konkrétní weby, pořád bych to dělal jen na základě SNI hlaviček HTTPS, nebo by nejspíš stačilo blokovat je v DNS. Dešifrovat HTTPS komunikaci je mnohem větší zásah do komunikace, spoustu věcí tím rozbijete, musíte všude instalovat certifikáty své autority, a hlavně tím na sebe přebíráte odpovědnost za to, že všechny certifikáty ověřujete správně. A přihlášení klientským certifikátem (třeba bezpečné přihlášení do datových schránek) vám takhle nebude fungovat vůbec.

Shrnul bych to – MitM na HTTPS komunikaci bude komplikované a způsobíte si tím spoustu problémů, a nebudete pak mít čas řešit ten problém, který jste chtěl řešit původně, tj. vyžírání kapacity internetové přípojky nedůležitým provozem.

3922
Sítě / Re:Proxy pro https
« kdy: 07. 06. 2017, 21:43:12 »
V první řadě si musíte rozmyslet, co znamená „webová adresa“ – zda je to jen doménové jméno, nebo celá URL. V prvním případě můžete kontrolovat jen SNI a zakázat navázat HTTPS spojení bez SNI. V druhém případě musíte dešifrovat HTTPS spojení, tedy podvrhnout všechny certifikáty, a to už jsme u té nebezpečnostní politiky firmy, kde vám maximálně popřeju hodně štěstí. Že se tím rozbije DANE je řekl bych prkotina, dnes je horší, že se tím rozbije HPKP – nevím, zda prohlížeče umožňují nějak administrátorsky HPKP vypnout.

3923
Vývoj / Re:Java - značkovací interface
« kdy: 05. 06. 2017, 22:17:40 »
Takový potomek by však nesplňoval LSP, neměl by tedy vůbec vzniknout.
To platí možná v případě, pokud se programuje čistě objektově. To ale není moc častý případ, dnes se většinou programuje „s objekty“, nebo jak to nazvat. Stačí, že si třeba do objektu potomka serializovatelné výjimky uložíte neserializovatelný objekt – parametr, který výjimku způsobil – a rázem máte neserializovatelný Serializable objekt.

3924
Vývoj / Re:Java - značkovací interface
« kdy: 05. 06. 2017, 22:12:09 »
Ale existují rozhraní, kde to dává smysl, třeba javax.net.ssl.TrustManager
Podle mne teda nedává smysl celý package javax.net.ssl od první do poslední třídy, a rozhraní TrustManager v tom není výjimkou. To není značkovací rozhraní, i v JavaDocu má napsané, že je to base interface. Zřejmě podle autorů  toho rozhraní je trust manager něco, co neumí vůbec nic.

javax.net.ssl má smysl akorát jako ukázka toho, že někteří programátoři dokáží v C++ programovat v libovolném jazyce. Kdybychom na to měli jenom Xerces, mohlo by se říct, že je to náhoda nebo omyl – proto máme stejným stylem naprogramované ještě javax.net.ssl, aby bylo jasné, že to byl záměr. Problém je v tom, že zatímco Xercesu se lze celkem snadno vyhnout, bez javax.net.ssl se v Javě neobejdete, pokud chcete používat SSL/TLS.

3925
Vývoj / Re:Java - značkovací interface
« kdy: 05. 06. 2017, 19:16:44 »
Jen poznamka - marker interface zdedi i potomci tridy, zatimco anotace je konkretni tride.
Což je zrovna u toho Serializable špatně.

Jak píšou ostatní, používalo se to v případech, které se dnes řeší anotacemi. Ty příklady z Effective Java ukazují zase jen příklady, kdy mají současné anotace v Javě nějaká omezení a může se vyplatit hackovat to pomocí značkovacích rozhraní místo hackování anotací.

3926
Vývoj / Re:Relace nad KV databází
« kdy: 03. 06. 2017, 21:06:48 »
Pojem relační implikuje hledání podle indexů. Když nevíš, jak se to implementuje, tak kušuj (to platí pro všechny trolly).
Nikoli. Pojem „relační databáze“ je založený na matematických relacích a znamená, že máte data reprezentovaná v tabulkách (relacích), přičemž všechny řádky tabulky mají stejné sloupce. S indexy to nemá vůbec nic společného. Tabulka relační databáze je například i následující seznam osob s datem narození:

  • Eliška, Malá, 19. 3. 1986
  • Jan, Novák, 13. 6. 2001
  • Tamara, Brzobohatá, 17. 12. 1967

V KV databázi to vyjádříte tak, že jednotlivé řádky uložíte třeba jako hodnoty s vnitřní strukturou, nebo do hodnot LV databáze uložíte jednotlivé hodnoty (hodnotu atributu pro daný záznam), ale strukturovaný bude klíč (třeba ID_záznamu.ID_atributu).

3927
Windows a jiné systémy / Re:Jaký antivirus používáte?
« kdy: 02. 06. 2017, 08:29:01 »
Jaký Firewall?
Žádný. Firewall nemůžete „mít“ – firewall můžete jen nakonfigurovat a pak jej provozovat. Což drtivá většina uživatelů počítačů neumí. Navíc na pracovní stanici je firewall zbytečný. Pokud uživatel používá nějakou aplikaci s přístupem k internetu, tak asi chce, aby měla přístup k internetu. Pokud na počítači provozuje nějaké služby dostupné ze sítě, buď je to záměr, nebo je má zapnuté omylem – pak to jednak nebude řešit ani na firewallu, jednak pokud by to chtěl řešit, není potřeba firewall, stačí tu službu prostě vypnout nebo správně nakonfigurovat.

Firewall má smysl jedině jako další pásmo obrany před chráněnou sítí. Ale samozřejmě ho musí provozovat někdo, kdo ví, jaké služby mají být v té chráněné síti dostupné, a podle toho firewall nakonfiguruje a udržuje.

3928
Windows a jiné systémy / Re:Aky antivirus pouzivate?
« kdy: 30. 05. 2017, 21:57:04 »
Lidem kolem mne, kteří mají Windows 10, nechávám Windows Defender. Sám ho mám dnes nainstalovaný taky, protože je to bez práce a je to nejsnazší cesta, jak ve Windows umlčet to varování, že je počítač nechráněn. Dříve jsem nepoužíval žádný antivirus, protože antivirus, který má chránit systém, jehož je součástí, je principiální nesmysl – jakési výsledky to dává jen na špatném operačním systému s nepoučeným uživatelem, kdy to občas může trochu suplovat některé bezpečnostní funkce, které zanedbal autor operačního systému.

3929
Jen tak od boku, co třeba server využívající NIO a snažící se minimalizovat zatížení GC? Java totiž neumí alokovat efektivně a deterministicky na zásobníku, takže se musí šaškovat s pooly apod. Jako cvičení asi dobré a užitečné.
(Aneb „napište znovu a lépe Netty nebo Apache MINA.“)
To je asi ten nejhorší možný nápad (i kdyby to bylo k něčemu dobré). Za prvé, aby mohl optimalizovat něco, co jde proti přirozenému způsobu používání Javy, musel by Javu velmi dobře znát – aby věděl, čemu přesně se chce vyhnout, a jaké jsou naopak silné stránky, které může využít. A za druhé by se tím Javu moc nenaučil, protože by se nedozvěděl, jak se Java běžně používá.

3930
Najděte si nějaký OSS projekt a a přispějte do něj. Tím se naučíte mnohem víc, protože se nebudete zabývat jenom svým vlastím kódem, ale uvidíte i kód ostatních.

Stran: 1 ... 260 261 [262] 263 264 ... 375