I also would want a better explanation of what the "(blockage for a 
period of time)" is going to solve.  As the other Andrew rightly 
pointed out, the IP address is likely spoofable, allowing for DoS type 
attacks.

Do requests happen on separate socket connections?  Is that why you are 
interested in doing authentication on each request?  If not, would it 
not be easier to just authenticate the connection and then allow any 
requests from that client?

In any case, it seems to me that the very next kind of security that 
you might want to implement would be to add some privacy to the request 
and the result, which would probably best be implemented with something 
very SSL/TLS like.  Might it not be better to just implement SSL/TLS 
first and be done with it?

This would also have the advantage of being an extensively 
peer-reviewed protocol, so there'd be far less chance of some 
"obvious-to-someone-who-hasn't-looked-at-it-yet" kind of mistake.

-andrew

On 0-Aug, 2005, at 0:59, Andrew Gaylard 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.
>
>> 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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 10249 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050820/28f8fd3e/attachment.bin