Add api for custom authentication

[Outfluencer]

PreLoginEvent now has an option for disabling the authentification, if disabled after encryption a custom authentification event is called to authentificate the player, In this event the session data can be set (if not set an exception is thrown (client gets kicked))

Its possible now to cache the session of a player by their ip address as example or to authentificate the player with Cookie data as mentioned by mojang here

[Outfluencer]

any thoughts on this?

[md-5]

What's the actual use case?

[Outfluencer]

Setting auth data with a cookie. Transfer the player to another bungee, set authentificate to false, and authentificate the player by the signed or encrypted cookie auth data without contact the auth server of mojang

[md-5]

What's the purpose of that though, speed?

Doesn't it also place the client at a MITM risk given there's no verification with Mojang servers?

Do other client functions like skins and secure chat work given the client thinks its offline mode when it's actually online mode?

[Outfluencer]

The client also think it is in online mode everything works

[Outfluencer]

It can have many purposes speed could be one of them also you could connect to the server if the auth server are offline and you could change the profile of the player, or skin data to whatever the plugin developer wants

[Outfluencer]

Could you please explain the MITM risk? I don't understand what the risk is (i know what man in the middle is, but i dont understand the risk for the mc client here)

I don't think that there are real risk as mojang added this feature exactly for that reason

[md-5]

Could you please explain the MITM risk? I don't understand what the risk is (i know what man in the middle is, but i dont understand the risk for the mc client here)

I don't think that there are real risk as mojang added this feature exactly for that reason

Well because there is no challenge response and the server is offline, you could just pass the encrypted cookie straight through to authenticate

[Janmm14]

A previously set cookie in the first connection with authenticate true can be checked to prevent mitm

This requires plugins to be mindful.

Edit: Wrong

[md-5]

How does that help?

[Janmm14]

How does that help?

Uh yeah, my bad. That does not help prevent mitm.

So in such cases think mojang has added a feature without this in mind and its only purpose was to ease the load on mojang's auth servers.

[md-5]

only purpose was to ease the load on mojang's auth servers.

Weird that Vanilla doesn't do anything with it then. I wonder if it was really just a poorly thought out example, as there are clear other uses for the cookies (eg, eliminating or making much easier the use of a database to maintain player state)

Alternatively, perhaps by authentication they meant things such as remembering a 2fa session

[Janmm14]

That doesn't make sense. 2fa session stuff is handled by microsoft's login system, not minecraft related.

How could vanilla do anything with the authenticate boolean, its a thing solely meant for customized multiplayer networks cross-server stuff.

But tbh many server networks might not care about MITM or even encryption, I was thinking about using this transfer API to get rid of encryption CPU time on bungee after authentication with a plugin or so.

[md-5]

That doesn't make sense. 2fa session stuff is handled by microsoft's login system, not minecraft related.

I meant a server side 2fa plugin

How could vanilla do anything with the authenticate boolean, its a thing solely meant for customized multiplayer networks cross-server stuff.

True, now I'm confused how the authenticate boolean is different from offline mode

[Outfluencer]

That doesn't make sense. 2fa session stuff is handled by microsoft's login system, not minecraft related.

I meant a server side 2fa plugin

How could vanilla do anything with the authenticate boolean, its a thing solely meant for customized multiplayer networks cross-server stuff.

True, now I'm confused how the authenticate boolean is different from offline mode

You connection is still encrypted

[Janmm14]

That doesn't make sense. 2fa session stuff is handled by microsoft's login system, not minecraft related.

I meant a server side 2fa plugin

How could vanilla do anything with the authenticate boolean, its a thing solely meant for customized multiplayer networks cross-server stuff.

True, now I'm confused how the authenticate boolean is different from offline mode

If you ignore MITM as risk. What stays is encrypted connection + previous cookie usage can identify users. IPs are no valid way to identify a single household. (i.e. public wifi, University networks / ISPs putting multiple customers on same IP, etc)

Edit: A serverside, in-minecraft 2fa system can not eliminate MITM, just like cookies can not.

