Salted Password Implementation

  1. Player starts Launcher.exe and fills out info then hits play
  2. Launcher.exe connects to listserver and requests a salt, hashes the password then inserts it to the client and clicks start
  3. When the client connects to the listserver the listserver will store the players IP thereby locking the password to it
  4. When a player connects to a server the server asks the listserver “Is this player IP the same as the one you have stored?”, if the listserver says no then it will reject the player

Thereby anyone who sniffs the password will get the salted + hashed password and will be unable to use it due to IP locking and the next time that player logs on the password will be completely different.

Possible Issues & Solutions:
* Issue: Players will be unable to logon to the server without the use of the launcher
Possible Solution 1: Allow legacy (unencrypted) connections for a changeover period and tell people to get the new launcher
Possible Solution 2: Use the listserver welcome message to announce that you require to use the launcher and have the “Show More” and “Donation” links goto the launcher EXE

Can’t think of any other issues

WoW… thats an awsome idea, and i find solution 2 sounds better.

also cant think of other issue ATM but who knows what everyone else will come up with.

Yo,

Do u need any help with the launcher?

I could bang one pretty quick in borland c builder 6 (or any other). My Windows Sockets are a bit rusty but as long as I remember WSAStartup then it should be all good :slight_smile:

I think I still even have the handle information from my other launcher.

Why exactly does the client now need this. or is this just for added security?

In the main loop, where i normally shove a sleep() call, perhaps I could do one to check if the certain launcher process is open… if not, terminate the app. Dunno though, depends if I can define a check process type thing.

[QUOTE=kpedersen;5868]Why exactly does the client now need this. or is this just for added security?[/QUOTE]
Just for added security, prevents rogue server operators from logging your password in a usable state.

[QUOTE=kpedersen;5868]In the main loop, where i normally shove a sleep() call, perhaps I could do one to check if the certain launcher process is open… if not, terminate the app.[/QUOTE]
Don’t see why you’d need that

“Don’t see why you’d need that” - Agret 2008

It would mean that the client will only run if the launcher is running.

Because this security solution is actually for the clients protection, then it doesnt matter lol

Is that not the point of your list server though? Surely u can hash it with the list server and only send the hash to the potential rogue gserver and then communicate with it using only the hash.

Ah ok, I am quite poor at explaining myself (evidently)

Basically…

  1. the client connects with your list server…

  2. The listserver compares the password given with the hash of it in the database and then accepts or declines accordingly.

  3. The list server only gives a gserver the hash rather than the password and this is used instead.

Ultimately, the list server turns the password that the client gave into a hash and deals only with that from then on.

The client sends it to the gserver too? damn.

Yeah ok, the launcher solution seems the best so then it can authenticate the hash with the hash on listserver (with added salt)

I think I am following you.

It should be possible to not even need the launcher.exe to type in the details and display serverlist.
Perhaps the launcher.exe can run hidden and change the text to the hash with SendMessageEx() as soon as user clicks connect. Perhaps even make an extra 2 dummy textfields and hide the real ones, and keep inputting the hash into the real ones when ever the user types a letter (detected by the launcher) into the dummy ones. Then simply embed the graal.exe into the launcher.exe using molebox and I think its done.

Oooh, we could also have a notification icon like v5 lol

Just some ideas.

just had an idea from reading your post kpedersen.
As i understand it so far the launcher.exe needs to keep running in the background while your playing graal (i may be wrong im not that technical), well as you have that program open already you could add a chat function in to it for ALL the players to chat ACROSS WORLDS.
This could help get groups of players on multiple worlds to pick a world to play on and help solve part of our empty worlds problem.

just an idea i dont even know if you could do it or if there is a better way to do it.

Yeah that seems quite feasible.

you could also have the chat app add the text to the graal client and hide the original chatbox at the bottom so it looks better.

yea, thats a good point didnt think of that. :smiley:

Hmm… Sounds good.

When everyone decides what we are going to do with the launcher… I’ll be happy to quckly knock up that external ingame chat app.

I could make fun of everyone online :]