Saving a variable client-side (persistently)

[serthy]

Sorry for beeing blind, but whats the difference to the one that is already used on alot of servers?
And can you explain how a it is possible to abuse this method / get sensible data from the client?

[IzNoGoD]

Sorry for beeing blind, but whats the difference to the one that is already used on alot of servers?
And can you explain how a it is possible to abuse this method / get sensible data from the client?

The difference is that it uses a challenge-response combination.

It works as follows:

Client creates an account, stores a loginname cvar and a randomized challenge cvar. Looks like this:

seta izno_challenge_bhwv95nfivapvr3r2co5z88m9tfk4t "openscriptmenu clientcmd chal_4delnmwge5n5qyl6o0tau9dfnwdmjj"
seta izno_loginsystem "openscriptmenu clientcmd login_0tljzgz93cwhdm0fafixr8c9w2mrta"

For now, lets replace this random numbers and shit with the following (for example sake):

seta izno_challenge_CHALLENGE"openscriptmenu clientcmd chal_RESPONSE"
seta izno_loginsystem "openscriptmenu clientcmd login_USERNAME"

So, server creates a USERNAME.txt file, in which both CHALLENGE and RESPONSE are stored.

Next time a client connects to the server, the client executes the given .cfg file (atm it is izno_login.cfg), and the cvars are loaded.
Now, the server tells the client to vstr izno_loginsystem, thus generating a menuresponse (clientcmd, login_USERNAME).
The server now opens the USERNAME.txt file, looks for the challenge and does the following:
[player] execclientcmd("vstr izno_challenge_CHALLENGE");

From this, the client responds with the appropriate menuresponse that was stored in this randomized cvar (clientcmd, chal_RESPONSE).

Now, the response given by the client should match the one on file at the server.

The added layer of protection here is that the server has to KNOW which cvar the client has to execute, as it is randomized on a per-client basis, thus not allowing rogue admins to clone the serv and steal the login details directly.

The security hole with this is, if the rogue admin gets the USERNAME, he can try to authenticate himself on the real server, which will require the CHALLENGE. As the admin can intercept this command, he can then modify his server to also request this data from the targetted client. This requires a lot of work for the rogue admin (as he has to mod his serv for every client he wants to hack), it is most likely not a feasible angle of attack. However, once in, no one can stop him.