[Mod] FediAuth [fediauth]

[frssoft]

2FA via Fediverse account, based on the original mod https://content.minetest.net/packages/mt-mods/otp/ by BuckarooBanzai
Lets Fediverse players use the

Code: Select all

/fediauth_on

command to protect their account with a second factor.

Players that have the FediAuth enabled have to enter a verification code upon joining the game, the code will be sent to their account handle (@nick@example.com).

That mod requires add to

Code: Select all

secure.http_mods = fediauth

for sending codes from service account (any mastodon API compatible instance)

Add

Code: Select all

fediauth.instance = example.com

and

Code: Select all

fediauth.api_token = secret

for work this mod.

Also you can enable

Code: Select all

fediauth.fedi_required

option and players who not have fediverse account can't play on server

NOTE for server admins: remember, minetest can't revoke privileges from server admin (UPD: 05.10.2023, mitigation in latest release), for mitigation of it use separate account for administrative purposes and better secure way - terminal via ssh.
NOTE: this mod conflicts with original `otp`
License:

• Code: `MIT`
• "basexx.lua" `MIT` https://github.com/aiq/basexx/blob/mast ... basexx.lua

Textures:

• fediverse.png from https://commons.wikimedia.org/wiki/File ... oposal.svg by Eukombos, CC0 1.0
• checkmark.png (aka blobfoxcheck.png) from https://volpeon.ink/projects/emojis/blobfox/ by Feuerfuchs <me@feuerfuchs.dev>, Apache 2.0

CDB: https://content.minetest.net/packages/frssoft/fediauth/
Download: [1a6ee] created 2023-10-05. (Changes)
Git: https://git.phreedom.club/localhost_frssoft/fediauth
[0458d] created 2023-10-03. (Changes)
[33586] created 2023-10-02_1 (Changes)
[8bd61] created 2023-10-02. (Changes)
FediAuth [e0899] created 2023-09-30

[Blockhead]

This will definitely be helpful for some people to add security, so good work. I had to do a bit of digging to figure out what the mechanism is though. It seems to use the Mastodon API to push a direct message to the user that will come from a service account for the Minetest server, is that right? Quite interesting - I say as someone who hasn't used Mastodon.

Now on a note for something I know more about: This mod appear to use stackoverflow-implemented bit operation functions, but Minetest bundles the bitop library with its Lua, and LuaJIT has them too, so you should have bitwise operations available in any Minetest environment and not need a Lua implementation. The native implementation should speed things up and be better vetted.

[frssoft]

It seems to use the Mastodon API to push a direct message to the user that will come from a service account for the Minetest server, is that right?

Yeah. You can use any account as "service", include your personal account, but no recommend because - you can see too many direct messages per day (if too much active server)
Also, example simple scheme:

Code: Select all

 [user_mt]  <-  [@account_on_fediverse@example.com]
 |                                                ^
 |                                                |
 mt_server -> masto_api -> DM with temporally code (from @minetest_service_acc@example.com)
 

In addition, I would like the mod to set up an independent fediverse instance server (like owncast), but in lua language it is extremely difficult to do... More simple solution - use external service and API.

Minetest bundles the bitop library with its Lua, and LuaJIT has them too

Oh, thanks! I try it migrate to native functions. Just in the original mod use stackoverflow implementation and I don't changed it

[frssoft]

New release: [8bd61] created 2023-10-02.

Changes:

• Fix license issues again, for approve package on CDB
• Migrate to native minetest bitwise operations (except basexx), thanks viewtopic.php?p=429240#p429240

[LMD]

Some cents regarding the code:

