Securing Your Server Without Master Server Authentication

[Legacy_Lightfoot8]

               

wyldhunt1 wrote...

NBDE doesn't work on Linux?
'Tis a wall I was unaware of... Although in this case, it may just be because I default to assuming that 'software' does not work on Linux... '>

I do not know if the bug was ever fixed or not.  In the linux version of the NW DB the Delete Campaing DB function did not work,  Therefor NDBE ended up compounding the problem that it was trying to fix, as far as the linux  client went.   

Im with funky,  It is funny that someone who says that the NW DB is 100% fail is suggesting a NW DB solution to the problem.     
               
               

               
            

[Legacy_WhiZard]

               Let's tie the discussion together.  As bolded below, Ultima maintained a lack of trust in first come is owner security interpretation.

ultima03 wrote...
Anyone can enter any account without knowing the password. Period. Now I can go and make a lot of companies laugh about this joke. If MSA has any security breach, bioware/atari must secure it as a priority or cut the entire traffic. And when the MSA falls like time to time before, after the timeout it shouldnt  grant access to servers like it always did. Now you say that checking Account/Keys and password matching require client patch? And yes pretending that the first to enter an account is the legitimate owner as the workaround of that funky guy declare is completly wrong.

Balduvard replied that this would only happen if the account owner had never logged in to the server.  Thus being a case of foreknowledge on behalf of the account stealer to know which server the account holder has not been to and will likely go to.

Balduvard wrote...
Oh, but wait, our player account protection does not actually end with the password. In order for such an attack to be successful, wherein the offender manages to log into a server before the proper owner of the account does, or tries to log into the server after the account owner has failed to set a password, they would have to possess the exact CD Key of the account owner. Why? Because in addition to offering password protection, each account is tied to a single CD Key (reference Funky's provided scripts) unless otherwise authorized (which the real account owner will immediately discover on their first login to the server, permitting a red flag to be brought to the attention of server admins to handle the offending CD/IP).

After his/her distaste of Funky's approach Ultima then wished to replicate the process only adding in NDBE and unlimited account keys.

ultima03 wrote...
I will provide a MSA Workaround of my own. It will use the same principles as the funkySwerve's system but will allow unlimited CD-KEY storage, I dont quite understand why he limited it to 7 especially for the mysql version, also will protect the user against some problems that I explain in the description. Database will be NBDE, wich is perfect and I also use a tokenizer (yes both systems are from Knat, so what, he's the best) wich mimics useful function that can be found in other powerful langages not available in aurora, like arrays (set, get, push, count, explode).

However keeping the first to come is account holder interpretation, the NBDE usage is susceptible to data loss from server crashes (while the given database solution is not).  This extends the possibility of impersonation (of any newcomers) to more than just foreknowledge, as the data from their initial login can be erased.  Thus Ultima's fix does an even worse security job in regards to one of the "security problems" he/she had already indicated.  Besides that, there doesn't seem to be any significant difference between the solution Ultima proposed and the standard database solution already posted.
               
               

               
            

[Legacy_ultima03]

               The MSA being down means that anyone can enter any account on any server.
The MSA workaround is an internal registration system, wich means your
account and your name can still be used on any other server.
No single developper have the obligation to be aware that this workaround even exist.
This workaround is based on a declaration wich states that 'the first one to
enter is the owner',  this is the principle for any new
game/website/platform launching when the database is empty, this is not
the case for a 9+ years old game. I remain against workarounds, and
everyone should be.

It's just that general flaws that shouldnt be provided.

account name can consist of 35 characters, the limitation of variables name is 32. Its already a problem.
example in : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
Now
if someone wants change your code for any purpose at their discretion,
and to concatenate accname to something else it will easily exceed 32
chars with even shorter accnames.

Simple test :
Create a player account of 35 characters
ie : "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Now store 7 keys like you do under that account name :
ie : string sKeys="88888888|BBBBBBBB|AAAAAAAA|QQQQQQQQ|ZZZZZZZZ|VVVVVVVV|XXXXXXXX";
SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);

