On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson <s...@scientician.net>wrote:
> AFAICT, the hash function needn't be cryptographically secure (though > that obviously avoids the issue altogether) -- if there is some > determined-at-startup "salt" that's added in to all hashed values then > that should provide good enough protection. Obviously this will mean > that the hashes won't be repeatable across runs of the same program, but > that's usually acceptable for a hash function which isn't used for > content identification(*). > > (*) For which you should use a cryptographically secure hash anyway. > This is what Python did and unfortunately it's not enough as the salt can easily be recovered if you use a weak hash function. See the SipHash paper. > > SipHash is one way to address these kinds of attacks. There are other > means > > as well. For example, many general DoS protection mechanisms (timeouts, > IP > > banning, etc) also work on these kind of attacks. > > > > Timeouts aren't necessarily sufficient -- the application can keep > sending data (e.g. form parameter data) and can cause 100% cpu usage for > a loooooonng time. After that it can just start over. > But that limits how long the any given request can occupy the CPU for (as we will sever the connection after X seconds.) > IP banning can only happen after the problem occurs. > Not at all. $BIG_WEB_COMPANIES do it on the fly using $SECRET_SMART_SAUCE. Hash flooding is only one of many ways to DoS a server. You can try other things, like building a bot net and trying to flood the connection. Just as sandboxing is a better way to run untrusted software than trying to plug every whole in your code/RTS, generic anti-DoS techniques are usually better than trying to figure out every possible way someone can DoS you. -- Johan
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
