by date
Plan for Stefan Lundmark
Plan for Stefan Lundmark
| Name: | Stefan Lundmark | |
|---|---|---|
| Date Posted: | Jul 26, 2005 | |
| Rating: |  2.5 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Stefan Lundmark |
Blog post
Authentication for MMO games, AutoUpdater and general progress.
Sup guys.
Been working with my team again. Haven't been feeling very healthy (menthally) the last few months so work on games had to be put on the backburner. The last two weeks have been calm though, and I felt I could put some time on working with the team again.
Authentication for MMO games
One of the many things I haven't worked alot with was Authentication. So I had to start from somewhere. Taking a look at how different games do it and how it works in Torque was interesting, but didn't yield alot for me.
After alot of reading and fiddling around, I concluded that the best method to use would be a Challenge-based authentication scheme.
This is how it works in theory:
- When the account is created, the client sends a scrambled password to the server which is stored.
- When a client tries to log in, the server will send a challenge to the client which is different at each logon.
- This challenge is combined with the clientside password, and then hashed into a MD5 checksum.
- The checksum is sent to the server, and compared to the serverside hash that is calculated the same way.
- If both hashes are identical, proceed. If not, boot the client.
Pretty simple, yet effective enough for our needs. The problem here is database security, as the password is kept in a scrambled state. Given enough time, someone could figure out the scrambler and get the passwords in cleartext.
This is however, alot more secure than sending the cleartext password at each logon (as in a Secret Exchange Authentication scheme). I will most likely improve this in the future.
AutoUpdater
This was a pain for me to code, as it turned out to be more difficult than what I first imagined. I also learned alot. :)
Apparantly, the HTTP 1.0 protocol doesn't support Pipelining, and without that feature.. streaming of small files would be rather slow.
I solved it by rewriting much of the functions used by TCPObj, and it works really well.
This is how I done it:
- The server has a copy of the most recent client. Uncompressed.
- It runs a CRC-check on all the clientfiles, and returns an array to the client with CRC values as well as path/filename and size.
- The client then compares these values to the received ones, and if they differ.. they are added to a list.
- When the list is completed, the client starts to download the files.
What I wanted here, was to code an implementation that only downloaded the differing bytes instead of the whole file, and compressing these before sending. But that turned out to be more than I could chew. I'll probably go on and implement something like it after the current implementation is fully tested.
Other than that
The Project is starting to get moving again, and that makes me happy.
TSE is so much fun to muck around with, and it only gets better! I miss how you could modify each mission fast and on the fly in TGE, but hopefully something similiar to the old TGE terrain blender is on it's way in to Atlas, as that's my only gripe right now. It's incredibly time-consuming and hindering having to use a huge texture for each terrainblock.
I attended a big LAN here in Sweden recently called Dreamhack (~5000 people with computers, people from Intel/Nvidia/Dice etc) and showed off our Project a bit. We had alot of feedback and questions and most of the people were very impressed by TSE.. that was great.
That's all for me right now. See you later.
Recent Blog Posts
| List: | 07/03/07 - Improved Max2Dts Exporter 10/09/06 - Torque and modifications 08/14/06 - Thunderstorm, luck, and being alive. 07/26/05 - Plan for Stefan Lundmark 11/02/04 - Plan for Stefan Lundmark |
|---|
Submit your own resources!| Ben Garney (Jul 26, 2005 at 21:21 GMT) Resource Rating: 4 |
| Peter Dwyer (Jul 26, 2005 at 21:33 GMT) |
I'm not sure why people always feel the need to re-invent the wheel. 128 bit encryption is sufficient for most needs like this.
The patcher is nice however.
| Stefan Lundmark (Jul 26, 2005 at 21:47 GMT) |
I implemented it because I didn't see another way that was more simple.
Show me a resource where you can integrate 128 bit encryption easily enough, and I'll eat my hat.
| Gary Preston (Jul 26, 2005 at 23:53 GMT) |
You should store a one way hashed version of the users password in your db. Ideally you should first add a salt to the password to make dictionary based attacks harder. Your db would have username, clear text salt, hash of password+salt, with the salt should be randomly generated for each new user.
By doing this you firstly prevent any hope of working out the password from the hash due to the one way nature of the hashing algorithm. Since the next route would be to do a dictionary attack, you make the attackers life harder by requiring them to use a different salt for every user. This doesn't stop a dictionary attack, it just makes it more of a pain.
If you did mean scrambled = storing a hashed value, then ignore the above :)
When the client then connects the server sends it a challenge value which should again be randomly generated held temporarily. The client sends the username to the sever, the server then sends the client the users salt + the temporary salt. (this prevents someone intercepting the hashed password the client will be sending back and using it in a replay attack). The client then takes the users password, hashes it with the salt then hashes again with the temporary salt sending the result back to the server.
The server then compares this value to the hash of the stored hashed_password and the temporary salt. Whether they match or not you then throw away the temporary salt.
This method is not infalible, but it does prevent storage of the clear text password, it removes the need for transmitting the password at anytime in cleartext (as your method does) and it also guards against replay attacks should someone intercept your challenge-response traffic. Finally the original salt helps make a dictionary attack that little more troublesome/time consuming by ensuring even if two users have the same password, you won't know it.
An even safer option (but much more time consuming to implement) would be to ensure the client/server communication is encrypted using a standard protocol. Whether you want the overhead of this is up to you, but it would prevent even the salt and hashed(salt/password/temp salt) been captured.
Really the above is just another variation on what you described, but I thought it was worth adding :)
Edited on Jul 26, 2005 23:56 GMT
| Stefan Lundmark (Jul 27, 2005 at 01:03 GMT) |
The scrambler I use is definatly not a hash. You can always descramble scrambled text, while you cannot "dehash" a hash, right?
I'd definatly think about adding the salt method to the implementation. Not sure I understood it fully but I'll search on the net :)
Thanks alot.
| Peter Dwyer (Jul 27, 2005 at 09:52 GMT) |
Encryption isn't difficult and there are libraries out there that you can use free of charge to do this. It's simple enough to implement as it uses standard protocols. If you really can't find a way of doing this easily, then perhaps the link below will help
http://www.canadiancontent.net/en/jd/go?Url=http://www.eskimo.com/~weidai/cryptlib.html
This is a free C++ crypto library that should give you any one aof a dozen methods for encrypting data and comms.
| Stefan Lundmark (Jul 27, 2005 at 12:49 GMT) |
| Tom Vogt (Apr 12, 2006 at 13:49 GMT) |
| Stefan Lundmark (Jun 17, 2006 at 07:53 GMT) |
I'm not much into public-key authentication schemes. I have fiddled around with private key block-ciphers but that's about it :) I take it the former is alot more advanced?
| T Squared (Thanhda Tie) (Jun 19, 2006 at 04:01 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
