Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform

[Bardur Arantsson]

On 03/20/2013 07:14 PM, Johan Tibell wrote:
> 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.
> 

I see -- will check that paper. (I see now that some of the messages
already mentioned this -- should learn to read threads before replying.)

> 
>>> 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.)
> 

Yeah, but you just start another connection and start occupying it again
almost immediately. Certainly none of the current Haskell web frameworks
provide any protection against this.

> 
>> IP banning can only happen after the problem occurs.
>>
> 
> Not at all. $BIG_WEB_COMPANIES do it on the fly using $SECRET_SMART_SAUCE.
> 

Hehe :)

> 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.

Sure, but that's another step up in difficulty from using a single
client to DoS a server trivially.

> Just as
> sandboxing is a better way to run untrusted software than trying to plug
> every whole in your code/RTS,

(Citation needed). There have been lots of exploits of VMs and
sandboxes. This is also irrelevant to DoS prevention, AFAICT.

> generic anti-DoS techniques are usually
> better than trying to figure out every possible way someone can DoS you.

(Citation needed.)

There's no excuse for not preventing obvious an relatively easily
preventable problems. Security in Depth and all that.

Regards,