[Outfluencer]

That doesn't make sense. 2fa session stuff is handled by microsoft's login system, not minecraft related.

I meant a server side 2fa plugin

How could vanilla do anything with the authenticate boolean, its a thing solely meant for customized multiplayer networks cross-server stuff.

True, now I'm confused how the authenticate boolean is different from offline mode

If you ignore MITM as risk. What stays is encrypted connection + previous cookie usage can identify users. IPs are no valid way to identify a single household. (i.e. public wifi, University networks / ISPs putting multiple customers on same IP, etc)

Edit: A serverside, in-minecraft 2fa system can not eliminate MITM, just like cookies can not.

depends on the usecase, if i have a server with a static ip that i use as a proxy i could securly authentificate by it for example. The security is on the plugin developers side

[Janmm14]

If you ignore MITM as risk. What stays is encrypted connection + previous cookie usage can identify users. IPs are no valid way to identify a single household. (i.e. public wifi, University networks / ISPs putting multiple customers on same IP, etc) Edit: A serverside, in-minecraft 2fa system can not eliminate MITM, just like cookies can not.

depends on the usecase, if i have a server with a static ip that i use as a proxy i could securly authentificate by it for example. The security is on the plugin developers side

The MITM risk can not be eliminated. With mojang authentication, the mitm risk is only when mojang/microsoft servers/certificate is leaked. Without mojang authentication, the mitm risk is just as high as unencrypted connection.

asymmetric into symmetric Encryption like Minecraft uses, without verified other endpoint, only provides protection against read-only MITM, but not write/change-able MITM.

[Outfluencer]

i personally would like to have and use this by mojang added feature, if a server admin don't want it they don't have to use it. i think the benefits outweigh the risks.

we could add a api note, that disabling auth is putting the client into a MITM risk. There a enough public offline mode servers and all of them have the risk of MITM and nobody is complaining

[Janmm14]

But as a mitm risk exists, i don't see any benefit of wasting server cpu cycles on encryption, let the users of bungee either have it completely secure or online-mode false. Not this weird middleway.

[Outfluencer]

Its a perfect way to create fail-safe fallback servers even if the mojang servers are offline. If for example a bungeecord server laggs very hard or has a very bad ping (maybe because internal hoster issues, or an attack) You could store the current auth data in a cookie and transfer the player in online-mode to a different proxy (possible with a different routing or on different hoster)

Currently if a server has issues you can't do much.

I am currently working on a bukkit impl for a server network with transfers and cookies out of curiosity i will also add a impl for bungeecord.

to improve the transfer success rate to maximum this change would be needed

if i would transfer enought players at the same time mojang would throttle the auth requests. (so maybe players cant be transfered)

If i have a attacked bungee instance for example with 200 players, and i send them to a different bungee i think mojang will reject some of the 200 auth request the server ist requesting when the players are all transfered

Make the connection cracked is not a solution for me as i think that the offline Tablist would scare much players. They would think something is wrong. if the have a cracked tablist.

[Janmm14]

Its a perfect way to create fail-safe fallback servers even if the mojang servers are offline. If for example a bungeecord server laggs very hard or has a very bad ping (maybe because internal hoster issues, or an attack) You could store the current auth data in a cookie and transfer the player in online-mode to a different proxy (possible with a different routing or on different hoster)

Currently if a server has issues you can't do much.

I am currently working on a bukkit impl for a server network with transfers and cookies out of curiosity i will also add a impl for bungeecord.

to improve the transfer success rate to maximum this change would be needed

if i would transfer enought players at the same time mojang would throttle the auth requests. (so maybe players cant be transfered)

If i have a attacked bungee instance for example with 200 players, and i send them to a different bungee i think mojang will reject some of the 200 auth request the server ist requesting when the players are all transfered

Make the connection cracked is not a solution for me as i think that the offline Tablist would scare much players. They would think something is wrong. if the have a cracked tablist.

No I mean, you can simply have the connection as offline mode, but that does not mean you cannot use cookies to set the player's uuid to the online mode uuid (via existing setter) and set the player's profile (later one would currently need reflection or a new setter) for later forwarding.

