ad 0, 2: Challenge neni cas, ale poradove cislo, ten cas je v tabulce jenom proto, aby se dala dobre uklizet.
Ale nejlepsi reseni to neni, da se tim udelat DoS:
Uzivatel A dostane challenge X, uzvatel Z (zaskodnik) dostane X+1, ale zkusi odeslat svuj formular se svym heslem a challenge X, kdyz bude rychlejsi nez A, vymaze radek s challenge X z tabulky "challenges" a uzivatel A se neprihlasi. Kdyz tohle bude uzivatel Z opakovat dostatecne rychle, zabrani urcitemu procentu uzivatelu v prihlaseni. (ne ze se bude porad tupe prihlasovat, ale bude si opakovane nacitat prihlasovaci formular, dokud se mu challenge budou zvetsovat jen o 1, vidi, ze je tam sam, jakmile se mu challenge zvysi vice nez o 1, vi, na jake challenge ma utocit)
Obrana:
A. Limitovat pocet zobrazeni prihlasovaciho formulare na 1 adresu
+ zaroven to brani prilis rychlemu rustu tabulky challenges
- velka firma za http proxy s 1 IP adresu bude mit problem
- Porad jde udelat DDoS :-)
B. misto predikovatelne challenge z auto_incrementu pouzit neco jineho, napr.
$UNIQUE_ID (ovsem neresi nadmerny rust tabulky "challenge"). Pridelenou challenge
si ale misto do databaze muzu ulozit do $_SESSION a mam tim i zajistenu vazbu na browser, kteremu jsem challenge poslal (viz bod 6) a nemusim se starat o udrovani tabulky challenge v rozumnych mezich.
Názor k článku
Bezpečné přihlašování uživatelů
