Password/Account Database

[manny2510]

Is your feature request related to a problem? Please describe.
I want to setup a maptools server that can be accesses 24/7 by a large group of people, but no so large that literally anyone with the server password can connect.

Describe the solution you'd like
If I could incorporate a password protected account based system any maptools user I've whitelisted or given a personal password to can connect and chat.

Describe alternatives you've considered
Currently RP is handled through discord channels, but those are rather limited in interaction. Being able to RP in maps the DMs make allows for social encounters to easily seamlessly change to combat encounters, as well as just generally enhancing immersion.

============
5/25/2021

• Each player that wants to connect to the maptools server should have their own unique username and password.
  • Reason being, if their password leaks we know whose password to change and who to question about it
  • Along with that, people with the same credentials shouldn’t be able to connect at the same time.
  • For example. Bob gets assigned the user name ‘Bob33’ and their password is ‘password1’. If he wants to change his password or user name he needs to contact a DM with access to the credentials.
• If a machine tries to unsuccessfully connect 6 times there should be a temp ban on them for 1 hour that a DM or anyone with control of the server can address and modify personally.
  • This should also be coupled with permanent bans
  • The file containing all the credentials and bans should be easy to share between DM’s so they can set up their own personal maptools servers which adhere to the same credential requirements.
  • A master credential file allows for people to be added/removed easily
• Public and Private keys are enough
• Give the ability to limit simultaneous connections.

Tasks

• Password File Authentication for Player Passwords #2906
• Add API for macros and UI to access "player account database" #2908
• Add reason message sent to kicked players. #2909
• Add ban users macro  #2910
• Add kick/ban reason to connections windo #2911
• Add macro support for player account database #2912
• Add player database management UI  #2913
• Add bulk import for player account database #2914
• Add public / private key support to player data #2915
• Add Playtime limits to password file #2918
• [Feature]: Add an easier way to manage public key connections. #3200

[Azhrei]

So how do you see this working?

It sounds like having MT generate a unique password on a per-player basis that can only be used one time. Otherwise, the password could leak and be used by someone else, possibly even at the same time that the authorized player is using it.

I suppose if MT was generating this itself, it could keep track of the proper password for each player, but we'd need a UI to allow the GM to enter the player name prior to the person actually logging in. And because they're single use, you'd want a new one given to the player as soon as they logged off (perhaps sent straight to their inbox).

How would you take care of users losing/forgetting their password? Should the passwords have expiry periods? Is this per-campaign or per-server? If a player is booted from the server (using the Connection panel), do they get a new password emailed to them?

(I'm curious about your use case as I'm wondering if it would fit well into an online game convention-style situation where players would be sent their passwords in advance.)

[manny2510]

I am not a programmer so I'm not sure if the following is feasible.

I'm helping with the Living world of Verum that uses maptools to play, we have 200 something players and I wanted a way to allow those players to be able to connect to a maptools server to facilitate RP outside of missions.

Currently each of those players will have patreon accounts associated with them except the DMs, so that's why I wanted something like an account list that would be verified to allow for connection.

As for how we could work in changing passwords? Maybe see if we could use some 2FA like google authenticator. If it does have to be a static password then I guess we could manually input randomized strings into a sheet with all existing accounts and just email them to the players.

[Azhrei]

Well, 200 players is about 20x what MapTool was designed for. Given that, I'm not hopeful that something like this will be implemented (it's a pretty niche request).

My first inclination is to recommend a reverse proxy with authentication. Such a proxy would sit in front of the MT server and clients would connect to it first, authenticate to it, and then have their connection forwarded to the MT server. This allows you to build whatever authentication you want into the proxy and to use its controls to limit the number of simultaneous connections. However, it gets tricky as most proxies are built for HTTP/S and MT doesn't use HTTP, so...

I suggest an SSH server instead. Players connect to the SSH server and authenticate to it using a per-player public/private key pair that you generate once and distribute to each of them. Once authenticated, a TCP tunnel is created so that the player can connect to localhost using port 51234. That local port is then forwarded to the remote SSH server where it connects to the MapTool server. I haven't done this for MapTool traffic, but I have done it for other applications. I'm not familiar enough with the Windows tools to know how to do this off the top of my head, but I know that the setup for Linux and macOS is only a few lines in a couple of configuration files. Adding a custom script that limits the number of simultaneous connections should be fairly easy. By using SSH, you eliminate the need for rotating passwords.

You will need a machine that can run an multiple instances of the SSH server and MapTool.

If you'll provide a specific list of requirements, I can see about putting together a proof of concept (if someone else doesn't beat me to it).

[manny2510]

The main thing would be that users with the same credentials as a connected user cannot connect, get the ability to prevent certain machines from connecting after x attempts, and having the credential data be easily edited so DM's can pass that around. Other than that I don't know anything else I'd need.

[Azhrei]

The main thing would be that users with the same credentials as a connected user cannot connect,

It should be pretty easy to prevent simultaneous connections from a single username.

But if people hand out their public/private key pair to other users, there wouldn't be any way to stop another user from connecting as them; ie, there would be no automatic 2FA built in unless you implement something like this approach.

