Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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 1329 times)
0 Members and 1 Guest are viewing this topic.
Offline Jacob_

Junior Member


Projects: 3



« Posted 2010-05-19 17: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?
Online Riven
« League of Dukes »

JGO Overlord


Medals: 743
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2010-05-19 18: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".


Note:
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  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (26 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (20 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org 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‑gaming.org
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!