Příspěvky

181

Server / Re:Databazy - programovanie/spravovanie

« kdy: 17. 05. 2014, 15:05:03 »

Tomu sa vravi "prakticka skusenost". Programator/analytik nie je vseveduci sef firmy aby rozhodoval, ci bude alebo nebude
branit sekretarke natlacit 3x ten isty VIN do aplikacie na vecne veky a nikdy inak.

Ano, praktická zkušenost to bohužel je. A na základě této praktické zkušenosti potom vznikají situace, jako že je třeba vymáhána pohledávka pro zcela jiném člověku podobného jména nebo bohužel neunikátního rč a nikdo se nenamáhá to řešit. Do systému to naťukat lze, počítač řekl, že dlužíte, tak plaťte.

Pokud má někdo za úkol napsat systém pro evidenci vodizel, tak VIN je pro měj dostatečně unikátní už z definice na to, aby z něj mohl být i PK. Protože v běžném režimu se nemůže stát, že dvě různá vozidla mají stejný VIN. Pokud se tak stane, nelze nad tím mávnout rukou, naopak se to musí řešit mimořádně. Systém, který umožní zapsat dvě vozidla se stejným VIN jaksi nikoho nenutí to řešit a v praxi to dopadne nejjednodušší možnou cestou, že to tam dotyčný operátor prostě nechá.

182

Server / Re:Databazy - programovanie/spravovanie

« kdy: 17. 05. 2014, 14:55:16 »

To jako když se mi sejdou tři auta se stejným VIN, mám je uložit do systému? Co to je za nesmysl?

Nedivím se, že pak ty IS stojí za starou bačkoru, pokud každý uvažuje takhle...

+1

183

Server / Re:Databazy - programovanie/spravovanie

« kdy: 17. 05. 2014, 14:45:40 »

Externí čísla se v praxi vždy po čase pokazí. I když zákazník odpřísáhne na smrt své matky že sériové číslo bude unikátní, stejně za rok začne vyrábět různé komponenty se stejným sériovým číslem.

Takže místo toho, aby si to zákazník opravil a zabránil by tak větším zmatkům do budoucna, tak se v DB udělá další, jiné, seriové číslo? To osobně nepovažuji za zlepšení.

184

Server / Re:Databazy - programovanie/spravovanie

« kdy: 17. 05. 2014, 14:43:40 »

Hlavne treba pisat query tak, aby DB pochopila, co chcete a ako to chcete. Ak to nepochopi, tak typicky robi na disku nejake sialene JOINy a to je skoro isty zabijak vykonu. Zle su aj full scany, ale na joiny sa to nechyta.

Pokud jsou data strukturovaná dle normálních forem, používají se správné datové typy a indexy jsou tam, kde dle prováděcího plánu mají své opodstatnění, tak to nemůže být pomalé. Stejně tak používání funkcí nad datovými typy přímo v db nemůže (by nemělo být) pomalejší než při jejich zpracování v programu (je tam navíc roudtrip mezi serverem a klientem).

185

Server / Re:Databazy - programovanie/spravovanie

« kdy: 16. 05. 2014, 14:25:59 »

Ano, mnoho lidí tvrdí, že to co se naučili ve škole se v praxi tak dělat nedá. Je to asi jejich omluva pro to, aby to mohli nabastlit jak jim to od ruky upadne.

Co se týče optimalizace, dle mé praxe plyne, že je důležité zejména pochopit návrh db, tedy alepoň normální formy. Potom už to db engine zpracuje vyhovujici rychlosti. Když se použijí vhodné datové typy a funkce k nim, je to už skoro dokonalé. Další optimalizace už záleží na situaci.

Co z praxe považuji za horší je to, že v praxi vlastně nikdo neví (konkrétně zadavatel), co se do té DB bude dávat a co získávat. Neexistuje žádný model dat, před samotnou analýzou a všechno se bastlí za běhu. Takže i DB schémata, které na počátku mají hlavu a patu se po x iteracích změní na 40 záznamů typu VARCHAR (255), a to jen proto, že dodavatel dat v průběhu používání programu 80x změnil formát dat (zdravíme státní zprávu).

186

Odkladiště / Re:Autor na nějakém webu potřeboval pomoc...

« kdy: 18. 03. 2014, 15:22:40 »

Možná to bude znít hloupě, ale po tom, co jsem si pročetl bych doporučil vyhledat pomoc psychologa. Ono nemít práci a mít tři děti, je psychicky jistě dost náročné a to čeho jsme svědky může být výsledkem onoho vypětí. Podle mne to chce najít správnou cestu, a když člověk nemá sílu na to, aby ji našel sám, tak není žádnou ostudou vyhledat odbornou pomoc. Třeba potřeboval vypustit jen páru a už je zase v pohodě, ale také se to může více stupňovat. Byla by škoda, aby se to nějak na dětech podepsalo. Nikoho k ničemu nemůžeme nutit, ale požádat ho o zamyšlení se nad celou situací snad nikomu neublíží.

