triplea-game / triplea

TripleA is a turn based strategy game and board game engine, similar to Axis & Allies or Risk.
https://triplea-game.org/
GNU General Public License v3.0
1.34k stars 393 forks source link

Single Use Login Token - Login Migration to New Schema #4766

Open DanVanAtta opened 5 years ago

DanVanAtta commented 5 years ago

Wanted to sketch out an idea of how to migrate from 'old' DB schema to new, and incorporate Https server.

(1) clients will do login against an https endpoint. Succesful authentication will return back a 'single-use-token'. (2) clients will use existing code to initiate a java socket connection (QuarantineConversation), but instead of doing the challenge sequence, the client will send the single-use-token. (3) the socket server part of the lobby will then accept a socket connection if the token is valid.

I'm thinking to support Moderator Toolbox 2.0, they'll instead use a token that is granted specifically to moderators and is re-used over https.

In this sequencing there is a concept and flow coordination between the http component, client, and lobby. I've been wondering how do we share code and concepts between at least the http component and lobby. There are some options like we could have the lobby communicate to http component, we could have the two share a DB. I'm thinking combining the two is perhaps the easiest to have a single lobby monolith with multiple communication endpoints.

RoiEXLab commented 5 years ago

@DanVanAtta I'd recommend going with a widespread standard like OAuth or OpenID Connect. Haven't had any problems with OIDC so far, been "using" it (through keycloak in case someone knows it). If you think having a complete network layer with tokens expiring every 5 minutes and what not is overkill, simply using a standardized format like JSON Web Tokens is ok for me as well. The reason I value standards so high in this regard is because of "never roll your own crypto". I know that @ssoloff and myself tried as best as we could to somehow secure passwords at least, but I couldn't guarantee you that the security is bullet-proof.

RoiEXLab commented 5 years ago

BTW. In case you're not familiar with JSON web tokens: They basically are a signed wrapper for a user-defined payload in JSON format, so it could store all the information you want in there and can be sure the client isn't able to maliciously change the information without breaking the signature.

DanVanAtta commented 5 years ago

@RoiEXLab are we on the same page, the socket layer I'm referring to is the existing one, it is communication in the clear. Hence why the token the client gets back is a single use. This is not roll-your-own crypto.

Essentially https would issue a one-time password. The client would then send that one-time password when it wants to create a socket connection. Today we have code that sends such connections to 'quarantine' if they have not authenticated and challenges for password. Instead of that the server would either accept a token or reject.

All the crypto here is done at the https layer when the client sends us the password. There would be a one way hash eventually to compare password to what is in DB, but that will be down the road.

RoiEXLab commented 5 years ago

@DanVanAtta Ah, thanks for the clarification. I didn't realize this was a proposal to bridge the gap. Makes sense now 👍

stale[bot] commented 5 years ago

The TripleA team regrets this issue was not solved sooner. To keep focus on latest issues and the most pressing tasks, this issue has been automatically marked as stale because it has not had recent activity. If the issue may be closed, please do so. If there are remaining items, we encourage for those items to be resubmitted as new, independent, concise tasks. The strategy is divide and conquer. Thank you for your contributions.