Now retrieve it with GetCampaignString("PlayernameKey", GetPCPlayerName(oPC));

And you get nothing but an empty string.


For
any future implementation or tweak by end-user, they shouldn't be
worried about problems with 32chars limitation and be free to
concatenate all they want for any purpose. Now even GetName(oPC) +
GetPCPlayerName(oPC) or public key variants is dangerous.

Maybe
disallow accounts with 32+ chars to even enter your server? That won't
solve the general problem vars which accept concatenations, various
object tags, resrefs, etc .

Now you store Keys under the account of the user without specifying it t to hold keys and nothing else.
ie : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
instead of somthing like : SetCampaignString("PlayernameKey", "KEYS"+GetPCPlayerName(oPC), sKeys);

Now if the end-user has already a system that store data on GetPCPlayerName(oPC), may it be a string, a float or anything at his discretion, it will simply be overitten. The varName must be unique throughout the entire database.

Let's say you store the string sKeys under sAccount, but the end-user also use to track the number of loggin under the very same sAccount variable name (wich is not string, but an int) : it will simply be overwitten and you will get unintented results.

Limited to 7 keys. Why not 4,2 keys?
What do you know about general needs of others server that you offer a
system, servers with heavy faction system hold easily dozen of keys per
public accounts.

There is one thing that I recognize atleast is
that you do not offer an NPC or a vocal command to allow new keys, that
would be a security breach. But you should also imply loudly that none
should use anything in their own implementation of your workaround but
activate an item with a unique power.

Also I'm still concerned about security with this system, because any log-out by any player can be done for and suspected to be to add a new key. So anyone can test the one who left and his account

Server crash? Not only data you will loose but also items, levels, experience etc.
Linux and Windows user should both use nwnx-mysql.
Windows and NBDE works without single problem and is easier to implement.
NBDE with Linux has an explicit functionnality problem, everyone knows it.
               
               

               

                     Modifié par ultima03, 27 janvier 2012 - 06:54 .
                     
                  

            

[Legacy_Lightfoot8]

               Ok, Lets see, Let me take this one piece at a time.  

ultima03 wrote...

This workaround is based on a declaration wich states that 'the first one to
enter is the owner', this is the principle for any new
game/website/platform launching when the database is empty, this is not
the case for a 9+ years old game....

Any server that has been around for 9+ years should have a backlog of server logs that contain the Public CD-Keys that have been used for any given account.  A server admin who has been around for 9+ years should have no problem prpouplating there DB with valid CD-Kyey that have been used when the MSA was still up. If the server Admin has deleted there server logs,  Well that was just a poor judgment call.

I remain against workarounds, and
everyone should be.
It's just that general flaws that shouldnt be provided.

Well I guess you are intitled to the opinion.  And us giving you the reasons what the MSA was never a good security system to begin with is is not going to change you mind now if it did'nt before

account name can consist of 35 characters, the limitation of variables name is 32. Its already a problem....

Well  you are a bit off on how long the account names can be.  I think SkyWing recently stated the the limit for the protocall is 80 characters.   I have made them up to 70 characters long just for testing. Cancatenating the names to 32 characters will work just fine.  Agreed an oversite by funky, most likely due to the fact that he has not used the NW DB in years.  with the names concatenated to 32 characters,  It will just mean that all accounts will have to have the first 32 characters unique.

Now
if someone wants change your code for any purpose at their discretion,
and to concatenate accname to something else it will easily exceed 32
chars with even shorter accnames.

True, But why would they want to do that.  I see no need, For any reason.

For
any future implementation or tweak by end-user, they shouldn't be
worried about problems with 32chars limitation and be free to
concatenate all they want for any purpose. Now even GetName(oPC) +
GetPCPlayerName(oPC) or public key variants is dangerous.

Again,  What is the point of adding to the var name.  It pertains to one account, Not to one player in the account.

Maybe
disallow accounts with 32+ chars to even enter your server? That won't
solve the general problem vars which accept concatenations, various
object tags, resrefs, etc .