Na základě tohoto jeho blogového zápisku jsem si přečetl některé jeho předchozí a i tam psal dost "nesmiřitelně". Z toho, co jsem si přečetl zde na jeho blogu jsem usoudil, že to bude opravdu velmi těžko zaměstnatelný člověk.

Asi opravdu potřebuje pomoc od někoho zcela jiného, než jsou diskuse na rootu.

187

Vývoj / Re:Šifrovací knihovna s obtížným dešifrováním

« kdy: 04. 02. 2014, 17:03:42 »

Co mi brání s nekonečným výpočetním výkonem (tedy libovolně silný problém lousknu okamžitě), vyzkoušet i celou plejádu možných šifer? Ať si ten problém definuji jakkoliv, s nekonečným výkonem to bude hotové za nekonečně malou dobu. ;-)

Jinak, napadl mě další důvod, proč to nefunguje. Je to problém dvojích hesel. Spousta lidí věří, že si ssh zabezpečí tak, že zabrání přístupu rovnou na roota. Nejdřív je heslo na uživatele, potom na roota. Pokud bychom měli heslo (obě z nich) složité 64b, tak jaká bude výsledná síla? Člověk neznalý problematiky odpoví 128b. Ne. Bude pouze 65b. Dvěma hesly jsme problém ztížily pouze 2x. Přitom k heslu stačí přidat jedno písmenko z množiny 64 znaků, a složitost se zvýší 64x, tj na 70b. Přidáním jednoho znaku hesla jsme pro bezpečnost udělali více, než zakázáním přístupu na roota. Pochopitelně, když se vypne přístup hesly a používají se výhradně klíče, jsme opět úplně někde jinde.

Nevím, zda se zrovna tento problém týká zrovna zde navrženého postupu a zkoumat to nehodlám, ale takových podobných pastí je kryptografie plná.

188

Vývoj / Re:Šifrovací knihovna s obtížným dešifrováním

« kdy: 04. 02. 2014, 15:53:35 »

Omlouvám se, že se vám pletu do diskuse na kterou si stačíte jistě sami, ale tohle mě dostalo:

Evropské, tedy bavíme se o všech Evropských znacích vycházejících z latinky, příkladem je písmeno Č nebo š, prostě cokoliv, kde hlavní písmeno pochází z latinky a lze ho napsat pomocí kódů UTF

Skoro se mi to chce nechat bez dalšího komentáře a jen bych se zeptal, zda daný text může obsahovat také čísla?

K tomu zbytku. Vycházíte ze špatného předpokladu. Bezpečnost se nedělá tak, že útočník něco neví. Právě naopak, moderní kryptografie se dělá za předpokladu, že útočník ví úplně všechno (kromě soukromého / tajného klíče). Celkem dost algoritmů, které si autor / společnost někde sama pro sebe vymyslela, skončilo velmi neslavně. Proto i NIST dělá veřejné soutěže na nové standardy AES a SHA, do kterých se přihlásí spousta týmů (které už jsou sami o sobě na velmi vysoké úrovni), zveřejní vše, a celý svět se několik let pokouší o útoky. A i v těchto soutěžích spousta algoritmů neobstojí (a teď si představte, že si třeba takový tým najme soukromá firma pro své vnitrofiremní šifrování, bez soutěže je slušná pravděpodobnost, že ten alg je obecně vadný). Po mnoha letech se určí ten nejlepší.

Různé zesložiťování vstupního textu se dělalo před několika stoletími. S příchodem statistické kryptoanalýzy popadaly jako hrušky. Tyhle přístupy prostě nefungují. I mnohem modernější metody, založené nikoliv na práci s textem, ale čistě matematické postupy založené na grupách, také mají své slabiny. Proto se obecně také nedoporučuje skládání šifer (AES+Twofish), protože obecně nikdo neví co se stane. Jedna šifra může částečně dešifrovat druhou. To se stalo u DES. DES byl slabý, ale 2DES ještě slabší. 3DES je v pohodě použítelný dodnes (používá se 3x alg. DES s určitým způsobem upravenými klíči).

Připomínám, že šifra se má za prolomenou ve chvíli, kdy se prokáže její oslabení, tedy např. že místo síly 128b má například 90b; což je samo o sobě stále dost. Ale ta šifra už je nalomená a neměla by se používat -- a to i za stavu, že se nikomu reálně nepodařilo dostat k původním datům, 90b je stále moc. Proč? Protože už se našla cesta. Bylo to krásně vidět na případu md5, kdy se nalezla nějaká zranitelnost, která tu funkci lehce oslabila (celkem nic moc), ale za pár měsíců se na základě tohoto poznatku došlo do stavu, kdy to byla hračka i pro slabý NTB. Bohužel dodnes, po 10 letech, je md5 stále moc oblíbená u vývojárů.

