Initial draft of the Session ID security proposal #8
Conversation
|
|
||
| ## Concerns | ||
|
|
||
| ### DRM |
There was a problem hiding this comment.
This entire section is problematic, as it wasn't reviewed by someone with the required legal skills to decide whether it is a DRM circumvention or not. In general, modifying DRMs, no matter what the modification is, will be considered as unlawful. In the absence of such reviewing, we should stay caution and not arbitrarily decide something is within the law without careful reviewing.
There was a problem hiding this comment.
I could not present this to Mojang in good faith with these assertions - it's not up to us to decide and "the authors believe" is not an OK thing to say when the MMPA itself does not believe.
|
|
||
| For clarity, we will refer to Java process that runs Minecraft as the Minecraft process, and the other process as the session ID process. | ||
|
|
||
| At some point during or before the launch, the session ID is given to the session ID process. The session ID is them removed from the Minecraft process. The Minecraft process then has `com.mojang.authlib.yggdrasil.YggdrasilMinecraftSessionService#joinServer` rerouted to ask the session ID process to join servers instead. The session ID process then uses the session ID to contact the Mojang session servers. |
There was a problem hiding this comment.
What would prevent a malicious mod from talking to the session ID process itself? Obviously, the solution presented here would secure the token from being exfiltrated. But if all an attacker needs is brief access to the account (which is likely the case if they are targeting a session token) all a malicious mod would need to do is "join" a server directly in the local client and do some malicious actions.
There was a problem hiding this comment.
This is a concern with the current implementation, however it is rather difficult to secure it against this case. A solution to this problem would be to have the session ID process handle the entire process of logging into Minecraft servers, with the process asking the user if they want to join the server. However this solution is more difficult to implement, and I believe that the current solution is a large improvement over the current situation
There was a problem hiding this comment.
This proposal would only limit the scope of the token to the runtime of the client. That is a net gain. However it could be much simpler if launchers could revoke session tokens after the game was closed. We would achieve almost the same effect that way
|
|
||
| ## Concerns | ||
|
|
||
| ### DRM |
There was a problem hiding this comment.
I could not present this to Mojang in good faith with these assertions - it's not up to us to decide and "the authors believe" is not an OK thing to say when the MMPA itself does not believe.
|
|
||
| ## Proposed solution | ||
|
|
||
| For clarity, we will refer to Java process that runs Minecraft as the Minecraft process, and the other process as the session ID process. |
There was a problem hiding this comment.
What does "the other process" refer to? I don't think this is explicit enough to clarify.
This is a draft and is liable to change