get the ability to prevent certain machines from connecting after x attempts, and

I'm not sure what you're trying to do here as it wasn't part of your initial request and hasn't been previously mentioned. It sounds like you want clients that make multiple failed connection attempts to be blocked for... ever? For some period of time? Until the valid owner logs in? Until someone resets it?

having the credential data be easily edited so DM's can pass that around.

In terms of "easily edited", that would depend a lot on the platform. For example, on a Unix system, it would be pretty easy to provide a menu of usernames who have public/private keys already configured, and someone with proper authority could then remove them. Ditto for adding new users. But it would outside of MapTool, as SSH is a different tool.

Once a client has authenticated with SSH, all players would use the same player password to connect to the MapTool server.

It sounds like the requirements have not really been nailed down yet. You're welcome to DM me on Discord @Azhrei and we can discuss it there, then come back here with clarifications.

[manny2510]

I need the 4 digit # to contact you on discord, I'm gonna take some time to detail what exactly I need

[cwisniew]

Some sort of built in user management / per user password would also be handy for asynchronously run games as well (something more resembling to play by email) or even people just playing in pickup groups.

The problem is how to manage it in a way that also suits your more complicated use case @manny2510

But we should be able to achieve something in MapTool without the need to resort to setting up a proxy. I will have a think about what can be done.

[cwisniew]

@manny2510 prefer if you discuss here or in general-dev channel on discord as @Azhrei was more interested in outside MapTool solutions unless he wishes to commit adding this to the MapTool code.

[manny2510]

Okay, I'm just adding notes made during our discussion in here at their request. Right now they're trying to resolve it without using maptools.

[cwisniew]

Question for you @manny2510
You have a requirement to share credential files between DMs but also a master credential file. Or did I misunderstand that and you only need to redistribute the master credential file when it changes?

Maybe it would help if you describe how you would plan to store all these user names and passwords do that users can get to them so I can figure out a non painful easy to get this working

[manny2510]

Basically if a CSV file would work we could share one on google sheets and just pull from that each time a server needs to be setup/

…

On Wed, Jun 2, 2021 at 3:04 PM Craig Wisniewski ***@***.***> wrote: Question for you @manny2510 <https://github.com/manny2510> You have a requirement to share credential files between DMs but also a master credential file. Or did I misunderstand that and you only need to redistribute the master credential file when it changes? Maybe it would help if you describe how you would plan to store all these user names and passwords do that users can get to them so I can figure out a non painful easy to get this working — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2673 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASYOJ2G2AH2ULOUXKMHXHFTTQZ6DDANCNFSM45OM4IOQ> .

[Azhrei]

@manny2510 What is your time frame for needing something working?

[manny2510]

within 4 months, that gives us time to do any changes.

[cwisniew]

@manny2510 just an update on the status for the change too add this to MapTool

I have added the ability to specify / require per player passwords but I have not added the UI yet to update/change passwords (currently has to be done by editing a json file). I will get to the UI this week which will then mean the two hardest changes are done. That will leave play times, max players, auto disable of player with too many bad logins, and associated macros. So probably about 3 weeks in total (work permitting)...

Some additional questions that I have for you

1. For the code I have the import is done via json at the moment (simply because its in the same format as the password file so didnt take much effort), will that work or you still need CSV?

2. For the "allowed" play times... this one is a bit trickier (time zones) How you plan to have this working on your end, a sperate "password file" for each time zone and GM downloads correct one? or you need the ability to specify which time zone applies to the allowed play times in the password file, and then for MapTool server to do the time zone conversion

[manny2510]

1. The amount of data entry that can be avoided by being able to use a csv file will be well worth it considering the ‘allowed’ list of players will easily be 200+, though a Json file is great for now, as I believe csv usage should be possible in the future.
2. For allowed playtimes I think that may have been in reference to an allowed connection time before a player connection is booted to allow for new connections. Otherwise RP was generally at all hours on the old discord server. We do not need timezone based connection atm, sorry if some miscommunication on my part conveyed that.

[cwisniew]

2. For allowed playtimes I think that may have been in reference to an allowed connection time before a player connection is booted to allow for new connections. Otherwise RP was generally at all hours on the old discord server. We do not need timezone based connection atm, sorry if some miscommunication on my part conveyed that.

So this would be something like, player can connect for 1 hour then is booted and not able to connect for another hour, day, week? Hmm another question then, do GMs count against the max number of connections or should that be for players only, or does it apply to both and the password file needs another flag which says if a certain player/GM should be allowed to connect regardless of max connections being reached?

[manny2510]

For time, that would vary greatly from group to group, so having variable limits being attached to the roles of player or gm, or even go further and attach connection times to the individual username/passwords would be the go-to there.
As for connection priority, we could do a weighted system where if a user with high priority (number attached to credentials) tries to connect, a user with lower connection priority is booted.

[cwisniew]

Split up into several subtasks and submitted Pull Request with changes for #2906 (password file for per user passwords + authentication) and #2915 (public/private key authentication). Other changes to follow over the next few weeks