Authentication hooks (wishlist)

[FunkySwerve]

[Disco]

I am going for another, not very safe but enough for me, approach. I got a few premises:

1. Arses are not gonna spend a long time behaving well just to be able to get into somebody else's characters. 99% of them logs in with a character names "DM's Suk" and get banned before you can say 'tard'.
2. I want as little bother for the players as possible.
3. I already place a key item on each character as a way to make them truly unique (mainly use that for quest tracking). This contains the CDKEY the character was made with (not as a local var, so it's rather safe).
4. I already track each level a PC gains, including account and cdkey at that moment.

So, I first made a list of any cdkey/account combinations that have at least one level 5 character, and I also started adding new entries to that list whenever a PC reaches level 6. That takes about 3-4 hours of dedicated XP gaining if you know the server.

Whenever a PC logs in I first check if the player CDKEY matches the key on the character. If not I check my list to see if this is a known account/cdkey combi. If not I boot the player.

There's two way to activate this character with a new cdkey. You make a new one on this account and reach level 6, or you ask a DM to do it on the webpage.

This, in combination with the records we keep in the database and a daily backup system seems enoug protection for me. When poo hits the fan we can always go to fully password protected.

[Gryphyn]

I'm using a similar system to Disco.
I ignore the cdkey - as this only validates the copy of the client software/install not the player, or their characters.
Mine is an encrypted passport system, with a 1xp write-back.

The premise is that any new character will have 0xp. So there is a primary check for this. Then there is some validation for point-buy, starting items etc. If these pass 1xp is given to the PC AND it is immediately saved to the server vault with an encrypted key attached. (this will validate against a value in a passport item - or in your database)

Any character returning has more than 1 xp.
Only those PC's that are validated by the encrypted key are allowed to return. (those that come from your-own server vault)

At various stages (eg OnRest, OnLevelUp) a new encryption key is generated and written-back to the server vault.
A hacked bic is useless, as some of the PC's attributes are used to generate the key. (and I'm not telling which ones, or how many )

It's quick and it doesn't bother the players - they don't even know it's there for the most part. (we don't see the ones who ask about it anymore...)

Cheers
Gryphyn

[Disco]

How does that stop from me getting into one of your players' accounts and harrass other players in their name? I think that's the issue we're dealing with here.

[Gryphyn]

OK, my post is a little off-topic then.

If it's identity theft you're guarding against, or preventing. You can only do this via an in-game authentication system.
The Player would need to enter a password to enter the game proper. A password they chose when joining the server or possibly a password they used when joining your website.
But it won't be achieved without some user interaction, were the 'real' player has to confirm who they are.
If a player gives up this info, you're back to square one again...

[FunkySwerve]

[acaos]

Actually, his method will work to validate a legal character (assuming he's following good security practices with his signing).

I did write an engine hack which lets us easily distinguish new characters from old with 100% accuracy, but a large impetus for this was so we didn't need to edit existing characters in our vault to add validation keys.

There is also a second component to the fix which prevents a method of crashing the server, which is why I have not yet released this publicly.

Unfortunately, I discovered the crash after 1.69 came out. Although I did forward it to Bioware, I don't think they will be fixing it. And it allows any malicious client to crash any server (Windows or Linux) with no defense unless they are running the fix.

Acaos

[FunkySwerve]

Let me rephrase that: if you are relying solely on xp to determine whether or not a character is new, you're subject to being deceived, since the player can simply upload a character that's been given xp in place of the new character made during creation. From rereading your post, though, it looks like you are not simply relying on xp, since you check authentication. I'm forced to wonder why you check xp at all, however, if that's the case, instead of just checking to see if there's an authentication key, before checking its validity, which would be a more direct check.

Funky

[Gryphyn]

The 0xp check is solely there for new characters.
When a character is created there is nothing to authenticate (and if you find it you know the BIC has been hacked)

And as I'm writing back the new character with 1xp - this, and any returning character, should have a valid authentication. (without validation it's not one of your server vault characters) [@Funky - I'm actually more concerned with characters with 1 or more xp]

Now if a hacked BIC was uploaded to your server vault, they would also need to hack the validation data. Now this data has been generated using a Key, known only to your server scripts, so trying to reverse engineer a cypher (without the hint of a key)... good luck.

It's just added more than exponential difficulty in hacking a BIC - they'll hit other easier servers (sorry guys )

The major benefit here is that the honest players (the vast majority) don't even know that this is all happening, they don't get dialogs "Please tell me this is you" to interrupt their game play.

Cheers
Gryphyn

[FunkySwerve]

An addendum - acaos informs me you CANNOT up characters with xp as new characters. I'd been told you could, but have never tested it, so that may we be a viable test.

Funky

[Jambo]

Not really wanting to bring this one up again, but seeing the master server continuing to be it's on-going flaky self... in the end, was anyone willing to

1) hook the "alternative authentication" method NWN provides to instead fire a NWScript to handle things, as opposed to writing things to ini files?

2) Hook the server password entry box, also to call a NWScript and pass relevant details.


Again, I realize all the arguments for looking at alternatives especially due to Bioware's authentication methods even being exploitable it seems - but it's nice to have many angles where possible.

Being able to do #2 would provide a nicely passworded interface for servers, and unique passwords per user are undoubtedly the best security you can get.

[Zebranky]

It's been on my list for a while, but it's quite a project, since it would also involve setting up the infrastructure to act as your own authentication server.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/

<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.

<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for?

[Disco]

I activated the system mentioned above last week, after collecting level 10+ character/account/cdkey combinations for a month. It took a few days of fixing fresh people, but now everything seems to work just fine.

[PlasmaJohn]

[Zebranky]

You're just saying this because all of BioWare's systems were down last night.

Point taken. There are still difficult decisions to be made about how the infrastructure is implemented. Where and how is the community master server database stored? Is it monolithic or does each server/server group have to run their own? How do new users get added to it? How does it handle CD key validation? And so on...

Not insurmountable by any means, but they're things that should be addressed before tackling implementation.
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/

<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.

<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for?