SRL Archive - SRL Archives

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 :D. 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)

This would be somewhat more secure than the current system of following this and using LoadPlayers.

AFAIK the only SRL function the DLL would need is LoginPlayer. That's the only thing that handles the password, and NextPlayer just calls LoginPlayer.

Usernames (or just nicks) would be left plaintext in the user file, for proggies, tracking (ie who needs to be reset). The only thing encrypted would be passwords, using an encryption scheme and key known only to the DLL and a ArmyManager program. This way the only time the password is decrypted is in the DLL for LoginPlayer, and in the ArmyManager program for editing players. That program would probably be well obfuscated.

<I had here a few ways to get the passwords, I removed them for security reasons. If this system was implemented, it would only be a matter of time until someone tried to use one of them. They are all harder to code than the current getpage etc, and would be detected in the same way as current methods (looking through the script)(and a little easier to detect, as there would be more code). So basically escalation would put us in the same situation as now, only with more complicated techniques on both sides.>

So with or without this system, the only 100% way to be safe is to look through the open source scripts, and have SRL staff look through the source of DLLs and closed source scripts and then compile and post.

However with the system, it would stop most of the noobier crackers. So is it worth it to create a security system that isn't 100% secure, but is better than the current system? Well, people do it all the time, like microsoft for example. It really depends on how much work, how close it is to 100%, and how much better it is than the current system.

I think it's somewhat needed, and I also think it's somewhat impractical/not worth it. Which one I think more, I'm not sure. But my opinion doesn't matter because I wouldn't be the one to code it anyway :p. Either way it's a good idea.

The easiest solution is that people will click allow only on links they know safe…

The dll has to handle all of the password related actions.. And even if it does, all the scripts would get broken.. But if we want to keep support, the passwords would still kept somewhere in the script. So if you want to do this you need to break all the current scripts.

From: mastaraymond
The dll has to handle all of the password related actions.. And even if it does, all the scripts would get broken.. But if we want to keep support, the passwords would still kept somewhere in the script. So if you want to do this you need to break all the current scripts.

Well….. You could have a variable that has to be in any script called SRLSafe: boolean; and then if it's true, those functions would just call the ones in the DLL and if it's false then that's the fault of the user and the script will still use the old functions.

For your pro point number one - SRL PlayerForm kinda does that (saves players in a file), only one line e.t.c

Otherwise its okay.

I think it's viable, but a little unnecessary regarding the fact that this rarely ever happens here at SRL.

From: NaumanAkhlaQ
For your pro point number one - SRL PlayerForm kinda does that (saves players in a file), only one line e.t.c

Otherwise its okay.

And benefit number 2.

Compatibility isn't really an issue. Both methods can exist at the same time until all old scripts need to be updated for other reasons anyway.

The only issue is that it's an extra security system, not a replacement system. Let's say you had a guard who pats down people before entering a building, to make sure they aren't carrying a weapon. Then you also hire someone with a metal detector and put them at a checkpoint in front of the of the guard's checkpoint. They will catch all the metal guns and knives, and for a while, the guard won't feel any weapons on anyone. But once criminals learn of this metal detector, eventually they will get a weapon made of plastic. They will fool the metal detector, but will get caught when the guard feels the weapon. Even with the metal detector guy, you need the guard anyway. Without the guard, the bad guys would have gotten in. So was it worth it to hire the metal detector guy?

The easiest solution is that people will click allow only on links they know safe…

Also, how many times a year does some script have some pass stealing features?

a) 0.5
b) They anyway manage to steal only shitty accounts because people who have pass stealing shit are shitty scripters and nobody will try shitty scripters' scripts with good accounts.

It's a healthy dose of drama for people as long as it stays as low…

The point is.. You actually need to break all the scripts, make the old system not work any more.. If you can still have scripts where people enter their passwords this whole idea is useless.

Perhaps an option for the person, like an alert "Do you have experience with scripts?"

If they select no, then it does the whole encryption thing. I like the idea, but, it can be unpractical. You would have to give people time to migrate scripts over to the new idea.

Cut em2 it

From: Cut em2 it
Perhaps an option for the person, like an alert "Do you have experience with scripts?"

If they select no, then it does the whole encryption thing. I like the idea, but, it can be unpractical. You would have to give people time to migrate scripts over to the new idea.

Cut em2 it

That really wouldn't make sense.

If someone is about to steal your pass, he just does for i := 0 to high(players) do SendPass(players.pass);

So, if you want to make the whole thing secure.. You need to be sure that every password is declared in an external DLL. This way you cannot get the passwords from a variable.

Please remember that security through obscurity never works, it'll just slow down the evil hacker for some time.

From: Markus
Please remember that security through obscurity never works, it'll just slow down the evil hacker for some time.

WOW. Perfect comment =)