<!–texy–>[14] Samozřejmě, protože hašovací funkce má stejný výstup pro stejný vstup – pokud tedy v jednom microtime přijde více požadavků, tak bude mít hašovací funkce 100% kolizní stav. V podobném případě je dobré přidat nějaké unikátní ID k hašovanému základu.

<!–texy–>[8] Muzu potvrdit. Sice nechapu jak se to mohlo stat, ale na pokud jsem generoval jmena uploadovanejch souboru jako sha1(microtime()) dochazelo ke kolizim.

<!–texy–>abych byl konkrétnější – pokud bude mít "někdo" dostatečné znalosti a s tím dostatečné možnosti, tak tě před prvotním brutal atakem nic neochrání (chci se robotem přihlásit – a jak toto ochránit neřešíme) a pokud budeš blokovat IP adresy můžeš zavařit serveru (požadavků na přihlášení budu mít z proxin mnoho a uděláš si to sám). Otázku mám zda se o prolomení bude někdo snažit. – výsledek těchto kroků mi tedy dávají jedinný možný způsob jak získat přístup do aplikace – vyplňovat ti formulář pro přihlášení – a pokud jsme u toho toto vyřešit znamená provozovat přihlašovací skript na neznámé doméně. (zajímal by mě tvůj názor, ale znáš to…)

<!–texy–>tady to, ale není za jistých okolností k ničemu. Je třeba pokusit se zabezpečit vše i z jiných hledisek

<!–texy–>[10] Díky za postřeh, v uvedeném smyslu jsem aktualizoval text článku.

[9] zkusme to spočítat. Z praxe mám vyzkoušené, že návštěvnost/počet zobrazení ve špičce/hod odpovídá asi desetině až osmině návštěvnosti/pageviews za den. Takže server s (malým) počtem 10.000 stránek za den má ve špičce cca 10.000/8 = 1250 stránek. Tj cca stránku za každé tři vteřiny.

Dále podle zdrojáků PHP se generátor inicializuje pomocí funkce gettimeofday(), která vrací čas s přesností na mikrosekundy. Otázka je, s jakým rozlišením skutečně pracuje. Dejme tomu, že s plným. Pak by pravděpodobnost byla 1/3mil. Vzhledem k návštevnosti by ke kolizi došlo každých 300 dní.

Na rovinu, ve hře je ještě několik dalších faktorů, které mohou celý ten výpočet rozcupovat na kousky. Ale něco na tom možná bude, protože jsem si právě teď při průzkumu zdrojových kódů PHP všiml, jak se v souboru session.c generuje SID:

hashovaci_fce(REMOTE_ADDR . microtime . combined_lcg)

:-)

[5][6] Když to bereš takhle, tak cookie pro permanentní přihlášení skutečně může mít hodnotu SID, tomu nic nebrání. Jak jsem ale už psal, pro jakýkoliv token obecně to vhodné není.

[6][7] S nulou na začátku to byl samozřejmě jenom jednoduchý ukázkový příklad pro účely článku.

[8] Otázka je, jak moc pravděpodobná tahle situace je. Nicméně dobrá, buďme ještě papežštější než papež. Pro případ paralelního běhu aplikace na více strojích najednou lze navíc přidat ještě IP adresu daného serveru. Pro případ současného přístupu dvou lidí za jednou IP adresou můžeme přidat třeba User-Agenta. Další nápady? :)

Jen drobnost – pokud generátor pseudonáhodných čísel se inicializuje pouze podle aktuálního času, může dojít k tomu, že dva requesty probíhají (z pohledu rozlišovací schopnosti té časové fce) ve stejný okamžik a dojde k vygenerování stejného ID. Není proto špatné přidat ještě entropii například v podobě: md5(xyrand() . $_SERVER['REMOTE_ADDR']) apod. Tady je (ad [5]) už použití hashovací funkce nutností, protože přídavek obvykle nesplňuje podmínky náhodného čísla.

Jak je který generátor implementovaný je nelepší mrknout do zdrojáků PHP. Spoléhat se na dostatečnou přesnost generátoru času nelze, podobný omyl způsobil, že na Pentiích nad 200 MHz přestaly fungovat aplikace psané v Turbo Pascalu.

ahoj,

..while ($token{0} == '0');

pokud by šlo o distribuovaný útok, tak útočník může snadno odhalit tvoje pravidlo. proto by bylo lepší:

..while (moje_tajna_checksum_funkce($token) == '0');

Proc vymyslet neco co uz je davno implemtovano.
Session_id je dost bezpecne a generuje dostatecne nahodne tokeny.

"Důležité je, že zvolené pravidlo musí zůstat v tajnosti"
- takze to tvoje uz v tajnosti neni, co? :-)