As has already been said, the current protocol was always known to be insecure, it was only meant to stop people from *trivially* circumventing it (e.g. if the actual key was present in the server code). If we ever introduce an actual account system, we will of course use something more secure.
I have an algorithm that is completely secure, but sadly requires an authority (gangarrison.com for example). It works like this:
The authority (ganggarrison.com) knows a secret key. This same secret key is given to the haxxy award winners.
When a server starts up it asks ganggarrison.com for an unique ID. The authority returns that ID, and a hash calculated as md5(id + haxxykey). Lets call the ID the serverID and md5(id + haxxykey) the serverhash.
When a client connects to a server and says it's a haxxy winner the server will send it's serverID to the client. Then the client sends the md5(serverID + secretkey) back to the server and the server will check if it matches with it's serverhash. If it does the client is a haxxy award winner.
Note that this algorithm can easily be changed around to use sha1 or something else instead.
Why is this algorithm secure? Well, first, since only the MD5 is taken from secretkey PLUS id it means that the algorithm implicitly uses a salt removing the possibility of using rainbow tables to extract the secretkey. And because the client never sends the secretkey but the hash of it + serverID to the server the server can't steal the key.
This protocol is not secure though, since someone can open a server with the serverID of an existing server. He cannot learn the actual key this way, but at least a temporarily valid token for authenticating on a selected server.
It is also a security problem that the server (a potential attacker) is allowed to choose the salt value used by the client, effectively destroying any additional entropy that a salt is supposed to provide.