Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nightcracker]

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.

[Derpduck]

You could just swap the last 2 frames in the character sprite and make a sprite mod

[Saniblues]

Having something in a mod is a lot different than having something in the actual game that everyone sees.

[nightcracker]

You could just swap the last 2 frames in the character sprite and make a sprite mod

Perhaps you don't understand it. The game sees me as a legit haxxy award winner. The server sees me as a legit haxxy award winner.

[Haxton Sale]

You could just swap the last 2 frames in the character sprite and make a sprite mod

Perhaps you don't understand it. The game sees me as a legit haxxy award winner. The server sees me as a legit haxxy award winner.

Have fun then. 95% of people here wouldn't understand if you explained them how you did this.

[Derpduck]

it doenst really matter if everyone sees you with it, its not like they will like you more or anything and unless you alt as an actual haxxy winner people will realise that you didnt win a haxxy

[nightcracker]

Oh I didn't do it so anyone would like me or anything, just to show that the encryption is broken.

And the reason I'm still running around with it is just because it's funny

[Derpduck]

ok, it just seems a little pointless

[MedO]

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.

[nightcracker]

Instead of the server sending it's serverID, instead the client could ask ganggarrison.com what the serverID of IP x is (where x is the IP of the server we're connecting to). The updated scheme would look like this:

The server is started up and asks the authority for a serverID and md5(serverID + secretkey). When a haxxy client connects to a certain server it asks the authority the serverID of the IP of the server we're connecting to and it sends md5(serverID + secretkey) to the server. The server next authenticates by comparing the two hashes.

Also, this system could be built in the lobby, the lobby server can give a serverID to every server connecting.


P.S. A salt is not there for entropy. A salt is for preventing rainbow tables and such from working. Quoting Wikipedia:

The benefit provided by using a salted password is making a lookup table assisted dictionary attack against the stored values impractical, provided the salt is large enough. That is, an attacker would not be able to create a precomputed lookup table (i.e. a rainbow table) of hashed values (password + salt), because it would take too much space. A simple dictionary attack is still very possible, although much slower since it cannot be precomputed.

[MedO]

P.S. A salt is not there for entropy. A salt is for preventing rainbow tables and such from working.

Yes. By adding entropy. If the key has enough entropy on its own, you do not need a salt. In fact, a long key without salt is more secure than a salted, shorter key, since the shorter key can be bruteforced more easily.