Ok, so probably the main problem people have with using others scripts is the possibility of passwords getting stolen, it is just too easy for someone to make a script that sends out passwords (as most people just tend to click allow for everything that pops up).
So here is my proposal. Add a dll, written in C++ that uses Crypto++ (public Domain) to encrypts and stores usernames and passwords. I'm not quite sure how it should be done though. Ideally we would just be able to send a message to the DLL like "GetNextPlayer" and the DLL should handle a pop-up that asks for a password. if the correct password is entered then it should go out and get the next player info and give it to SRL to log the player in.
The problem with that is that a function call like that would also be available to someone outside of SRL, so asking for the encrypted password would be possible even outside the script. So the Less then ideal solution would be to make the DLL handle all the login stuff, and then just say "LoginNextPlayer" to the dll, which, in turn, moves the mouse ect. This would be more secure as the password is only ever accessed by the DLL and never outside of it, but it would be far more complicated because of things like needing to tell the DLL to use smart functions or not ect.
So, the benfits would be things like
1. Players wouldn't need to worry about filling out data for multiplayer, as that would be handled by a file they create.
2. Scripter wouldn't have to worry about leaving their account info in a script as it is stored in a separate file.
3. Even if they do somehow include their info it is encrypted making it pretty hard for someone else to recover.
4. It would give some peace of mind to the Script user as they would be able to have more confidence that no backdoor communication is happening.
The downfalls would be.
1. Players would have to run a setup script of some sort to initially make the players file.
2. As discussed above, the DLL might have to take on SRL functions ect to be able to run without exposing the password.
3. If the DLL doesn't do this, the password could be just as obtainable as if the DLL didn't exist.
So, what do you all think? Good idea, bad idea, unneeded idea. For me, the benefits would outweigh the losses. I know this wouldn't be perfect protection, as a malicious scripter could easily mimic the encryption pop-up to fool the user in giving them the decryption password. However, I don't think too many of the malicious scripters are advanced enough to do that. (some protection is better then no protection)





. For me, the benefits would outweigh the losses. I know this wouldn't be perfect protection, as a malicious scripter could easily mimic the encryption pop-up to fool the user in giving them the decryption password. However, I don't think too many of the malicious scripters are advanced enough to do that. (some protection is better then no protection)
Reply With Quote





. Either way it's a good idea.











