Add api for custom authentication #3670
Conversation
Outfluencer
changed the title
|
any thoughts on this? |
|
What's the actual use case? |
|
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 |
|
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? |
|
The client also think it is in online mode everything works |
|
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 |
|
Could you please explain the MITM risk? 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 |
|
Edit: Wrong |
|
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. |
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 |
|
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. |
I meant a server side 2fa plugin
True, now I'm confused how the authenticate boolean is different from offline mode |
You connection is still encrypted |
If you ignore MITM as risk. 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 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. |
|
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. we could add a api note, that disabling auth is putting the client into a MITM risk. |
|
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. |
|
Its a perfect way to create fail-safe fallback servers even if the mojang servers are offline. 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 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. |
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. |
|
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 |
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: Edit: I am not aware whether the client displays the tablist differently when the connection is not encrypted. |
|
I dont think its working like this |
|
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 |
|
online mode with or without mojang auth: offline mode: |
bro if you don't know what you are even talking about maybe you should stop talking, to clarify: |
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. |
did we not have the same MITM risk if BungeeCord connects to a not local backend server? |
|
Just that in this case the risk is between backend and bungee and not bungee and client? |
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. |
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