zabezpečení proti session hacku

Přemýšlím, zda je dostatečné zabezpečení proti session hacku kontrola IP. Při načtení indexu si vytáhnu z DB IP uloženou při přihlášení a porovnám s aktuální, pokud IP nesouhlasí, je uživatel automaticky odhlášen. ( Je toto dostatečné, nebo je lepší IP kontrolovat, před každým provedením dotazu na DB ( např.: editace práv atd), nebo se dá bránit ještě nějak líp?

Treba http://php.net/manual/en/function.session-regenerate-id.php by ti mohlo pomoct :)

ja kontroluji user-agent promenou a IP s tim, ze v pripade ze nesouhlasi, tak se proste session unsetne, coz vede k odhlaseni a zamezeni jakychkoliv akci, protoze samozrejme se pred pristupem do sekci ci k akcim vyzadujicim nejake opravneni kontroluje zda je prihlasen clovek s potrebnym opravnenim... a samozrejme session_regenerate_id po nekolika (rady jednotek) akcich/obnovenich stranky ale musim rict ze to za me dela framework, proc se s tim srat, kdyz staci pouzit hotova reseni :)

session_regenerate_id() slouží k zabránění podstrčení útočníkova SID oběti. Kontrola IP adresy je nedostatečná (útočník i oběť může být ve stejné síti). Nejlepší by bylo použít HTTPS a při obraně proti session hacku kontrolovat ip adresu a user-agenta. Ale jinak připadá mi zbytečné se bránit proti session hacku, když nepoužíváš HTTPS (předpokládám), protože útočník může pohodlně zjišťovat hesla, takže se ani nemusí namáhat s SID :)

kontrola user-agenta ma smysl - uzivatel asi tezko vymeni prohlizec a pritom porad zustane prihlaseny, ale je teoreticky mozne, ze si zaktualizuje prohlizec, takze to taky neni idealni jestli chces, kontroluj ip, ale jenom prvni 3 casti, ta 4ta se obcas meni "za behu" - a urcite nechces otravovat sve uzivatele zbytecnym odhlasovanim i tak to ale obcas muze odhlasit (ale nestava se to). obecne je ale uplne nejlepsi reseni zabezpecit zmenu hesla/emailu aktualnim heslem, povolit posilani sessiony jenom v cookie (cimz predejdes vetsine session utoku) a nejdulezitejsi cast - vytvorit blbuvzdorny system, kde se vlastne nic nesmaze hned - vse je v "kosi", kde to ceka na davkovy "pulnocni" script - takze kdyz ti zavola smutny zakaznik, tak se da vsechno vratit. a jak poznamenal mazlik - nejvetsi slabina je momentalne absence https, problem se zabezpecenim je ale obecne v tom, ze uzivatele jsou hloupi, jak se chces branit proti "socialnimu" utoku? no a samozrejme zalohy, zalohy, zalohy.