Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Verifying Logins  (Read 2004 times)
0 Members and 1 Guest are viewing this topic.
Offline Jacob_

Junior Devvie

Projects: 3

« Posted 2010-05-19 15:06:17 »

I'm trying to figure out how to prevent hacking/impersonation in Buildsim. There is a central user database, but servers are hosted by players. Currently, users login on the website and click a link to join a server, which creates a webstart file with the correct information filled in. The problem is that people can save the web start file locally and edit it--not good! I was orignally going to have the client send some kind of user-specific key to the game server--their password hash, or one generated by the website that is used only for multiplayer. But then I realized that a server admin could steal someone's key using wireshark and login as them anywhere they wanted.

I guess I need to make the key specific to each server somehow, but how? Using the server name or something as a salt would work, but eventually someone would crack it and leak the details of the hash on /b/. Any suggestions?
Offline Riven

« JGO Overlord »

Medals: 1357
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #1 - Posted 2010-05-19 16:06:06 »

You can do a hash handshake. The password will not be transfered.

Google "MD5 handshake" but apply it using another hash function (like SHA2)

You end up with a structure like:
Client -> User Hosted Game Server -> Secure Central User Database

1. "Client" wants to login
2. "Client" sends username, sends it to "User Hosted Game Server"
3. "User Hosted Game Server" sends it to "Secure Central User Database"
4. "Secure Central User Database" generates salt, calculates [hash of (salt+client.password)] , but sends [salt] to "User Hosted Game Server"
5. "User Hosted Game Server" sends hash to "Client"
6. "Client" knows own password (obviously) and calculates [hash of (salt+client.password)], and sends it to "User Hosted Game Server"
7. "User Hosted Game Server" sends it to "Secure Central User Database"
8. "Secure Central User Database" compares remembered [hash of (salt+client.password)] with answer from "Client"
9. "Secure Central User Database" sends SUCCESS/FAILURE to "User Hosted Game Server"
10. "User Hosted Game Server" now knows whether "Client" is authenticated, disconnects from "Secure Central User Database"
11. "User Hosted Game Server" sends SUCCESS/FAILURE to "Client"
12. "User Hosted Game Server" and "Client" do their magic.

This is basically a hash handshake with a proxy in between. The proxy becomes the server once the handshake is finished. Note that "Client" never connects to "Secure Central User Database".

The above communication suggests that "Secure Central User Database" has the 'client.password' stored in plaintext. This is inherently unsafe, so (once it works) you can replace 'client.password' with 'hash of (hardcoded salt + client.password)' on both sides of the handshake. Keep in mind that it doesn't matter that clients know the password-salt used on the server. This renders MD5/SHA lookup tables useless.

Note 2:
The "Client" must guard against the "User Hosted Game Server" sending a hash of "" (empty string). That way the "Client" would hash (password+"") and send that to "User Hosted Game Server", which can then lookup the hash in a lookup table. A better salt-hash-function than hash(salt+password) would be hash(hash(salt), hash(password)) anyway.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Pages: [1]
  ignore  |  Print  

hadezbladez (730 views)
2018-11-16 13:46:03

hadezbladez (366 views)
2018-11-16 13:41:33

hadezbladez (717 views)
2018-11-16 13:35:35

hadezbladez (183 views)
2018-11-16 13:32:03

EgonOlsen (2378 views)
2018-06-10 19:43:48

EgonOlsen (2532 views)
2018-06-10 19:43:44

EgonOlsen (1469 views)
2018-06-10 19:43:20

DesertCoockie (2134 views)
2018-05-13 18:23:11

nelsongames (1930 views)
2018-04-24 18:15:36

nelsongames (2612 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!