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.
Pokud chápu, jak to funguje, tak je ten ASIC specializovaný na SHA(root + nonce++). To se asi jen tak někde nevyužije.Díry v SHA, které by umožňovaly ze znalosti SHA(X) snáze spočítat SHA(něco odvozeného z X), snad ještě objeveny nebyly. Takže to musí být specializované na počítání SHA() z čehokoli, a to se přeci jen občas používá. Třeba díky tomu zažijeme boom elektronického podpisu :-)
Je v tom takový „drobný“ rozdíl, že v případě té sousedské výpomoci to není nelegální – zákon na to pamatuje a takovýhle drobný přivýdělek je od daně osvobozený a ani se nepřiznává. Samozřejmě něco jiného je, pokud se tím někdo živý.Pane Novák, tohle není na hraně zákona ale daleko za hranou zákona. Cituji Vás : " Ale jdi... Firma může dál podnikat v Kč aleJde o to, že to neprokážete... Bitcoinová síť je v zásadě anonymní. Uvidíte tam, že Franta přes dva prostředníky převedl bitcoiny Lojzovi. Ale už nezjistíte, že ti prostředníci byli nějaké firmy, co jim za ten převod poskytly službu.
Je to jako u té sousedské výpomoci. On mi poseká trávník a já mu za to nechám něco ze zabíjačky. A to i v příapdě, že jsem řezník na ŽL. Chtějte po něm, aby se z takového obchodu platily daně.
Brej večír všem. Zase otravuju, bota mě sice netlačí, ale pokračuju ve studiu iptables. Jelikož mám přímo na veřejse debian s FW, potřeboval bych poradit, jakým způsobem prioritizovat pakety na ssh spojení, potažmo obecně na nějaký port, nebo více portů. Neptal bych se, kdybych věděl, co se vlastně ptát strýčka googla. Budu vděčný i za klíčová slova pro strýčka.S iptables to nijak nesouvisí. Hledejte traffic shaping nebo QOS. Jinak pokud nemáte domluven QOS s ISP (což se vám na spoji za pár drobných asi nepodaří domluvit), můžete rozumně ovlivňovat jen odchozí směr. Příchozí se ovlivňuje tak, že zahazujete příchozí pakety a doufáte, že se protistrana dovtípí, že má posílat pomaleji.
děkuji.
Vypadá to velmi zajímavě, dost vám fandím. Kritika si zde je, ovšem já patřím k těm, kteří chtějí obchodovat s bitcoiny a ne se jenom přetahovat kdo toho ví více o IT.Lidí, kteří chtějí obchodovat s vašimi bitcoiny, je víc. Ti myslím doufají v brzké spuštění tohoto projektu ještě mnohem víc než vy.
nechat programátora, aby prezentoval komerční produkt byla dost zásadní chyba, ale ještě větší chyba byla v následné panice zkoušet jeden přes druhého napravovat způsobené škody (přičemž každý říká něco jiného). A vůbec nejhorší chyba byla nechat ho tady vykecávat dál a ještě víc to rozmazávat. Tolik k té komunikaci.Úplně první chyba ve vztahu k veřejnosti bylo vůbec vystavovat takovéhle nedodělané demo, a ještě navíc na produkční adrese. Pokud chtěli využít příležitost, stačilo vystavit pěknou stránku s popisem, jak to celé bude fungovat a proč to bude bezpečné, s formulářem pro zadání e-mailu, na který se budou zasílat informace o dalším postupu služby. Přesně takhle to dnes startupy dělají, neutrhnou si ostudu hned na začátku a ještě získají e-maily lidí, kteří projektu fandí, kteří jsou ochotni jít na začátku do neodzkoušené služby, berou to tak vážně, že dokonce i zaregistrují svůj e-mail -- a pokud se s nimi bude dobře pracovat, získají dojem, že se podílejí na něčem zajímavém, a budou službu zadarmo dál propagovat.
Nesouhlasim s citaci nahore - pri opakovanych dotazech nemusi prepared statements vest na cele care, dokonce muzou prohrat na cele care, zalezi na hodne vecech. Databaze si zpravidla dela plan SQL dotazu pri vytvareni prepared statementu, je-li volba planu zasadnim zpusobem zavisla na parametrech, muze DB udelat plan spatnej a pak dotazy trvaji dlouho - casto se to deje, napriklad pri nerovnomernem rozlozeni hodnot na indexovanem sloupci.Podle toho, jak jsem rychle prolétl popis kešování MySQL, kešuje dotazy i s hodnotami. Což podle mne odbourává jednu docela zásadní výhodu prepared statements, na druhou stranu, výše uvedený problém pro MySQL neplatí. Druhá věc je, že výše uvedená věc je docela speciální případ a nemá smysl kvůli tomu měnit zpracování všech SQL příkazů. Pokud nastane, je potřeba ho ošetřit v tom jednom případě. Ono asi stejně bude nutné přidat v takovém případě další podmínku nebo něco takového, protože s uvedeným problémem se rozumně nevyrovná ani aplikace. Pokud se v jednom pohledu uživateli běžně vrací deset záznamů, a najednou se mu jich tam vrátí milion, co s nimi bude dělat, bude po jednom je procházet?
napsat "SELECT * FROM table WHERE x = ".(int)$x mi prijde uplne OK a nikoho bych za to nekamenovalAle k čemu je dobré to takhle zapisovat, má to nějakou výhodu? Já vidím hlavně nevýhody. Nesmíte nikde zapomenout na to přetypování; řetězce musíte řešit jinak; jakmile ten příkaz bude delší, bude to nepřehledné; SQL dotaz se sestavuje až při prvním použití, takže prakticky nemůžete udělat statickou kontrolu dotazů...
prepared statements jsou pomalejší (každý ten příkaz znamená ping pong s mysql serverem tedy latency)Jaký ping-pong? Víte, co jsou prepared statements? Víte, jak komunikuje knihovna v PHP s MySQL serverem? Když máte dotaz s vloženými daty, ten se pošle na server, server se podívá do cache, zjistí, že tam dotaz ještě není. Rozparsuje ho, vytvoří exekuční plán, provede a vrátí výsledek. Při použití prepared statements se dotaz s balíčkem dat pošle na server, server se podívá do cache, vytáhne z ní už hotový exekuční plán pro daný příkaz, provede a vrátí výsledek. Síťová komunikace je pořád stejná, akorát pro opakované dotazy jste serveru ušetřil parsování dotazu a sestavování exekučního plánu.
prepared statements v zásadě jen řeši obrovskou neschopnost programátorů ošetřit si apostrov (a mysql programátorů ten správný apostrof v tom textu najít)Nikoli, prepared statements jsou už dávno základní režim, data vložená přímo do SQL příkazu je jen pomůcka určená pro rychlé testování a prototypování. Pokud si myslíte, že jediným problematickým znakem je apostrof, pak ta aplikace musí vypadat… Jinak tipnul bych si, že spousta SQL injection vznikne tak, že programátor si ošetří „apostrof“, ale pak se ukáže, že se ošetřuje dvakrát, tak jedno ošetření odstraní – jenže pro jinou větev programu bylo to odstraněné ošetření jediným ošetřením, a SQL injection je otevřené.
Proč ten kód nepoužijete, když ho tam vidíte?Prosím vás, hlavně nikdy nedělejte na zabezpečení něčeho fyzického. Pokud byste trval na tom, že bezpečnostní díru lze prokázat jedině tak, že se někomu opravdu podaří zastřelit strážného, mohli by to odnést nevinní lidé.
Po té třešničce jsem definitivně pochopil, že je to marné – ale vy se ještě překonáváte. Nedáte rovnou do placu heslo roota, když je to nastavení produkčního prostředí tak nepodstatné?- chybí třešničkaOMG!
Komu není rady, tomu není pomoci.
Přesně tak, přeceňuješ nastavení produkčního prostředí. Carlos to dělal taky. dopadl přesně tak jak dopadl. Proto nemohu tyhle rady poslechnout, sorry.
Z toho usuzuju, že je fajn mít super extra zámek a ocelové dveře a mříž na dveřích, ale nesmím ve sklepě nechat otevřené okno a v celý barák volně průchozí. Podle mého názoru zabezpečení se nesmí soustředit jen na dveře.To je jedna z věcí, kterou jsem chtěl napsat v předchozím komentáři, ale pak jsem to vynechal. Když tohle víte, proč pořád dokola píšete, že chcete hodnotit jen jeden aspekt vaší aplikace, a všechno ostatní bagatelizujete a omlouváte tím, že je to jen demo?
Otevřený SSH, banner v apachovi... neříkám, že by se to nemělo podceňovat, ale na druhou stranu, je to až to poslední a zároveň to nejjednoduší, co jde zabezpečit.Ve vašem pojetí zabezpečení, které jsem já nazval „bezpečnost tam nakonec nějak přilepíme“. Podle mne to žádné zabezpečení není, protože skutečné zabezpečení se nedá dělat tak, že vezmete hotový systém a ten na závěr zabezpečíte. To pak totiž nemůže skončit jinak, než mříží na dveřích a otevřeným oknem ve sklepě.
Asi jsem se blbě vyjádřil, nebo přecenil diskutující. Samzořejmě jsem chtěl prolamovat aplikaci a ne provádět cílený útok na servery virtualmasteru, jakože nemáme ještě žádný stabilní server na kterým poběží ostrý provoz. Za to se omlouvám. Na produkčním serveru žádný SSH být nesmí a ideální by bylo, kdyby to byla nejaka DMZ (beztak tam bude nějaký LBL, v nejhorším případě proxy). Myslel jsem si, že to lidem dojde.To je pořád dokola. I hostitelský systém a ISP jsou součástí bezpečnostního řešení, protože i přes ně může vést útok. Pokud se v tomto ohledu demo nasazení a produkční nasazení liší, musíte ty rozdíly přesně znát a je nepochopitelné, proč jste to do úvodního příspěvku nenapsal – vždyť to musela být v době nasazování dema jedna z nejdůležitějších věcí, kterou jste řešil. Navíc já jsme nepsal o hostitelském prostředí, ale o celkovém zabezpečení, což je vaše aplikace, systém, na kterém běží, hostitelský systém i sít ISP. Nemá smysl hodnotit jedno bez druhého.
Dobře tedy, každopádně, zatím největší problém jste skutečně objevil vy a to zapomenutý výpis chybové hlášky, což jsem následně fixnul. Jestli to byl nejhorší problém v celém systému, tak to vypadá dobřePrávě naopak, vypadá to hodně špatně. Je z toho totiž zřejmé, že místo „vytvoříme maximálně bezpečné prostředí, kolem kterého pak postavíme potřebnou funkcionalitu“ jste postupovali přesně opačně – „uděláme tam spoustu funkcí a pěkných tlačítek, a nakonec tam nějak přilepíme tu bezpečnost“. Takhle se dá postupovat u nějakého diskusního fóra nebo blogu, ale použít to pro systém, kde se mají točit nezanedbatelné peníze, to je cesta do pekel. Myslím, že přesně takhle postupovali autoři BIPS, Bidextreme.pl nebo Bitcash.cz, a víte, jak to dopadlo. Jediný bezpečnostní koncept, kterým jste se zřejmě zabývali, je to, že u vás žádné Bitcoiny nebudou uložené. To je dobrý nápad a dobrý začátek, ale nestačí to – pořád ještě je potřeba myslet na zabezpečení transakcí. Když to přirovnám k bance – nestačí zabezpečit, aby vám někdo nemohl ukrást peníze přímo z účtu, ale taky musíte zabezpečit, aby nikdo nemohl manipulovat s příkazy k úhradě a také aby se nikdo nedostal ani k výpisům z účtu (mimo transparentní účty je to považováno za citlivý údaj).
Jediný co mě na prepared statements vadí je jejich naprosto nepoužitelná syntaxe.Mně tedy připadají mnohem přehlednější, než slepování řetězců. Ale to je věc názorů – nicméně pokud se rozhoduju mezi přehledností a bezpečností, musí – zvlášť v případě, kdy jde o něco důležitého, třeba o peníze – vyhrát bezpečnost.
Nevím proč by se měla syntaxe dotazů měnit.Nejde o změnu syntaxe, ale o změnu v parsování věcí, které třeba ve standardu nejsou jasně řečené, případně v parsování příkazů, které jsou v rozporu se standardem.
Jiné jazyky používají taky escapování a dodnes to nikomu nevadilo. XML, JSON, prakticky každý formát používá escapy. Proč to vadí u MySQL?Odborníkům na bezpečnost to samozřejmě vadí odjakživa. Ono nejde jen o samotné escapování, ale o to, jak je složité a jaké má varianty. V XML je velmi jednoduché a jasně definované, chybnou syntaxi parsery rovnou odmítnou – takže ten problém, že dva parsery stejný vstup rozparsují jinak, prakticky neexistuje. Úplně jiné je to třeba u HTML, kde se různé parsery chovají i záměrně jinak – třeba podmíněné komentáře v MSIE. No a MySQL je někde uprostřed, rozparsuje i dost nestandardní dotazy, a to samozřejmě otevírá možnost, že real_escape něco vyhodnotí jako „v pohodě, jsme uvnitř hodnoty“, ale parser MySQL to vyhodnotí jako součást SQL příkazu.
Máte nějaký reálný útok zkrz real_escape?Nemám. Ale „umíme to lépe zabezpečit“ si rozhodně nespojuju s „víme o té hrozbě a umíme to snadno opravit, ale Googlem jsme nenašli informace o žádném reálném zneužití, tak budeme doufat, že to nikdo nezneužije zrovna proti nám“. Nevýhoda tohohle přístupu je také v tom, že to nikdo samozřejmě nebude zkoušet proti nějaké demoverzi, protože to není úplně snadné a motivace žádná. Až bude možné skrze ten web ukrást pár milionů, motivace bude výrazně vyšší a třeba se najde někdo, kdo si zjistí vámi používané verze MySQL a PHP, ty parsery si porovná a zjistí, jestli nějaká obskurní posloupnost znaků ten parser v PHP nezmate.
S prepared statement samozřejmě umím, ale přišlo mi to... pomalejší... komplikovanější.Mně to připadá jednodušší, není důvod, aby to bylo pomalejší – naopak při dobré implementaci a podpoře serveru to bude rychlejší, protože serveru nemusí parsovat každý dotaz znova, ale jenom sáhne do cache pro již dříve zpracovaný dotaz, který u sebe má rovnou i prováděcí plán.
OK, vzdávám to, pouč mě, jak jsi obešel mysql_real_escape...Na mysql_real_escape bych rozhodně nespoléhal, to není zabezpečení, ale pokus o zamaskování problému. Víte, jak mysql_real_escape funguje a jaké má předpoklady pro bezpečné použití? Jednak musíte zajistit, že programátor na každý vstup od uživatele tu funkci aplikuje právě jednou. To zajistíte jedině tak, že si to programátor ohlídá, otestovat to moc nejde – to není zrovna bezpečný přístup. Druhá věc je, že ta funkce má fungovat přesně inverzně k parseru SQL dotazů v použité MySQL. Opravdu jste si jist, že ve vaší verzi PHP je ta funkce přesně inverzní k vaší verzi MySQL? Že se to nezmění s nějakým minor updatem PHP nebo MySQL?
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