Takže, bezpečnost svého algoritmu vůbec neprokážete tak, že se s někým vsadíte. Naopak tím (že to nikdo v této sázce nelouskne) pouze sám posílíte svůj falešný pocit bezpečí. A to není pro bezpečnost nikdy dobře.

189

Server / Re:Co když ztratím SSH klíč?

« kdy: 30. 01. 2014, 11:55:12 »

Pointa je v tom, že existují hesla, která nejdou lousknout vůbec - a nejsou ani tak složitá. Například největší veřejně známý distribuovaný cracker má momentálně 20 Pcrack/s. Heslo náhodně složené z a-zA-Z0-9-_ dlouhé 15 znaků by louskal 2000 let.

Jen pro doplnění, NIST / NSA doporučují kvalitu hesla alespoň 112b, tj při rozumné množině znaků je heslo asi tak 24 znaků dlouhé.

Na druhou stranu, pokud nejaký mamrd toto heslo nahashuje pomocí 64b hash fce (nebo rovnou pomocí nějaké prolomené fce), tak je vám jakkoliv kvalitní heslo poněkud k ničemu. Zbude z toho max 64b entropie a to už není takový problém lousknout. Dneska je nutné používat min 224b hashe.

190

Server / Re:Co když ztratím SSH klíč?

« kdy: 30. 01. 2014, 11:49:24 »

Trhlina je v tom, ze utocnik musi napred prolamat passphrasi. Pokud ji mate dostatecne hutnou, bude to na sve PS/2 farme louskat treba tyden nebo i mesic. A az to rozlouska, zkusi se prihlasit a zjisti, ze jste mu zatim vymazal klic a on palil elektrinu nadarmo. A vetsina potencialnich utocniku PS/2 farmu nema, treba ja bych to na svem HW neroslouskl ani za sto let, i kdybych ze vsech stroju, co se mi tu vali, udelal louskaci cluster.

Týden nebo měsíc? To spíše miliardy let. Pokud vím, jsou soukromé klíče šifrovány pomocí aes a pokud ta implementace není oslabená a používá dostatečně dlouhé bloky (více než 224b, tzn třeba AES-256), tak je to nelousknutelné.

Jinak k původnímu dotazu. V praxi se používají dva přístupy, jak zacházet s klíči.

* Jeden říká, že klíč patří ke stroji, kde byl vygenerován a nikam se nestěhuje. Tzn pro každý stroj, ze kterého se budu na server přihlašovat, mám spešl pár klíčů. Pokud dojde ke kompromitaci stroje, stačí vymazat pouze tento jeden klíč (na serveru) a jsem v klidu, nemusím měnit další klienty.

* Druhý přístup je ten, že existuje pouze jeden pár klíčů, a při jeho kompromitaci je nutné je vygenerovat znovu. Všechno stojí a padá na tom, jak dobře jste schopen tento jeden klíč ubránit (což jde v praxi docela těžko).

Samozřejmně, že v praxi se používá kombinace obou přístupů. Je také dobré si uvědomit, že pro různé případy můžete používat jiné klíče. Tzn pro skripty, pro synchronizaci dat, pro přístup na shell apod.

V každém případě ale platí, že pokud dojde ke kompromitaci soukromého klíče, je nutné ze serveru co nejrychleji odstranit jeho veřejný protějšek. Potom se útočník ani po případném lousknutí passphrase nikam nedostane.

Dál a to už je nad rámec tohoto dotazu. Je také dobré se zamyslet nad tím, co se stane, kdyby se útočník na ten účet opravdu dostal. Co všechno může a co nemůže. K čemu se dostane apod. Bezpečnost nestojí pouze na jedno aspektu. Pokud budu počítat s tím, že "to ssh" jde nějak prolomit, tak můžu mít další opatření, která povedou k tomu, že útočník se sice někam dostal, ale tj tak vše co udělal.

191

Odkladiště / Re:Založení blogu o IT/programování.

« kdy: 26. 01. 2014, 09:57:49 »

Celkem doporučuju začít prostě psát a uveřejňovat. On se z toho ten blog časem vyloupne sám. Určitě budeš několikrát měnit jeho vzhled, cms, apod. Důležitý je ten obsah, ten začni vydávat hned (i kdyby to měla být statická stránka).

Opačný postup, tedy uděláme fanstastické zázemí, redakčák, všechno, a potom začneme psát, podle mě nefunguje. Potom se totiž stane forma důležitější než obsah a to je konec.

192

Odkladiště / Re:Zatopení hostingu Casablanca

« kdy: 25. 01. 2014, 20:32:32 »

