So, I was talking to T3 the other day on his server about how to secure parts of PRISM. I've come to the conclusion that this can be done correctly only for the web site front end and in game, where a chain or trust already exists. Anything that happens within PRISM regarding passwords can't be considered safe if you don't trust the host that is running PRISM. PRISM is the man in the middle in this case, and that's the nature of the beast. So the only solution is to remove the man in the middle from handling any senstive information that it can't be trusted with. There are 3 aspects where this becomes important.
Regarding demo users vs that of S1 and S2.
There is another argument to be made about the level of trust extended to a DEMO user vs that of a S1 or S2 user. Where a user has unlocked his client to a S1 or S2 level is a authenticated user that can be tracked and handled. Demo users on the other hand don't have this level of trust extended to them as the client's status has no weight or value. The information could be used once and thrown away by each demo user as their accounts are banned from servers.
- In Game.
In game, the client is already authenticated by the LFS master servers. This is not the case with demo races, but a level of trust can be assumed. On S1 and S2 servers the level can be asserted to a slightly greater level as user name and password is required to connect to a S1 or S2 server with the game client. (Ie, the game has to be unlocked with the client's password.) This can not be absolute as there may be a situation where the LFS client can be compromised, and that would also compromise the integrity of PRISM. But really, if the game trusts them, we should trust them too.
- On PRISM's Web Front End.
There is where OAuth comes in. Whereas LFSWorld / LFS.net set it's self up as a OAuth provider. When some one tries to login to the web site front end, they are asked to login using their LFS credentials, but as the username and password is entered on LFS's servers and not PRISM's we can again trust that as long as LFS says that it's ok, then it should be ok for us as well.
- On PRISM's Telnet Client.
This one is the hard one. The telnet client is handled on PRISMs end. We can't use a LFS password for this case as the server operator might change the nature of how PRISM works and instead of sending your password to LFSWorld, it might do that, but also save it plain text in a file some where. This is not an acceptable security risk, so users within say the website front end, or the game would have to setup a password from there. So the chain of trust only extends to the PRISM server host, but it leaves the security of the LFS information intact as it would not use those credentials.
Regarding demo users vs that of S1 and S2.
There is another argument to be made about the level of trust extended to a DEMO user vs that of a S1 or S2 user. Where a user has unlocked his client to a S1 or S2 level is a authenticated user that can be tracked and handled. Demo users on the other hand don't have this level of trust extended to them as the client's status has no weight or value. The information could be used once and thrown away by each demo user as their accounts are banned from servers.