Now you store Keys under the account of the user without specifying it t to hold keys and nothing else.
ie : SetCampaignString("PlayernameKey", GetPCPlayerName(oPC), sKeys);
instead of somthing like : SetCampaignString("PlayernameKey", "KEYS"+GetPCPlayerName(oPC), sKeys);

Now if the end-user has already a system that store data on GetPCPlayerName(oPC), may it be a string, a float or anything at his discretion, it will simply be overitten. The varName must be unique throughout the entire database.

That would not happen, Unless of cource the end-user just happened to already be using a DB with the name
PlayernameKey" as there DB. Of was folish enough to change the name of this DB to the one they are alrady using to store other stuff.  They should leave this DB for storing CD-Keys and nothing else.  all the problems you just named just went away.   Or do you think a module is restricted to having just one DB that it can access?  

Let's say you store the string sKeys under sAccount, but the end-user also use to track the number of loggin under the very same sAccount variable name (wich is not string, but an int) : it will simply be overwitten and you will get unintented results.

It should not be placed into this DB.  Use another DB name of storing that information, If not you are just asking for trouble.  

Limited to 7 keys. Why not 4,2 keys?
What do you know about general needs of others server that you offer a
system, servers with heavy faction system hold easily dozen of keys per
public accounts.

I guess if you do not know the general needs of other you should just not try and help anyone. If not someone will come along and start saying that your scripting is not worth a dam because you only solved the problems of 99% of the people.   The other 1% just want to gripe instead of asking for help, I guess.  

There is one thing that I recognize atleast is
that you do not offer an NPC or a vocal command to allow new keys, that
would be a security breach. But you should also imply loudly that none
should use anything in their own implementation of your workaround but
activate an item with a unique power.

  I do not see how funky can be held accountable for any modifications any decides to make to it.   I also Do not see your security breach from spoken commands.   The PlayerChat commands are easily removed for any prying ears, As long as you know what you are doing.  Anyone writing such a script should know enough to take the need procations.  It is there responcibility to know what they are doing if they make modifications.    

Also I'm still concerned about security with this system, because any log-out by any player can be done for and suspected to be to add a new key. So anyone can test the one who left and his account

And the player will know it and be able to report it.

Server crash? Not only data you will loose but also items, levels, experience etc.

 
Umm You lost me, What does this have to do with anything?

Linux and Windows user should both use nwnx-mysql.

Every one has a right to chose based on there own reasons.

Windows and NBDE works without single problem and is easier to implement.
NBDE with Linux has an explicit functionnality problem, everyone knows it.

There is realy no differance.  NBDE is just a wraper of the NWN DB to allow a few extras at the cost of a few things.

You have made one one valid point and that was the limit of 32 character for the NW BD,  It is simple enough to just trim the account name to 32 characters,  The problem is solved right there.    Even if some one tries to create an account with 32 characters that are the same as someone elses, He will fail the validation and be required to create a new account.   If such accounts already exsist on the server, unlikely but I guess it could happen,   The server admin should have no prpblem moving the players to there new account.
               
               

               

                     Modifié par Lightfoot8, 27 janvier 2012 - 11:10 .
                     
                  

            

[Legacy_FunkySwerve]

               Actually, the 32 char limit isn't a problem, as lightfoot points out - the person would be blocked. We have a grand total of 487 of those 26k playernames that exceed 32 chars, and have NEVER had a complaint about an accidental overlap. And, of course, if an overlap wasn't accidental, it would be blocked, as lightfoot notes.

Likewise, the assumption about the legitimate account holder being the first to log in has also NEVER failed, as has already been noted in the thread.

What ultima simply doesn't grasp is something that is obvious to experienced coders. ANY good code is a series of compromises. You COULD choose to maximize your code's speed, for example, but to do so you would have to make extreme sacrifices in readability and modularity. The best code is, generally speaking, that which looks at the costs associated and balances them to maximize benefit vs cost. The concept is related to that of diminishing marginal returns, or, more colloquially, 'too many cooks in the kitchen'. See, e.g.,
http://en.wikipedia....nishing_returns

