Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform
johan.tibell at gmail.com
Wed Mar 20 19:14:28 CET 2013
On Wed, Mar 20, 2013 at 11:00 AM, Bardur Arantsson <spam at 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
> > as well. For example, many general DoS protection mechanisms (timeouts,
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries