|
|
|
|
|
by sootzoo
5280 days ago
|
|
Not endemic to PHP, of course, as it seems MSFT took the same approach with a recent ASP.NET security update. The workaround described in their KB (http://support.microsoft.com/kb/2661403) is to add a similar configuration override and they've set the limit arbitrarily at 1000 form keys. Which vendors did not dodge the hash algorithm problem and what's the updated algorithm you're referencing? Who's doing this right? |
|
Ruby 1.9 was already randomizing the hashes whereas this current rediscovery of the problem caused them to fix it by randomizing in 1.8 too. Same goes for Python.
The best link to the algorithm I found on a quick search is here http://www.hardened-php.net/hphp/zend_hash_del_key_or_index_... - where the problem was discussed again in 2006.
By randomizing I mean randomizing that value for h for the lifetime you need your hashes to be consistent (until the script ends in PHP)
While you are still vulnerable to attackers who know what that random initial value is, finding that by just randomly trying to create the collisions is impractical and easily detectable.