- There is no need for bitops at all. Selecting bits can be done using just the remainder operator and floor division (but since we have bitops now, that is the cleaner / more efficient approach). Side note: "write_uint64_be" raises an eyebrow - Lua 5.1 doesn't have 64-bit integers, and 64-bit floats can only represent integers up to 2^53 accurately.
- I see some string manipulation antipatterns; using some loops rather than string.rep or string.gsub to process strings, mainly. This will likely have suboptimal performance (though it may be fine, since most things are of low constant length) and be harder to read.
- i_pad and o_pad can be written as just string.char(0x36):rep(64) and string.char(0x5c):rep(64) respectively. They don't seem to be necessary at all, though: You're building these strings just to index them, which is pointless. You should inline the 0x36 / 0x5c constants for the XOR instead.
- The loop for concatenating i_key_pad and message is pointless, you could directly do i_key_pad .. message. Same for the second concat loop.
- left_pad could be written as just s:rep(#str - len) .. str.
- The loop in generate_secret could be replaced with just buf:sub(1, 20)

I'm not sure how I'd rewrite the generation of i_key_pad and o_key_pad; I'd probably first pad them, then use gsub. Or I'd keep i_pad and o_pad around, and use gsub on those. A simple rope + table.concat or a recursive function that produces a vararg to be fed to string.char also come to mind... That said, since the loop limit is constant and low, this could of course also be kept as-is if the alternatives are deemed to be too unreadable.

[frssoft]

Some cents regarding the code

Thanks for advise! Commit message: https://git.phreedom.club/localhost_frs ... bbc102af5c

[frssoft]

New release: [33586] created 2023-10-02_1

Changes:

• mini generation code optimizations, thanks viewtopic.php?p=429245#p429245
• removed unused qr generation png
• reformat message in send_code
• added locale for send_code
• added automatic deletion as option

[sorcerykid]

Interesting implementation. I will say that realistically, it should be impossible to join the server until the correct 2FA code is entered.

While you can revoke privileges, the other game mechanics are not suspended. For example, I developed a temperature survival mod for my server that damages players if they are outdoors in freezing weather. The damage is dealt unconditionally, regardless of whether the player is busy entering a 2FA code into a modal form. This is unfortunately just the nature of how the Minetest engine works in multiplayer.

This is why I think the prejoinplayer callback should be enhanced to allow mods to request additional form input from the end-user before they can join the server. Or perhaps some other intermediary challenge-response mechanism specifically designed for custom authentication, where the player is not actually added to the environment until approved.

[frssoft]

The damage is dealt unconditionally, regardless of whether the player is busy entering a 2FA code into a modal form. This is unfortunately just the nature of how the Minetest engine works in multiplayer.

Hm... This is good point. Maybe just make immortal player when busy entering a 2FA? But, they too limited - code valid around 60~ secs
But... It can be used for cheat, example - pvp, player just rejoin and stop damage from another player (also it works in reverse)

And maybe i think freeze player position or just make unbreakable blocks around player...

[Blockhead]

Interesting implementation. I will say that realistically, it should be impossible to join the server until the correct 2FA code is entered.

...

While I can agree that it would be nice to have a way to serve a custom "pre-join" formspec or similar for server admins who want this, I think that there are plenty of servers where it's not a concern, or the player bears responsibility for logging out in a safe area.

Creative mode servers and servers with safe spawns and safe houses will be fine. On survival servers, logging in in the night or in a dangerous area is inherently dangerous and you probably just shouldn't log out in a spot that could leave you exposed. Even if it's just night mobs, through a spot of bad luck you can still get a nearby mob spawn or mob that's saved to the block pop in and knock you out really quick.

There are other mods that serve formspecs when you relogin too, like MOTD and server news formspecs. A lot of those I find pretty annoying honestly. I can think of an (in my view) bigger problem than survival server logins though - being able to move the character around with a cheat client is quite likely even without privs. That's a security concern that I don't think the current implementation addresses (could be wrong).

[sorcerykid]

I believe it would technically be possible to change the user password as well, since the ESC menu is builtin to the client and is always available as soon as the player enters the game. Also I suspect the user would still able to issue chat commands. In both cases, a hacked client can simply close the authentication form silently, making both the F10 chat console and ESC menu available. So at the very least you need to filter chat messages and intercept password changes from the user until authentication is complete.

Not to minimize the effort put into this mod, but aside from the gameplay issues mentioned above there are some security concerns that likely need to be addressed.

[frssoft]

I believe it would technically be possible to change the user password as well, since the ESC menu is builtin to the client and is always available as soon as the player enters the game.

Attempt mitigation of it in next release soon as possible. (already done, but no released)

Also I suspect the user would still able to issue chat commands.

Only commands with privs = {}

[frssoft]

Try hack please (for testing hackability):
server: fediplace.minetest.land
port: 30000
login - mt_pentest0x01
pass - pentest

[frssoft]

New release: [0458d] created 2023-10-03.

Changes:

• Security fix (mitigation): password can't be changed now, during fediauth verification, thanks viewtopic.php?p=429275#p429275
• Security fix: /fediauth_on can't be called without interact privilege, now bad actor can't change 2FA handle
• Integration with yl_matterbridge: if bad actor try change password, message will be sent
• Position locked by default (teleport + reduce player velocity)
• Player by default immortal, solve that problem: viewtopic.php?p=429267#p429267
• Jail cubic removed, because huge overhead and not work as well
• Formspec fix on enter keypress

[frssoft]

I try make strongest security be like:

[frssoft]

New release: [1a6ee] created 2023-10-05.

Changes:

• Security will be strongest by default!*
• yl_matterbridge disabled by default, but have in settingtypes

*

Also I suspect the user would still able to issue chat commands. In both cases

(now it mitigated (include server admin), but not panic if you got locked in --terminal - just input /fediauth_unlock [random code above in console]; or just join to world as admin, also you can manage your server via szutil_consocket without any restrictions as "root")

So... I attempt make it secure as possible, but still not ideal, and any buffer overflow can broke it (include other mods), or just another CVE like curl skip TLS. Security is too much complex and harder... And is process, infinity process...
This mod can't help you if you install another suspicious mod, or just unprotected your host machine and etc... etc...
This mod can't help you if some one try hack your account 24/7, professional hacker still can find hole in mod or engine...

[sorcerykid]

I haven't looked at the code, but it sounds like the measures you put in place should be sufficient now.