That principle is why it is so monumentally stupid to insist that people shouldn't use code simply because it has hypothetical shortcomings which almost never obtain in practice, and which are low-cost to fix should they actually come to pass. No one with any reasonable amount of coding experience would make this kind of claim...as has been made abundantly clear by all the experienced coders posting above. '>

And to those coders...thank you for your time spent debunking - I can ill-afford the time to do it myself if I can help it. '>

Funky
               
               

               
            

[Legacy_Irisiri]

               How to prevent players from camping inside another player's vault?
               
               

               
            

[Legacy_FunkySwerve]

               Long story short, you don't, not in vanilla nwn. It's likely possible to develop a plugin to prevent this, but we haven't had to, since it only blocks login on the same server, and we have 12 up and running at any given time. This has never happened on HG, to my knowledge - at a minimum, it's never been reported. Are you currently having this issue?

Funky
               
               

               
            

[Legacy_jess_amour]

               Can you please explain how to set up the item conversation fired when they log into the docks? i cannot quite understand how it would automatically fire up if it is an inventory item. Thankyou '>
               
               

               
            

[Legacy_FunkySwerve]

               I answered this in a pm - please let me know if you have followup questions.

Funky
               
               

               
            

[Legacy_Khuzadrepa]

               This is FANTASTIC code!  Thank you so much for all you give to the community, Funky!! '>
               
               

               
            

[Legacy_Greyfort]

               All I can say is great Job Funky.  

You have always been generous and helpful to nwndb, nwnx, windows,linux users.  For that I thank you.  Also I have visited your server and enjoyed very much.

As a programmer I have tried to offer solutions to the community for all data base systems, knowing that all of us are at different levels of programming skills.  I am curious to see any code one of us comes up with, giving us greater resources to insure security and expand our ability to keep this great game going.  

All of you keep up the great work, thank you for sharing that's what will keep this community and game going.
               
               

               
            

[Legacy_jess_amour]

               

FunkySwerve wrote...

I answered this in a pm - please let me know if you have followup questions.

Funky

Thankyou Funky. I haven't attempted to add it in yet as i have to add it to an allready exisiting script but i shall most certainly ask if i have problems. '>
               
               

               
            

[Legacy_HUNTER_of_Wisdom]

               This is wonderful.
But I would like a set of SCRIPTS to link the players' login passwords, does anyone could help me?

I thought about creating a table on my website, called LOGIN, that stores information through the previous registration, and at some point the script made ​​the connection with this table and check whether the password is actually the real ... this would be possible, could someone help me?

(The table is in MySQL, i have de script conection in PHP)

Thanks ...
               
               

               

                     Modifié par HUNTER_of_Wisdom, 20 mai 2012 - 09:31 .
                     
                  

            

[Legacy_Sir Elric]

               I’ve been out of the NWN scene for awhile now but still run a 24/7 PW and this issue was only brought to my attention recently by a player.

Firstly, thanks for the code Funky saves me messing about scripting something. I implemented the native Bioware database version you posted and gave it a quick test and it seemed to be working fine. There is however a simple way round it, which luckily we stumbled across when I asked player to test it and he managed to still log in on my account with the scripts in place. It’s a simple tweak to the existing code to fix it. I have PM’d PM Funky with my findings and leave it to him to change the code if he agrees with what I found. This effects the Bioware database version and possibly the MySQL version too.
               
               

               

                     Modifié par Sir Elric, 08 juin 2012 - 01:59 .
                     
                  

            

[Legacy_4BOLTMAIN]

               Im not sure if this has been though of before but...

Is it possible to prevent the module from displaying a players account name... like when you click their avatar to whisper them?

I took my mod offline when the master server went down but would like to bring it back up again.

Hiding a players account name would be very helpful.

Thank You FunkySwerve and Sir Elric for helping me out back in the day on the old forums : )
               
               

               

                     Modifié par 4BOLTMAIN, 04 juillet 2012 - 09:31 .