How to handle multiple UIDs per Discord user

[sjstein]

Given the way R8 assigns / calculates UID, it is apparent that depending on things, a specific user may have a few different UIDs. How can we handle this atm?

[sjstein]

the SID is a unique key - originally intended as a 1:1 per user, however why not have an admin command /add_alt @discord_name which will add another sid entry for a given discord name. Since the creation of the hostsecurity file is based on the SID, this would potentially add another entry with the new password (created due to the /add_alt command)

This affects how/show_password operates for those users with more than one UID

[sjstein]

and how does this work with bans

[sjstein]

Perhaps adjusting the db access to keying off of the discord ID instead of the SID will make this easier and also facilitate #89. Instead of the abstracted get_element for returning the SID for a given column val, just iterate over the database structure for each instance of a the relevant discord id.

[sjstein]

-and/or- add a get_num_elements(key, search_col: str, ldb: list) method which returns the number of rows which contain the key in the search_col

[sjstein]

More thought put into this. Given the backwards way I have to correlate a user with a password, I think it best to wait until the next release drops of Run 8 and see if the devs decide to keep the NAME field in the HostSecurity file. If so, it will be MUCH easier to handle multiple UIDs for a single discord user.

[sjstein]

So latest update didn't fix or change anything with the HostSecurity file.

Here is my current thinking on how to handle multiple UIDs

Every time the merge back from the hostsecurity to the database happens, if a diferent UID is found, rather than just nuke it, append with a special character delimiter (similar to how notes are appended). Then when writing the hostsecurity file, if more than one UID is found for a given record, just create two instances of that user's password- tied to each individual UID.

[sjstein]

I don't think this is possible without having a separate user for each UID - which is lunacy. Tried to incorporate a clever feature in branch #94 but won't work due to the way Run8 steps through the hostsecurity file.

Description of what I found - pasted from Discord rant I went off on: Anyway - the TL;DR: You cannot have multiple UIDs tied to the same password. Hard stop. I had modified the bot to add multiple entries to the hostsecurity file for a given user if they requested a refreshed password and already has an existing UID I appended a list of UID within the UID field of the db - so it didn't break the current schema and rewrote some the engine to parse that, create the new xml, etc. works great - after a few hiccups but fundamentally what is happening (at least, this is my observation) is that when a user initiates a login attempt the server walks through the HostSecurity file - top to bottom if it sees a password match, it then checks the UID

[sjstein]

Had an interesting conversation with @jackfruh this afternoon - and he posed a question I had thought about a while ago but dismissed. What if we just blow away the UID field every time Run8 populates it? This way the password will be ready to be used by whatever UID is presented with it.

From a security standpoint this is nauseating as anyone who happens to have a user's password can grab it and use it.

However that chance is pretty low, and as Jack pointed out - the risk really isn't that high. This is a train game after all.

[sjstein]

The ban user function will still work since that routine automatically changes the users password when the ban hammer hits.

[jackfruh]

I agree, Just put some disclaimer in the code: "Not for Export" "Not authorized for use in any centrifuge monitoring applications."

[sjstein]

question: when should the hostsecurity file be rewritten?

Every time it changes? (Run8 re-writes every time a user logs in - and adds that UID field)

That seems easy - but will indeed allow multiple people to share a password then.

Ideally (heh - "Ideally" this convoluted stuff wouldn't be necessary) we would update/delete the UID for the user that just logged out; priming it for their next login

This would require monitoring the log file and scraping through the events to do so

Which isn't impossible (nor really that hard), but I was really hoping to not have to worry about yet another Run8 schema changing

[jackfruh]

This raises a question: If passwords can be shared and anyone can use a password if they have it, Do we have logs as to which user was assigned which password and when?

Thinking about scenarios where there's some server abuse, ultimately we want to tie the actions we see in the Run8 log to the user who "owned" the password.

For example: "Bob" shares his password with "Steve" "Steve" logs in the password is reset. Steve now does harm to the server. Do the run8 logs contain enough info for us to know that Steve was using Bob's password? Or do we need supplemental logging to tie a UID to a time frame.

This makes me wonder if we should just send John a Portillos cake and ask him nicely if he could update some of the code that's causing trouble for us.

Everyone likes Portillos cakes right?

[sjstein]

The only info the logs show when a user connects is: Run8 name, ip#, UID, password

So the forensics would go something like: Steve logs in a screws around in the server If steve didn't "spoof" Bob's name by changing it before logging in, then we can at least be pretty certain it isn't Bob that did it.

If Steve did change his name to look like Bob, the next level of sleuthing would be to check the IP#s. Compare to previous logins where the real Bob got in, and then look at this latest one who defaced the server.

Along those same lines, we could look back and see the UIDs of the valid Bob, vs the bad actor Bob.

However, in the end, Steve is probably at least partially responsible because he shared his password and will likely be banned or at least warned.

[sjstein]

So what about rather than rolling this into the bot, it is a separate tasks running like a daemon (kind of like @Garrisonsan log bot - but no tie-in to discord). This daemon monitors the status of the log file looking for the successful login messages and logout messages.

When Steve (from the example above) logs in, the daemon sees it in the log and makes a note internally (maybe writes it's own log?): User: Steve, UID: <uid>, Log in timestamp : <datetime> Daemon builds up a table of users logged in at any specific time

Later, Steve leaves the server. The Daemon notices (again, maybe logs the event to a file) and then opens the HostSecurity.xml file and nukes Steve's UID.

I like this method for a couple of reasons:

• It doesn't mess with the core bot code - which we all hope at some point will be able to work well with a sane server security scheme
• It keeps the UID entry in the XML while users are logged in. This prevents Steve giving Bob his password so they both can get on at the same time
• It is easier to maintain as a standalone daemon, and will allow the bot maintainer the ability to use or not

[sjstein]

It was decided with @Garrisonsan to table this effort for now as the potential for introducing bugs plus the opening up a (slight) vulnerability risk isn't worth it at this point. Hoping again for a solution from the devs at some point.

[sjstein]

I have a stop-gap solution for those admins who want to use. The bot can start a thread which will periodically check the host security file(s) for modification, and if it finds that there has been an update, will re-write the file(s) without the UID entries.

Time between checks is selectable from the configuration file - setting to 0 will disable this feature.

[sjstein]

This has been addressed as outlined above and incorporated in branch #91