|
|
Posted by Richard Lynch on 04/12/05 01:37
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
Navigation:
[Reply to this message]
|