Authentication hooks (wishlist)

[virusman]

I think we should discuss this when and if the Master Server will be taken down. A viable solution with infrastructure can be set up in less than a month, and if EA/Bioware is going to make that decision, I think we'll have enough time to develop this solution.

[Asparius]

With all due respect - I disagree.

Master Server is down quite often and when it is down, practically nothing prevents people from getting onto others people accounts (unless login during master server down is disallowed - in this case nobody can login and server is empty).
An open door for malicious people.

I had other solutions (typing a password on client enter for players (using SetCommandable to disable actions) , for DMs- special items in inventory), but those protections are still very weak.

[PlasmaJohn]

[PlasmaJohn]

continuation...

I do see the need for PW's to be able to perform their own player authentications via overriding the single server password with a player specific one.

I just don't see the need for a centralized alternate MS specifically when I'd much prefer to build and maintain an infrastructure independent of any such 3rd party. If anybody can offer a reason why the alternate is necessary to me then I'm willing to reconsider. The arguments must be backed by fact and detail. Specifically telling me that it covers an exploit without explaining that exploit is not good enough.

The only value I see added by the Master Server is that the keys used are recognized by Bioware as paid for (in theory). Eventually (in my experience) it gets too expensive for those inclined to misbehave to acquire a new set of keys.

There's a lot that I despise about the MS: Obviously the outages, but also the Big Brother aspect. I tolerate those because the stick associated with the keys is the best tool I have. It isn't the only tool however, so if that tool becomes worthless, then I don't give a flying fig about key validity.

Please do not make hook development depend on the existence of an alternative central MS (or at least its design). You're just blocking me for no real benefit.

[Zebranky]

I should have asked "Is there a replacement master server at all?" as the first question. You're right, a per-player server password would solve that for most purposes (apart from a slight delay while the client and server each try to contact the MS and time out). I had forgotten where we were originally going with this thread.

What kind of interface would you want from the hooks? Launch a script and expose NWNX methods to get player name, check password against hash provided, and accept or reject the credentials?
_________________
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]

We got rid of master server authentication months ago and implemented our own protection with scripts. I didn't hear about any abuse so far and we're having quite a few players.

[maddogfargo]

My question then...without going into details about the aforementioned vulnerabilities...what is a recommended best practice for capturing & validating authentication information?

With a database it's easy enough to track if a particular account and key combination has ever logged into your server before. With a sim-tools like tool and setting non-commandable you could capture a password for setting and authentication. Or maybe you could use the journal notes to type in a password which would then be deleted from the journal post authentication?

Has anyone posted a good system to do this on the vault? Or perhaps it is already included with an existing system and I'm overlooking that?
_________________
* illegible scribble *

[FunkySwerve]

As discussed earlier in this thread, cd keys are better than nothing but not infallible. You want a system that prompts the user to pick a password on enter, and asks for it before it allows them to do anything. We do this, though the passwords are optional for non-dms. They're stored in encrypted form in our database, thanks to code by acaos. Here's a chunk of code from our cliententer, though it's obviously far from complete:

[maddogfargo]

Thanks Funky, that does give me some good ideas.

I'm curious, what is the purpose behind looking at the IP in the beginning? I can think of several possibilities, and was just wondering.
_________________
* illegible scribble *

[PlasmaJohn]

[PlasmaJohn]

*bump* 'cause the MS flaked out again

[drake127]

I created replacement for master server but it is not ready for public release yet (and certainly won't be for few weeks) and it for the time being it heavily relies on iptables. I am also concerned about licensing issues so there may not be public release at all. So this post is just to say that this topic is not dead.

[Sethan]

[drake127]

Well, I managed to take a time and pack source together. It still needs some work but I like the way it is going.

Look at https://redmine.drake127.net/, not much there as I am still testing project environment but could be nice preview for those interested.

Basically, it is complete implementation of a master auth server with currently only basic functionality (always authenticate, always reject, use BioWare server) but I plan to use SQL to work with custom authentications tables (given you know private CD keys and/or player password). The ultimate goal is to provide application that can work on localhost and suits admin's needs or in nested chain with other master servers (including BioWare's).

I would probably like to hear some opinions on topic, particulary whether is it appropriate not to consider CD key authentication results and whether to release information how to fix an authentication exploit (and therefore disclose details of such exploit).

[PlasmaJohn]

CD key verification is pretty much useless.