On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson <spam@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