Add support for using hashed passwords for bot editor security.

[togetherwithasteria]

Hey, I think it would be nice if servers can use hashed passwords for the Bot Editor password. So if the hosting is compromised by pesky hackers, they can't know the password of the Bot Editor menu.

[Bizarrus]

ToDo: Check if Hashing-Algorythm exists on Lua 5.4.3.

[togetherwithasteria]

Even if it doesn't, we can use third-party libraries. Maybe this or other libraries. Google will help.

[Bizarrus]

Sure, but built-in methods are better (if these are exists).

Personaly, i'm not a fan of huge/overloaded/overpowered external libs.

[togetherwithasteria]

Ah yes, dependency hell.

[togetherwithasteria]

But yeah:

https://stackoverflow.com/questions/1940696/accessing-built-in-string-hash-functions-of-lua

There is, just not exposed.

[Bizarrus]

I've given it some thought: Currently, the configuration is supplied as a shared resource in the client as well.

No matter if the password would be hashed or not, in theory you can read both in the client. Hashes would be safe with a salt, but without, there would be rainbow tables to figure out the plaintext.

I would go and remove Config.settingsPassword!

There would be two ways that would now be implemented (regardless of whether the password is now hashed!):

• Idea 1: One has an extra file called Authentication.lua, which is located exclusively in the directory /ext/Server/. If this file does not exist, there is simply no password set, otherwise the content is taken as password:

Authentication = {
    Password = 'fun
};

or as hash:

Authentication = {
    -- fun-bots$<password> as SHA1
    Password = '4019b2d152c65ce78761104a4d50b86a133047de' -- "fun"
};

This would be the master password. In addition to this change, I would additionally implement user-specific passwords in the SQLite database. This way the main admin can give a player a seperate access, which might also be given different permissions:

• Can execute ChatCommands
• Can call the UserInterface
• [...]

Here we can provide/add some new permissions later.

• Idea 2: We don't use passwords for that. The user must set an admin/user over RCON command or over SQLite. This will prevent bruteforce attacks on the JavaScript-Console. The user will stored here directly in the SQL-Database.

Advantage: We get away from passwords and use the account GUID for authentication.

As already mentioned in idea 1, there would also be various permissions that can be set here.

What is the best idea for that?

[togetherwithasteria]

That's make sense. We can make the bot editor permission-based instead of password-based.

However though I think it would be better someone create a Universal Permission Manager mod for VU that any mod can use to check user permission. The concept is kinda like LuckPerms, a permission manager plugin for Minecraft servers.

[Bizarrus]

I will close this issue, because the Permissions-Feature is upcoming to the next big release.