Příspěvky

3631

Vývoj / Re:Java: String constants a velikost bajtkódu

« kdy: 18. 12. 2017, 16:21:11 »

Chci mít textovou konstantu přístupnou alespoň v podtřídách (protected) nebo ideálně kdykoliv a kdekoliv (public static) abych neměl tentýž řetězec naflákaný na padesáti místech kódu

Dejte to do nějaké třídy jako public static final konstantu.

zároveň nechci aby tím bytecode bobtnal

Že to nechcete má nějaký důvod? Nebo je to jenom rozmar? Pokud k tomu nemáte nějaký dobrý důvod, neřešte to.

nebo zpomaloval ...

Tak to neřešte, JVM si s tím pravděpodobně poradí daleko lépe. Pokud byste to přesto chtěl řešit, tak to neřešte. A pokud byste to i přesto chtěl řešit, zapněte si profiler a změřte, co aplikaci skutečně zpomaluje, a pak se zaměřte na to.

3632

Server / Re:Less v Bashi vypisuje jen na půl obrazovky

« kdy: 17. 12. 2017, 22:38:46 »

Jenom taková poznámka na okraj – jste si jistý, že na začátku toho souboru nejsou prázdné řádky?

3633

Distribuce / Re:Co si myslet o autorech OpenELEC?

« kdy: 17. 12. 2017, 22:36:39 »

Pokud mají autoři OpenELEC o bezpečnosti jiné představy, než vy, mohla by to být docela dobře zabezpečená distribuce. Protože vy tady zatím neomylně jmenujete povrchní věci, které mohou budit zdání bezpečnosti, ale se skutečnou bezpečností nemají moc společného.

Pokud chcete používat SSH, použijte bezpečnější způsob přihlášení, a to přihlášení klíčem. Máte to tam napsané. Pokud si někdo zapne SSH, asi ho chce používat. Pokud ho chce používat, bude muset zjistit, že je tam přednastavené defaultní heslo. Když to zjistí a bude ho chtít změnit, dozví se, co má dělat. Pokud bude někdo postupovat vaším způsobem, zapne si SSH, nechá tam výchozí heslo a nezakáže přihlášení heslem přes SSH, je to jeho chyba, nikoho jiného. Ano, bylo by pohodlnější zakázat přihlášení heslem rovnou a umožnit přes administraci nahrát klíč, ale to je jen věc pohodlí, ne bezpečnosti.

Pokud je /etc/shadow na read-only souborovém systému, je podstatně rozumnější vypsat při spuštění passwd chybovou hlášku s návodem, než jenom skončit s chybou, že nelze zapisovat do souboru jen pro čtení.

Vystavit roota na SSH není žádný mazec, je to normální. Pokud to zařízení nemá víc správců, což zařízení s OpenELEC asi nebude mít, není žádný důvod, proč se nepřihlašovat rovnou na roota.

Existují zabezpečení proti různým druhům útoků. Vy píšete o úniku dat, ale o tom vůbec nebyla řeč. Read-only systém může být způsob zabezpečení proti trvalému ovládnutí zařízení. Pokud zařízení nastartuje vždy v továrním nastavení, útočník nemůže zařízení trvale ovládnout.

Root s pevným a veřejně známým heslem nemusí být z pohledu bezpečnosti žádný problém, pokud není možné se heslem přihlásit. Ono je možné se do Linuxu přihlásit jako root i úplně bez hesla nebo jakéhokoli jiného ověření – a taky to není bezpečnostní problém, protože se takhle může přihlásit jenom někdo, kdo sedí u konzole při startu systému.

sudo je v systému, který má jediného správce, nesmysl. A sudo obecně s bezpečností nejde moc dohromady, protože se to před uživateli pokouší skrývat komplexitu bezpečnosti, kterou ale skrýt nejde.

Omluva spíš není pro to, když někdo mermomocí chce SSH v systému, ale neumí si ho nakonfigurovat bezpečně, aby bylo povolené přihlášení jenom klíčem.

3634

Odkladiště / Re:Je hashovaný údaj osobný údaj?

« kdy: 17. 12. 2017, 19:36:14 »

V rejstříku obyvatel (ROB) se rodné číslo používá jako jednoznačný identifikátor fyzické osoby.

Jestli se nepletu, jednoznačným identifikátorem fyzické osoby v základních registrech je ZIFO (a s ním se ani nepracuje přímo, ale dělá se "překlad" přes agendový identifikátor AIFO) a v ROB rodné číslo vůbec neni, rodné číslo je v AISEO

Přesně tak, v ROBu rodné číslu vůbec není (např. proto, že je v plánu rodná čísla zrušit a cesta k tomu jsou právě základní registry). Navíc ROB není rejstřík obyvatel, ale registr obyvatel.

