socketServer questions

[Paul Rubin]

rbt <rbt at athop1.ath.vt.edu> writes:
> > I don't understand the question.  HMAC requires that both ends share a
> > secret key; does that help?  
> 
> That's what I don't get. If both sides have the key... how can it be
> 'secret'? All one would have to do is look at the code on any of the
> clients and they'd then know everything, right?

Yes, clients have to keep the key secure.

> > What do you mean by verification?
> 
> I'm trying to keep script kiddies from tampering with a socket server. I
> want the server to only load a valid or verified string into its log
> database and to discard everything else. 

If the clients can keep a secret key secure, then use hmac.  Note that
if there's lots of clients, they shouldn't all use the same secret key.
Instead, for client #i, let that client's key be something like
  hmac(your_big_secret, str(i)).digest()
and the client would send #i as part of the string.  You'd use
#i to recompute the client's key and then use that derived key to
verify the string.  This is called "key derivation" or "key
diversification".  If an attacker gets hold of that client's key and
starts hosing you, you can disable that key without affecting the
other ones.  (The client is issued only the derived key and never sees
the big secret).

> Strings could come to the socket server from anywhere on the Net from
> any machine. This is outside my control. What is there to prevent a
> knowledgeable person from finding the py code on a client computer,
> understanding it and then being able to forge a string that the server
> will accept?

Yes, if you're concerned about insecure clients, you have a much more
complex problem.  But your x..z..y scheme is far worse than hmac.
Once the attacker figures that out, there's no security at all.

What is the actual application, if you can say?  Depending on the
environment and constraints, various approaches are possible.