Results 1 to 14 of 14

Thread: Function Proposal, SNextplayer, SLogin, ect

  1. #1
    Join Date
    Dec 2007
    Location
    Somewhere in Idaho
    Posts
    480
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default Function Proposal, SNextplayer, SLogin, ect

    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)

  2. #2
    Join Date
    Sep 2006
    Posts
    5,219
    Mentioned
    4 Post(s)
    Quoted
    1 Post(s)

    Default

    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 . Either way it's a good idea.

  3. #3
    Join Date
    Dec 2006
    Location
    Copy pastin to my C#
    Posts
    3,788
    Mentioned
    8 Post(s)
    Quoted
    29 Post(s)

    Default

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

  4. #4
    Join Date
    May 2006
    Location
    Amsterdam
    Posts
    3,620
    Mentioned
    5 Post(s)
    Quoted
    0 Post(s)

    Default

    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.
    Verrekte Koekwous

  5. #5
    Join Date
    Mar 2008
    Location
    ::1
    Posts
    915
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    Quote Originally Posted by mastaraymond View Post
    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.

    Records and Types Save Code (and make you look better)
    Quote Originally Posted by Wizzup? View Post
    Is it possible to make Runescape a 2D game with this?... That would greatly simplify... Just about anything.

  6. #6
    Join Date
    Mar 2007
    Posts
    4,810
    Mentioned
    3 Post(s)
    Quoted
    3 Post(s)

    Default

    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.

  7. #7
    Join Date
    Mar 2007
    Posts
    1,700
    Mentioned
    0 Post(s)
    Quoted
    8 Post(s)

    Default

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

  8. #8
    Join Date
    Sep 2006
    Posts
    5,219
    Mentioned
    4 Post(s)
    Quoted
    1 Post(s)

    Default

    Quote Originally Posted by NaumanAkhlaQ View Post
    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?

  9. #9
    Join Date
    Dec 2006
    Location
    Copy pastin to my C#
    Posts
    3,788
    Mentioned
    8 Post(s)
    Quoted
    29 Post(s)

    Default

    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...

  10. #10
    Join Date
    May 2006
    Location
    Amsterdam
    Posts
    3,620
    Mentioned
    5 Post(s)
    Quoted
    0 Post(s)

    Default

    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.
    Verrekte Koekwous

  11. #11
    Join Date
    Nov 2007
    Location
    Nowhereville
    Posts
    1,155
    Mentioned
    0 Post(s)
    Quoted
    3 Post(s)

    Default

    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
    Formerly known as Cut em2 it

  12. #12
    Join Date
    May 2006
    Location
    Amsterdam
    Posts
    3,620
    Mentioned
    5 Post(s)
    Quoted
    0 Post(s)

    Default

    Quote Originally Posted by Cut em2 it View Post
    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[i].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.
    Verrekte Koekwous

  13. #13
    Join Date
    Feb 2007
    Location
    Het ademt zwaar en moedeloos vannacht.
    Posts
    7,211
    Mentioned
    26 Post(s)
    Quoted
    72 Post(s)

    Default

    Please remember that security through obscurity never works, it'll just slow down the evil hacker for some time.
    I made a new script, check it out!.

  14. #14
    Join Date
    Jun 2006
    Posts
    1,492
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    Quote Originally Posted by Markus View Post
    Please remember that security through obscurity never works, it'll just slow down the evil hacker for some time.
    WOW. Perfect comment =)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •