Důležité PRO Vývojáře: čtěte

http://www.soom.cz/index.php?name=articles/show&aid=512 tento článek by si měl povinně přečíst každý, začátečník nebo pokrořilý nebo expert, každý tam určitě najde nějakou tu novou informaci :) a pokud ne? Tak jedině dobře, každopádně by to měl každý přečíst...

hezke, o clickjackingu jsem si chtel neco precist, ted uz nemusim... diky :-)ale k tomu hashovani hesel bych mel vytku - sha1 ( md5 ( je spatne, zmensuje to vysledny prostor pro kolize,kdyz hash, tak z puvodniho retezce, nejlepe zakodovaneho a nebo zasifrovaneho, ja pak jeste vyslednou hash koduju do base64,cimz retezec trosku zkratim (je treba volat raw_output na hashovaci fci, jinak by to melo opacny vysledek)

"ale k tomu hashovani hesel bych mel vytku - sha1 ( md5 ( je spatne, zmensuje to vysledny prostor pro kolize," v tom clanku to ams vysvetlene a rozhodne s tim souhlasim, nebal bych se to projet hashovaci fci vicekrat

ok, delej jak chces, ja to delat nebudu, je to proste spatne - MNOHEM lepsi je zasifrovat hashovany retezec.a jeste neco k tokenum - nejak jsem to prehlidl - tokeny se negeneruji jenom z uniqid(mt_rand(), true), ale hlavne taky z ip adresy a user agenta - prave z duvodu, uvedenych v clanku, takze popsane je to hezky, ale priklad spatnej - a to vubec nemluvim o tom zkracovani, proboha proc? lepsi je predavat $algo parametr a volat ruzne hashovaci fce pomoci fce hash ( $algo, $str ), dostupne jsou ruzne algoritmy od crc az po sha512, kterou pouzivam napriklad pro hashovani uzivatelskych hesel. pro url tokeny pak pouzijes proste kratsi hashovaci fci.ale nechapej me spatne, ocenuju tvou snahu, a sem rad, zes sem hodil odkaz, jen vic takovych - rad si na tohle tema neco prectu znovu. ber to jenom jako takove rozsireni informaci.

a co tak pouzit standardny postup: SALT http://en.wikipedia.org/wiki/Salt_(cryptography)blbnutie s funkciami - problem je ze nezvysujete obtiaznost exponencialne ale len linearne (ak to niekto bude predpokladat, tak si vyrobi este druhu, tretiu, stvrtu verziu rainbow table).

? moc nechapu - salt je prece pouzita, to je jasne - server salt je co nejvice nahodna a jako user_salt slouzi login (to pouzivam uplne stejne, na ten ucel to staci)ale kdyz uz tady to tema je, tak prihodim svou verzi:$str = $serverSalt . $pwd . md5 ( $login, true );$pwd_hash = my_hash ( encrypt ( $str ), "sha512" );$serverSalt je pak co nejvice nahodna a rozumne dlouha - ovlivnuje silu vysledneho hashe, zejoencrypt () vola sifrovani dle klice v konfigurakumy_hash () je pak upravene volani hash (), vysledek encoduje do base64, aby nebyl zbytecne dlouhyje to jenom princip, v realu je to jeste konfigurovatelne a my_hash dela jednu "tajnou", ale z pohledu sily hashovaci fce naprosto neskodnou vec :-)---budu moc rad za reakce na mou verzi - at uz kladne nebo zaporne, jakekoliv

aha sry nevsimol som si ze md5($login.$password.$token) to s funkciami som myslel asi tak ze je to zbytocna snaha lebo ked niekto ukradne db plus php skripty tak vidi ze ako je to spravene a pouzie rovnaku transformaciu rainbow tabulkyimho uplne staci 1 nahodny salt... pozor aby z toho potom inac nebolo "security through obscurity" :)

Napsal vedouci;506645

je to jenom princip, v realu je to jeste konfigurovatelne a my_hash dela jednu "tajnou", ale z pohledu sily hashovaci fce naprosto neskodnou vec :-)

myslim ze to co pouzivas je absolutne v poradku, neni ta tajna vec nahodou ze obrtai poradi pismen ? :D (to em ted napadlo jako takova vychytavka navic)

Napsal AlesiBoss;506684

myslim ze to co pouzivas je absolutne v poradku, neni ta tajna vec nahodou ze obrtai poradi pismen ? :D (to em ted napadlo jako takova vychytavka navic)

neni, ale ikdyby, tak to nereknu, protoze je to tajne :-)

Salt je vhodnější skládat z unikátního řetězce pro web a unikátního pro každého uživatele (bohatě stačí třeba email+doména, z pohledu hashovacích funkcí je celkem jedno, jestli do nich cpete něco lidsky čitelného nebo ne). Prasárny s ořezáváním a kombinováním hashů - kryptografie je dost těžký obor a pokud někdo nedokáže (což se dělá dost blbě) jakým způsobem to zvyšuje bezpečnost, tak bych se držel osvědčených způsobů (nepoužívat MD5, nepoužívat SHA-1, které je za horizontem a používat rodinu SHA-2 - viz doporučení třeba NISTu). Kombinace může a nemusí přinášet nějakou výhodu. Hrátky se šifrováním v JavaScriptu - máme poměrně účinný způsob, jak zabránit odposlechu po cestě, říká se mu SSL/TLS. Má i další drobnou výhodu - víme, kam (z pohledu klienta) odesíláme data. Cookies a spol - ano, ale tak, že máte 2 tokeny: jeden pro nešifrované připojení, ten může být vázaný na nepodstatná data (typu údaje, jakou barvu pozadí má uživatel zvolený) a druhý přenášený jen šifrovaným kanálem (tzn. přiřazený i přes šifrovaný kanál, na to bacha), kterým se udržuje přihlášení třeba pro přístup k profilům (koukněte na Amazon.com pro pěknou implementaci). Blbosti s exit(0) - když už někdo někdy nahrál nějaké skripty na server, tak je stejně jedno, jestli tam na konci něco je nebo není, tak jako tak je třeba všechno ručně projít a vyčistit (nebo obnovit ze zálohy). Spíš než pitomosti o TotalCommanderu by stálo za zmínku SFTP/FTPS. DNSSec nic? Proti DoS se dá chránit na úrovni serveru (mod_evasive pro Apache, je to efektivnější než kdesi v rámci kódu webu - ten má zobrazovat obsah návštěvníkům). Chápu, že návod je určený pro lidi, co si po večerech na PHP-nuke ťukají klanové stránky, ale přeci jen by mohl být trochu na úrovni (ale soom.cz :-D ) - hodně rad tam je "mám nějakou díru na webu, ale udělám něco, co trochu zblbne podobného amatéra, jako jsem já, a budu v bezpečí".

Napsal karel.kohout;506847

Chápu, že návod je určený pro lidi, co si po večerech na PHP-nuke ťukají klanové stránky, ale přeci jen by mohl být trochu na úrovni (ale soom.cz :-D ) - hodně rad tam je "mám nějakou díru na webu, ale udělám něco, co trochu zblbne podobného amatéra, jako jsem já, a budu v bezpečí".

clanke mi prijde uzitecny - pokud ti prijde spatny, trapny, obsahujici kraviny, tak bys treba mohl napsat lepsi :) myslim ze by ti bylo hodne lidi vdecnych

Napsal karel.kohout;506847

Salt je vhodnější skládat z unikátního řetězce pro web a unikátního pro každého uživatele...

Presne tak to v clanku je, precti si jej poradne a pak kritizuj.

Napsal karel.kohout;506847

Pokud někdo nedokáže (což se dělá dost blbě) jakým způsobem to zvyšuje bezpečnost, tak bych se držel osvědčených způsobů (nepoužívat MD5, nepoužívat SHA-1, které je za horizontem a používat rodinu SHA-2 - viz doporučení třeba NISTu).

Uvedena metoda bezpecnost rozhodne zvysuje, nebot na ty tvoje "osvedcene" postupy existuji rainbow tabulky a ty jsou hojne vyuzivany. Ale i toto bylo v clanku zmineno, stacilo by se naucit cist. Hashovaci funkce z rodiny SHA-2 vyzaduji knihovnu mhash, ktera neni na mnoha serverech dostupna, navic uvedeny algoritmus zajisti ulozeni hesla ve tvaru, ktery neni mozne cracknout v dostatecne kratke dobe (pod miliardu let), ale ani toto si pravdepodobne nedokazes spocitat...

Napsal karel.kohout;506847

Hrátky se šifrováním v JavaScriptu - máme poměrně účinný způsob, jak zabránit odposlechu po cestě, říká se mu SSL/TLS. Má i další drobnou výhodu - víme, kam (z pohledu klienta) odesíláme data.

A na kolika webhostingovych serverech je ti nativne SSL/TLS poskytovano? Na tretine? Navic je ve clanku jasne zmineno, ze pro privilegovane uzivatele je potreba sifrovany kanal nasadit, ale to jsi pravdepodobne opet prehledl, ze?

Napsal karel.kohout;506847

Blbosti s exit(0)

Ukazkovy priklad tvoji kratkozrakosti. Ze je potreba nahrat cistou prezentaci je logicke. Nez to ale udelas (a nebudes-li mit ve svych scriptech tento radek), nakazi se mezi tim polovina navstevniku tveho webu malwarem a google te umisti na blacklist, Einsteine...

Napsal karel.kohout;506847

Spíš než pitomosti o TotalCommanderu by stálo za zmínku SFTP/FTPS.

Stejna situace, jako u SSL/TLS, kolik hostingovych spolecnosti ti dnes nabizi FTPS? Tretina? Kolik nemalych webu bylo v nedavne dobe hacknuto diky ulozenym heslum v TotalCommanderu? Opravdu ti gratuluji k tomu, ze sis precetl nejakou teoretickou brozuru o bezpecnosti, o realnem svete a praktickych moznostech nevis ale zhola nic...

Napsal karel.kohout;506847

DNSsec nic?

Ne, nic. Nikde neni uvedeno, ze jsou ve clanku zmineny veskere metody prevence utoku, nemluve o tom, ze DNSsec postrada pro klienty jakykoliv smysl, dokud jej ve velkem nezacnou aplikovat majitele DNS serveru (coz se k dnesnimu dni skutecne nedeje). To, ze sis nekde precetl o tom, jak je DNSsec cool, je sice fajn, ale bez hlubsich znalosti zustanes stale jen teoretickym kecalkem, ktery kritizuje neco, cemu naprosto nerozumi...

Napsal karel.kohout;506847

Proti DoS se dá chránit na úrovni serveru (mod_evasive pro Apache, je to efektivnější než kdesi v rámci kódu webu - ten má zobrazovat obsah návštěvníkům).

Modul mod_evasive neni nativni soucasti serveru Apache, navic je ve clanku uveden, opet sis ho neprecetl poradne, a presto si jej dovolujes kritizovat.

Napsal karel.kohout;506847

Chápu, že návod je určený pro lidi, co si po večerech na PHP-nuke ťukají klanové stránky, ale přeci jen by mohl být trochu na úrovni (ale soom.cz :-D ) - hodně rad tam je "mám nějakou díru na webu, ale udělám něco, co trochu zblbne podobného amatéra, jako jsem já, a budu v bezpečí".

Fakt, ze jsou tvoje znalosti zminovane problematiky na mizerne urovni, neznamena, ze je clanek spatny. Vypovida to spise o tvoji hlouposti, coz ostatne dokazal posledni odstavec, ktery jsi napsal... Emkei PS: Kritice podlozene argumenty se nebranim, uvedene snippety by sly urcite vylepsit, ale vetsina z vas zde az prilis zabredava do teorie, kde je sice mozne zvladnout cokoliv, v realnem svete tomu tak ale v drtive vetsine pripadu neni...

Napsal AlesiBoss;506855

clanke mi prijde uzitecny - pokud ti prijde spatny, trapny, obsahujici kraviny, tak bys treba mohl napsat lepsi :) myslim ze by ti bylo hodne lidi vdecnych

Užitečný je, jen mi přijde, že zbytečně zdůrazňuje opatření typu "schovávejte si doma peníze pod koberec" místo "kupte si bezpečnostní dveře a lepší zámek" (nemá význam řešit uložená hesla v TC, pokud mám zavirovaný počítač a podobně). Jediná vyložená kravina v článku jsou hrátky s MD5/SHA1, svědčí to o znalostech autora - algoritmy se často chovají "divně" (viz DES'(DES(X))) a co z té kombinace vypadne a nakolik to bude méně odolné než SHA-2 (případně neořezané SHA-1) podle mě nikdo neví. Zajímavé povídání třeba tady: http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-800-107.pdf

zrovna dneska jsem prochazel a upravoval prihlasovani v systemu - serverSalt a loginSalt jsem vypustil a nahradil je aktivacnim tokenem - ktery je sam o sobe nahodny, tudiz nahradi obe dve soli... a taky se musim opravit, nahodna sul je rozhodne lepsi nez user sul a server sul - uz z principu - je proste nahodna...a vystup z hashovaci fce samozrejme nesmime do db ukladat v plain textu, ale nejak upraveny, protoze se jednou dockame casu, kdy pro vetsinu hesel budou existovat predpocitane hashe - jestli ta doba uz tedy nenastala :-)

Flame :D

Napsal Emkei_;507247

Presne tak to v clanku je, precti si jej poradne a pak kritizuj.

Uvedena metoda bezpecnost rozhodne zvysuje, nebot na ty tvoje "osvedcene" postupy existuji rainbow tabulky a ty jsou hojne vyuzivany. Ale i toto bylo v clanku zmineno, stacilo by se naucit cist. Hashovaci funkce z rodiny SHA-2 vyzaduji knihovnu mhash, ktera neni na mnoha serverech dostupna, navic uvedeny algoritmus zajisti ulozeni hesla ve tvaru, ktery neni mozne cracknout v dostatecne kratke dobe (pod miliardu let), ale ani toto si pravdepodobne nedokazes spocitat...

Máš někde dokázáno, jak se tvůj postup chová? Nemáš, proto jednoduše nemůžeš vědět, co ti z toho na konci leze a jakou to má reálně složitost - jen hádáš a doufáš.

Napsal Emkei_;507247

A na kolika webhostingovych serverech je ti nativne SSL/TLS poskytovano? Na tretine? Navic je ve clanku jasne zmineno, ze pro privilegovane uzivatele je potreba sifrovany kanal nasadit, ale to jsi pravdepodobne opet prehledl, ze?

Šifrovaný kanál je rozumné nasadit pro všechny uživatele (ty před přihlášením víš, kdo je privilegovaný a kdo ne)? SSL/TLS nabízí na těch webhostingových serverech, na kterých si to zaplatím.

Napsal Emkei_;507247

Ukazkovy priklad tvoji kratkozrakosti. Ze je potreba nahrat cistou prezentaci je logicke. Nez to ale udelas (a nebudes-li mit ve svych scriptech tento radek), nakazi se mezi tim polovina navstevniku tveho webu malwarem a google te umisti na blacklist, Einsteine...

Když už někdo může upravovat data na serveru, tak je celkem jedno, co mám na konci skriptu - a pokud jsi někdy viděl logy po klasickém "ukradeném hesle z TotalCommanderu", a trochu si studoval, jak se chová nahrávající botnet a co za kód nahrává, tak by ti bylo jasné, že exit (0) si v pohodě vyhází. Navíc jakékoliv ručně upravené soubory znamenají, že se mi nebude chtít updatovat software, který si nepíšu sám (předpokládám ruční přidávání, skriptem tohle jde občas poměrně obtížně), což je mnohem nebezpečnější.

Napsal Emkei_;507247

Stejna situace, jako u SSL/TLS, kolik hostingovych spolecnosti ti dnes nabizi FTPS? Tretina? Kolik nemalych webu bylo v nedavne dobe hacknuto diky ulozenym heslum v TotalCommanderu? Opravdu ti gratuluji k tomu, ze sis precetl nejakou teoretickou brozuru o bezpecnosti, o realnem svete a praktickych moznostech nevis ale zhola nic...

FTPS je na webhostingu, na kterém si ho zaplatím - třeba by časem šlo o standardní službu, pokud ji někdo skutečně požadoval... Bezpečnost v reálném světě je založená na mnoha teoretických východiscích, bez kterých si jen tak hraješ - neshazoval bych teoretické brožury.

Napsal Emkei_;507247

Ne, nic. Nikde neni uvedeno, ze jsou ve clanku zmineny veskere metody prevence utoku, nemluve o tom, ze DNSsec postrada pro klienty jakykoliv smysl, dokud jej ve velkem nezacnou aplikovat majitele DNS serveru (coz se k dnesnimu dni skutecne nedeje). To, ze sis nekde precetl o tom, jak je DNSsec cool, je sice fajn, ale bez hlubsich znalosti zustanes stale jen teoretickym kecalkem, ktery kritizuje neco, cemu naprosto nerozumi...

Česká zóna je podepsaná, ve velkém ji majitelé DNS serverů začínají aplikovat, tak proč ji nezmínit (v textu jsou mnohem okrajovější věci). O DNSSec jsem si skutečně přečetl, že je cool, taky jsem si přečetl, že není cool (Bernstein), ale zatím jsem si nikde nepřečetl, jak ho hezky bez větší práce rozběhat v Bindu (pro víc než pár domén)... Tak se předveď.

Napsal Emkei_;507247

Modul mod_evasive neni nativni soucasti serveru Apache, navic je ve clanku uveden, opet sis ho neprecetl poradne, a presto si jej dovolujes kritizovat.

V době, kdy jsem článek četl, jsem tam zmínku o mod_evasive nezaznamenal, může to být moje chyba. Součásti nativní instalace Apache není spousta věcí, ale to není důvod je nepoužívat, ignorovat nebo nevyžadovat.

Napsal Emkei_;507247

Fakt, ze jsou tvoje znalosti zminovane problematiky na mizerne urovni, neznamena, ze je clanek spatny. Vypovida to spise o tvoji hlouposti, coz ostatne dokazal posledni odstavec, ktery jsi napsal...

http://board.pentester.cz/ Buď máš rád V1agru nebo kovářova kobyla chodí bosa... :D Což když už jsme u osobních urážek, na pentester.cz ti to ani po letech nevydělá na živnosťák / s.r.o., že musíš fakturovat na rodiče / pracovat načerno / dohody a u služby, která je o důvěře, skrývat jméno?