3635

Odkladiště / Re:Je hashovaný údaj osobný údaj?

« kdy: 17. 12. 2017, 13:04:00 »

Budú to školenia pre interných zamestnancov.

To ty interní zaměstnance nemáte nijak identifikované? E-mail, login, osobní číslo? Navíc rodné číslo u nich už stejně evidujete, minimálně kvůli daném a jiným odvodům.

Je potrebné človeka jednoznačne identifikovať. Email si môže vytvoriť kde kto.

Co si představujete pod pojmem „jednoznačně identifikovat“? Já si pod tím představím to, že dva různí lidé nebudou mít stejný identifikátor. E-mail si může vytvořit kde kdo, stejně tak si kde kdo může vymyslet rodné číslo. Jednoznačné identifikaci by vadilo, pokud by jeden e-mail používali dva lidé – stejně tak se ti dva lidé mohou domluvit a mohou vám sdělit jedno rodné číslo.

3636

Odkladiště / Re:Je hashovaný údaj osobný údaj?

« kdy: 17. 12. 2017, 09:53:54 »

Dokonce existují čísla, která vůbec nesplňují pravidla, prostě je někdo asi omylem zapsal a zůstalo to tak, kdo ví, těm lidem to ale nezávidím, kdekoho napadne si validovat RČ a dále ho nepouštět.

Nejčastější případ je, že při výpočtu kontrolní číslice vyšlo, že by to mělo být 10 – rodné číslo se v takovém případě mělo přeskočit a použít další. Ale někdy místo toho dali jako kontrolní číslici nulu.

To, že by validace kontrolní číslice rodného čísla měla být měkkou kontrolou se aspoň trochu ví. Ale pokud by se někdy přidělila rodná čísla s přičtenou dvacítkou k měsíci, to bych teprve těm lidem nezáviděl, protože s tím nepočítá skoro nikdo.

ČSSZ vydávala cizincům bez rodného čísla nějaké svoje číslo, které vypadalo jako rodné číslo, akorát se něco přičítalo myslím ke dni narození. A někteří lidé si myslí, že tohle je jejich rodné číslo.

Zkrátka s rodnými čísly je zábava a už aby byla zrušena. Ale jako pomocný čistě orientační údaj jsou fajn…

3637

Odkladiště / Re:Je hashovaný údaj osobný údaj?

« kdy: 17. 12. 2017, 09:43:59 »

Pre rozsah našej aplikácie to vadiť nebude

Pořád mi chybí informace, zda jde o nějaká interní školení např. zaměstnanců, nebo školení pro veřejnost. V prvním případě už je stejně někde evidované máte, v druhém případě tam klidně může přijít někdo, kdo rodné číslo nemá, navíc to rodné číslo vůbec nepotřebujete – pro takovéhle případy je ideální e-mail.

Bolo by to len pre úvodné potvrdenie registrácie, prípadne reset hesla.

Rodné číslo takhle použít nejde, není to tajný údaj a teoreticky ho může znát kde kdo. Máte nějaký důvod neudělat to stejně, jako všichni ostatní – tj. použít e-mail?

3638

Odkladiště / Re:Je hashovaný údaj osobný údaj?

« kdy: 16. 12. 2017, 23:11:24 »

raději bych použil Argon2, než planý SHA.
A ať to alespoň chroustá vteřinu (i na silným počítači). Ono by toho útočníka potom omrzelo čekat na pouhé jedno rodné číslo cca. 20 tisíc let.

Dvacet tisíc let? Rodné číslo se skládá z data narození, pohlaví, trojmístného pořadového čísla a kontrolní číslice. Za rok se tedy teoreticky může vydat maximálně necelých 730 000 rodných čísel. (Teoreticky tedy dvojnásobek, protože pokud by rodná čísla v jeden den došla, k měsíci se ještě přičte 20, aby tak vznikla nová řada, ale pokud vím, takové rodné číslo nikdy nebylo vydáno. Ale pokud chcete, výsledek si klidně přenásobte dvěma.) Když budu počítat osoby od narození do sta let, dělá to tím tempem jedno rodné číslo za vteřinu necelého dva a půl roku. Na jednom počítači. To je 8 dní na stovce počítačů, necelý den na tisícovce. Ve skutečnosti se denně narodí zhruba 300 dětí, takže místo těch 2000 rodných čísel pro každý den mi jich stačí vyzkoušet třeba 400. Za půl roku budu mít vypočítané hashe rodných čísel pro celou ČR.

Ne, prostě když je na vstupu málo entropie, žádné hashování to nezachrání.

3639

Odkladiště / Re:Je hashovaný údaj osobný údaj?

« kdy: 16. 12. 2017, 16:44:14 »

