This wiki is archived and useful information is being migrated to the main bzflag.org website

LocalAuthentication

From BZFlagWiki
Revision as of 08:24, 10 February 2013 by JeffM2501 (Talk | contribs) (Moved to idea since it's not something we really want to get into, but someone may want to do it as a plugin so keep the info for historical reasons)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Picture Frame.png This page contains a design document for an possible enhancement or feature. It is a work of collaborative design and has not been accepted as a development goal at this time. The final implmented feature if any may differ from the information on this page. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design.


Please note that this proposal has been rejected and is just here for historical reference. Global authentication is the only built in authentication system the project will support

A need exists to provide a local version of global authentication, with users, groups, and permissions.

Overview

The old local authentication system was not secure, it sent passwords in plain-text as chat messages. This meant that user passwords were stored on the sever in chat logs and easily accessible by anyone. Global Authentication does not send the password directly to a server, but a token. On isolated networks, global authentication is not a valid option.

Options

This is a list of authentication options.

Request Hash Method

One method is to have a server option (-localAuth) that can be added to the server config. This option is only valid when a server is not set as public. Upon connecting the server will send a password hash request to the client as a new message type. The client will then verify if the server is on the same subnet as itself, if so it will ask the user if they wish to send the password hash to the server, warning them of the issues. The client will then hash up the password ( from the password field ) using a different system then the global auth ( not MD5 ) and send the password as a new message.

The server will NOT log these messages by default and they will happen before the player joins the game. Questions to answer are:

  • Should it be limited to subnets?
  • Should there be a system to set "acceptable" lan servers to trust?
  • Should there be an option to enter a password just for that one server and the client cache them?

Legacy As A Plug-In Method

Another option is to implement the old passDB as a plug-in using a custom slash command. It has the same issues as the old system but becomes more opt in. It can be called "LocalAuth" and even do auto auth based on hostmask/IP if we want to auto op owners. It's simple but does not solve any of the issues with plain-text passwords. This may be enough if everyone is just going to move to global anyway.

Questions

  • Is this even needed? can LAN users use /password to admin a server? do they really need per user perms?
  • Can this be done any way else?
  • Can/should we make a little list server that the server can point to, to generate tokens, then ask the players if they trust that server? ( doesn't seem different then trusting the game server really )