Např. u nás se domnívám, že si s tímto naběhla státní správa. Samozřejme konkrétní lidé.

Problém je jinde. Není to ta nebo ona technologie. Státní správa neví co chce. Neví. A přesně to poptává. Potom stačí, aby se do situace vložil nějaký "poradce", který v tom vidí (oprávněně) snadný přístup k opravdu velkým penězům. A poradí státní správě jdi tím směrem. A jde. Potom vznikají kaskvily jako datové schránky (to se dalo zvládnout podobně jako v německu pouze pomocí elektronického podpisu a emailového klienta), software pro soc. dávky, registr vozidel a další. On vlastně nikdo neměl zájem na tom produktu. Dodavatel chtěl peníze a státní správa dál neví.

A nejsou to jen ty celorepublikové projekty. Jde o jednotlivé úřady. Jako IT oddělení na všech možných úřadech nedělají nic jiného, než že volají dodavatelům. Místo toho, aby to IT samotné vykonávalo ty činnosti (min. do počtu lidí by na to sami stačili), tak na všechno mají dodatele. Na všechno. Nic sami neumí / nedělají (no proč, protože by za to nesli odpovědnost, takhle mají splněno tím, že informovali dodavatele a dál už to není jejich problém). Musím říct, že je velmi příjemné, když mi (jakožto zaměstnanci jednoho z dodavatelů) zavolá nějaký člověk z úradu a opravdu ví o co jde. To jsou vyjímky.

193

Odkladiště / Re:Zatopení hostingu Casablanca

« kdy: 25. 01. 2014, 10:28:05 »

Cena, dostupnost, bezpečnost a použitelnost jsou spojené nádoby.

No právě. Jako nechtěl bych být v kůži kluků z casablanca int, na druhou stranu si dovedu představit jejich pocit bezpečí před touto událostí. Bezpečí typu: naše řešení přežije výpadek 20% disků současně, mohou odejít 3 výpočetní nody, máme dvojité napájení ze dvou větví distributora, máme dva diesel agregáty, máme zálohy, máme hotovo. Jako to že na tu serverovnu spadne ta budova (obrazně), proti tomu se zajistit nedá. Samozřejmně, pokud říkají do očí (mě ano), že mají HA cluster geograficky oddělený, tak ho mají mít. Ale po technické stránce si dovedu představit, že na této lokalitě udělali maximum.

A to není málo, znám i další poskytovatele housing / hosting řešení (nebudu jmenovat), kteří slepě věří tomu, že se nic nestane, že disk vydrží, že raid je záloha, že zdroj neodejde apod. Ono je to taky o té ceně, pokud zákazník platí tak akorát na jeden disk ročně, tak asi nemůže očekávat, že o svá data nikdy nepřijde.

194

Odkladiště / Re:Zatopení hostingu Casablanca

« kdy: 25. 01. 2014, 10:13:33 »

Pokud provozujete nějakou službu, která si nemůže dovolit výpadek, kritické office „v cloudu“ atd., tak musíte mít skutečný cloud/HA cluster, tedy geograficky oddělené lokace s replikací dat a failoverem, když jedna z lokací spadne. V baráku se nemusí rozbít jenom voda, může tam hořet, může tam spadnou letadlo nebo přistát ufoni. HA řešení nemusí být u některých typů služeb ani tak drahé.

Casablanca u svého cloudu říkala, že se jedná o HA cluster na dvou oddělených lokalitách. Říkal mi to přímo jejich obchodník (jsou to už dva roky), osobně na schůzce a ukazoval nám lokalitu umístěnou v HC8. Nakonec jsme do toho nešli a máme (taky v HC8) umístěnou vlastní technologii. Naštestí nebyla vodou zasažena.

Ovšem kdybychom se spoléhali na slova přímo z úst zástupce Casablanca INT, tak máme dneska hodně velký problém. (Nevím, jak by to bylo ošetřeno smluvně, žádnou smlouvu na cloud jsem od nich nečetl, ale určitě tam není plná odpovědnost za způsobené škody.)

195

Odkladiště / Re:Podivne diskusie na Zdrojak.cz

« kdy: 24. 01. 2014, 14:47:47 »

Podobne je na tom web elektrika.cz. Par revizaku a projektantu rozhoduje o tom, ktery prispevek pusti do fora a pak si na nem honi ego a z tazatele udelaji totalniho ...

Jenže diskuse.elektrika.cz není volné diskusní fórum, ale aktivně moderované. Mě osobně se moc líbí a chodím si tam číst, když jsem otráven z IT diskusí, kde si každý mele to své, aniž by měl o problematice elementární znalost. Tam mají tu výhodu, že existují normy, a když někdo plácá kraviny, tak ho srovnají (mají čím). Ono nakonec, jde o život.