Pokud by z hashe nešlo získat původní údaj, osobním údajem by neměl být. Problém je, že rodná čísla i čísla OP jsou tak krátká, že vyzkoušením všech možností ten původní údaj z hashe snadno získáte.

Rodné číslo není dobrý identifikátor, protože existují duplicity. Číslo občanského průkazu se zase v čase mění.

3640

Server / Re:Mail hosting přijímající spam

« kdy: 14. 12. 2017, 21:40:09 »

Předpokládám, že mailhosting bude některé e-maily odmítat hned při příjmu, takže pro vás by si museli vyhradit jiný server, a to dělat nebudou. Řešením je podle mne vlastní server, nějaký nejlevnější VPS – tam byste se měl vejít s cenou zhruba někde mezi 50 až 80 USD ročně.

3641

Sítě / Re:Jak zaznamenat SSL komunikaci pro pozdější dekódování

« kdy: 03. 12. 2017, 16:44:59 »

Pokud z nějakého důvodu nepotřebujete data přímo z prohlížeče, použil bych např. Burp proxy, která udělá na HTTPS spojení MitM útok (v prohlížeči si nastavíte příslušný certifikát proxy CA jako důvěryhodný). Pokud byste potřeboval komunikaci přímo z prohlížeče, potřebujete nakonfigurovat příslušnou SSL knihovnu, aby příslušné klíče ukládala – např. návod pro NSS (používanou Firefoxem) je zde: NSS Key Log Format.

3642

Server / Re:Apache vrací náhodně kód 403

« kdy: 01. 12. 2017, 19:39:05 »

Takže tu 403 vrací cílový server. To je klíčová informace. V tom případě byste měl pátrat tam a zjistit, proč přesně se ta autentizace nezdaří.

3643

Server / Re:Optimalizácia MySQL

« kdy: 30. 11. 2017, 20:43:34 »

A znova sa uvolni ramka a vsetko fici ako ma, ale jemi jasne ze toto neni normalne chovanie. Mohli by ste ma naviest co to moze robit ? popripade co je to za featuru ?

Ten skript je nějaká samodoma snaha o optimalizaci, jediné rozumné, co se s ním dá udělat, je zahodit ho někam hodně daleko. (Ten skript dělá to, že se snaží zaplnit RAM, tudíž donutí operační systém vytlačit z RAM věci, které tam být nemusí – např. nacachovaná data souborů. S velkou pravděpodobností ale vytlačí z RAM i data, která je užitečné tam mít. Skript nakonec paměť uvolní, takže systému zbyde spousta volné paměti, do které může zase začít nahrávat data.)

Kolko server potrebuje mat volnej pamati ram aby bol save, napr ked mam 16 GB server je tam apache, mysql, mam to nakonfigurovane tak ze je tam volnej ram od 2 - 4 GB je to ok ? alebo mozem napr pridat viacej mysql aby napriklad viacej vyuzivalo ram a bude to len 1 - 2 GB volnej. neni nato niaka rovnica ? mas 16 GB minimalne 10percent musi byt stale volnych.

Žádný takový vzorec neexistuje. Server nepotřebuje volnou paměť, potřebuje paměť na to, co dělá. Pokud má server trvale 2 GB RAM volné, jsou tam ty 2 GB zbytečné. Bez znalosti té aplikace se ale nedá říct, k čemu by se volná RAM dala využít – může být efektivní dát jí k dispozici databázi, může být efektivní umožnit v ní cacheovat soubory…

3644

Server / Re:Apache: 403 nahodne

« kdy: 30. 11. 2017, 19:02:47 »

Pokud by to byl timeout, nedostal by odpověď hned, ale až po vypršení timeoutu, což by předpokládám zaznamenal.

Podíval bych se na DNS. Jestli Apache občas nedostane nějakou divnou odpověď, případně jestli jméno nevede na více IP adres – např. IPv4 a IPv6. Je možné, že je cílový server třeba pro IPv6 špatně nakonfigurován, nebo adresa směřuje někam úplně jinam, a když Apache zrovna zvolí danou adresu, dostanete chybnou odpověď.

3645

Vývoj / Re:XML Konfigurace Springu a null reference jako výsledek

« kdy: 28. 11. 2017, 07:03:38 »

Evidentne mixujete property placeholder so SpELom...

V tom ale není problém. Problém je v tom, že potřebuje vložit null hodnotu – která se normálně vkládá pomocí elementu <null/>. V ref je ale název odkazovaného beanu, takže string. Cokoli jiného, než string, se na string převede – a null se převede na string "null".

Napadlo mne, zda by místo ref nešlo použít value. Je to obecná hodnota, ne název beanu, tak by tam null možná mohlo projít.