On Sun, April 10, 2005 7:48 pm, Adam Hubscher said: > In an attempt to provide the best way to limit the # of accounts per > person, I assumed that this could be accomplished by placing a dummy > value only used by the site itself that is the username/encoded password > for them on the community, and test if... when searched for in the > database, a result set of x is discovered, then they are unable to > create another account. What stops the Bad Guy from creating 47 different logins on the community site, each with X accounts on the game system? Nothing. GAME OVER Only forcing them to pay a deposit for an account on the game server will stop abuse. > However, the issue at hand here is, I'm not sure how secure it would be > if I were to say, create a secure login form, verify the data... and > then create another pseudo form that directs the person to the > local-based site using hidden post variables (this is my original > thought on the subject). Hidden POST variables are *NOT* secure at all. Totally useless. If you control both servers, you can securely transmit the data you need from one to the other using http://php.net/curl Given the amount of trouble an open forum can cause these days, I would say get a money deposit before you issue a game login, and then use cURL to get the user's info with a DIFFERENT username/password over to the community site. Use the different username/password because the forum code has already proven itself susceptible to a lot of security issues. Make sure you never refund a deposit to somebody who can still cause trouble -- IE, their login must be invalid before the deposit goes back. You *CAN* refund to those users who prove themselves trustworthy over time, on a selective basis. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