[Outfluencer]

Yeah but can you make the tablist have the normal online-mode look this way?

I thought the tablist look depends on enabled or disabled encryption

[Janmm14]

Yeah but can you made the tablist have the normal online-mode look this way?

If one sets the uuid and loginProfile in InitialHandler to what they are in onlineMode, the forwarding mechanism should work as usual and therefore provide a normal tablist, as it doesn't check for online/offline mode, jsut if the login profile is filled: https://github.com/SpigotMC/BungeeCord/blob/5fbcc6b1195addc96673c8d9e70521562e12120b/proxy/src/main/java/net/md_5/bungee/ServerConnector.java#L118

Edit: I am not aware whether the client displays the tablist differently when the connection is not encrypted.

[Outfluencer]

I dont think its working like this

[Outfluencer]

if you are on offline mode (clientside) witch bassicly means not encrypted the tablist dont show the player heads

if you are in online mode (with auth or without) it will display the heads

[Outfluencer]

online mode with or without mojang auth:

offline mode:

[nellieldev]

Yeah but can you made the tablist have the normal online-mode look this way?

If one sets the uuid and loginProfile in InitialHandler to what they are in onlineMode, the forwarding mechanism should work as usual and therefore provide a normal tablist, as it doesn't check for online/offline mode, jsut if the login profile is filled:

https://github.com/SpigotMC/BungeeCord/blob/5fbcc6b1195addc96673c8d9e70521562e12120b/proxy/src/main/java/net/md_5/bungee/ServerConnector.java#L118

Edit: I am not aware whether the client displays the tablist differently when the connection is not encrypted.

bro if you don't know what you are even talking about maybe you should stop talking, to clarify: Vanilla clients won't display tablist with heads if you don't get an encryption request.

[nellieldev]

But as a mitm risk exists, i don't see any benefit of wasting server cpu cycles on encryption, let the users of bungee either have it completely secure or online-mode false. Not this weird middleway.

I don't really understand why you would block that option right away. There are possibilities of MITM attacks, yes, but it's still the decision of the server owners whether to implement a custom encryption scheme or not. Also the possibility of a such an resource-expensive MITM is very low and would never even occur just for a minecraft server. I don't see the point in not implementing new minecraft features just because they might be insecure upon wrong usage. Also, you could even implement it to be not like a custom auth scheme option but only to make it an option for the usage of the new encryptionDisabled boolean in encryption request packets which is also a vanilla change, which still aims to allow servers to implement their own custom auth scheme like mentioned before.

[Outfluencer]

Could you please explain the MITM risk? I don't understand what the risk is (i know what man in the middle is, but i dont understand the risk for the mc client here) I don't think that there are real risk as mojang added this feature exactly for that reason

Well because there is no challenge response and the server is offline, you could just pass the encrypted cookie straight through to authenticate

did we not have the same MITM risk if BungeeCord connects to a not local backend server?

[Outfluencer]

Just that in this case the risk is between backend and bungee and not bungee and client?

[Janmm14]

bro if you don't know what you are even talking about maybe you should stop talking, to clarify: Vanilla clients won't display tablist with heads if you don't get an encryption request.

Your tone is disgusting. I admitted a knowledge gap and all you can do is harrass me.

[nellieldev]

bro if you don't know what you are even talking about maybe you should stop talking, to clarify: Vanilla clients won't display tablist with heads if you don't get an encryption request.

Your tone is disgusting. I admitted a knowledge gap and all you can do is harrass me.

You literally said that yourself and still claimed knowing better. I think your behaviour is disgusting, maybe stop answering to well thought out things without even spending one minute on your reply. I think there is more effort appropiate in your reply on eloberate ideas than this. In my eyes my response was perfectly fitting to yours, I did at least take my time to state my opinion and thoughts about it and had my efforts.

To sum up: Think TWICE what you write and check your facts and if it is correct and don't make us high efforts worth nothing by lowering the level of conversation.