Sorry for a delayed reply Andrew..

Wow, excellent point!  And to think, my original thinking in the "punishment"
aspect was to protect against a DoS attack; let me tell you about my naive
reasoning just for your entertainment..

 - I was thinking in the context of a coordinated DoS attack where million
computers with different IP's would merely try to flood the server with bogus
requests; merely slowing it down so that other users could not be productive.

 - the client-server framework has two layers of operation, the lower layer
which deals with ByteArrays and Sockets, the upper layer which deals with
first-class request and response Objects.  The upper-layer uses the
lower-layer.

 - By punishing originators of bad requests, I smugly thought each of those
million computers would only get one request past the lower-layer which would
black-list their IP and then all subsequent requests from them would be
rejected at the lower layer a much higher speed because the request bytes
wouldn't have to be materialized.

So it would be able to reject them at a rate of millions per second instead of,
say, merely thousands per second.  I hadn't considered an attack where they
impersonate a real user and thus block the real person.

Perhaps I've been premature in even concerning myself with an attack of this
type and scale at this point..  :)

> I'm not saying you shouldn't do this, I'm just saying that it needs to be
> rigourously thought through first.

Evidently so!  Thank you for helping me think about this!  I'll post again
after some more thinking and research (I found a security anti-patterns paper
which I haven't had time to read yet).  I hope you will entertain some
rigourous thinking with me again soon..

Regards,
  Chris


--- Andrew Gaylard <andrew.gaylard at aircom.co.za> wrote:

> Chris Muller wrote:
> 
> >Now that Magma has power-outage security, I'm designing security to protect
> >against hacking and would like to get feedback on the following approach.
> >
> >Basically, I want to punish senders of invalid or forged transmissions by
> >blocking their IP for a period of time.
> >
> [ snip ]
> 
> >On the server-side, an incorrect next-random results in punishment of that
> IP
> >(blockage for a period of time).  On the client-side, an incorrect
> next-random
> >results in immediate disconnection from the server with a Warning signaled.
> >
> >
> Chris,
> 
> Be careful with this strategy.  Attackers might deliberately provoke the
> blocking behaviour with carefully crafted (mis)information to trigger a
> denial-of-service attack against your own perfectly valid IP addresses.
> 
> I'm not saying you shouldn't do this, I'm just saying that it needs to be
> rigourously thought through first.
> 
> Andrew.
>