Beta Release: Sophisticated Banking System

[Kristi]

Originally Posted by Chandler

MD5 secret flags. That's how I coded V$:C's user account system.

any corrupt staff could still insert a way to intercept the variable before its encrypted moment. Napo's idea is a good one.

[Chandler]

Originally Posted by Kristi

any corrupt staff could still insert a way to intercept the variable before its encrypted moment. Napo's idea is a good one.

That's true. However, a staff member could still find a way to avoid it I suppose. Although, you wouldn't allow a corrupt staff member on the force now, would you!

[Kristi]

Originally Posted by Chandler

That's true. However, a staff member could still find a way to avoid it I suppose. Although, you wouldn't allow a corrupt staff member on the force now, would you!

We are talking about a nonpaid workforce often comprised of minors...

[Chandler]

Originally Posted by Kristi

We are talking about a nonpaid workforce often comprised of minors...

Hahaha.

[Chompy]

Wait, there are some websites that allow you to encrypt and unecrypt md5 hash.. :O

Well, using md5 can be good tho

[Chandler]

You're right

Removed URL due to rule--

Just found it within five or so seconds

[Chompy]

Originally Posted by Chandler

You're right

http://gdataonline.com/seekhash.php

Just found it within five or so seconds

Don't just external links :o
btw, sites like that

[Gambet]

Originally Posted by Kristi

The ugly:
This npc is on a one way abuse ticket. You are giving the entire server access to fill up an npc with as much information as they want (the user accounts), without any visual checks or etc. I would limit the amount of bank accounts the player can be associated with, or at least set up some type of check (like how most places now use an image check when registering so it cant be automated.)
If you do not do this, someone can automate a way to just sit there and create accounts all day, and going unchecked, this could be a really really bad thing (filling the server!).

Not at all.

You can only have one username per Graal account.

Originally Posted by Kristi

Any staff who has access to looking at that DB's flag could know the user's passwords! What if they use a password they use other places on the internet, like aim or email, or even worse... use their graal passwords! You know someone is going to do it, then some corrupt staff can go look for a random 8 character password! I would suggest using MD5 encryption on the serverside. However, the problem still lies with staff pretty much having access to scripts period. They could easily script something that intercepts that password on the clientside or serverside before it is encryped and compared in the first place. Variables on clientside are accessable no matter what way they are stored in a weapon. This can be very dangerous...

That doesn't really matter because of the fact that I made it a 10 character limit and I even added a password strength checker.

I don't know about you, but I find it hard to believe that people would use 10 character passwords for things such as emails and so forth.

Besides, why would you use the same password for your personal information on a registration NPC on Graal?

I don't know about you, but I wouldn't be bothered with having a 10 character password for every site I have to register with. Not to mention it's quite easy to give -r to the DB NPC so that no one except the Manager or so can access it (assuming that right doesn't allow you to access it even via script).

Originally Posted by Kristi

The bad:
You should break up these really long functions into smaller task functions with parameters, for more readable code. also, i see you use onBlahBlah for nonevent functions, when you write your own function, you dont need to do that. function blahBlah is fine. also, you dont need to put temp. in a parameter list. Anything in the parameter list is automatically temporary. EG:
function whatEvs(coolname).
coolname is automatically temporary, so you can refer to it as coolname or temp.coolname inside the funciton.

I don't really understand what you mean by this.

Originally Posted by Kristi

Password stuff

This was the only part of the script I did not fully make, the password strength checker. As I stated in my first post, Joey helped me with this part.

Are there better ways to do it? Most of the time there are always better ways of doing something, mostly due to the type of habits that certain scripters have, where they prefer one method over the other and so forth.

This system isn't perfect, but it's a 'core' system that can be tampered with to be made even greater to fit any server, really.

Originally Posted by Kristi

Sorry if any of this was offensive, but the security issues (the ugly) have to be addressed most of all. Anything else is just preference/efficiency.

No, it wasn't offensive at all, only that the issues weren't really issues.


Appreciate the feedback, though.

[Draenin]

From the results you've shown in the screens, it is impressive.

[Kristi]

Originally Posted by Gambet

Not at all.

You can only have one username per Graal account.

Really? All i see on the serverside is this. Doesn't seem to check if the player account already has a bank account. If its on the clientside then youre screwed anyway because someone can always screw with clientside scripts and just trigger the server. This means they could still endlessly flood the database.

PHP Code:

 else if (params[0] == "Register")
   {
    if (gambet_bankDB.(@params[1]) == "")
     {
      if (gambet_bankDB.counter == "") 
       { 
         gambet_bankDB.counter = 1;
       } else 
        {
          gambet_bankDB.counter+=1;
        }
       gambet_bankDB.(@params[1]) = {params[2],params[3],gambet_bankDB.counter,0};
       gambet_bankDB.usernames_used.add(params[2]);
       this.success = "true";
     } else
      {
        this.success = "failed";
      }
    player.triggerclient(name,"Registered",params[2],params[3],gambet_bankDB.counter,this.success);
   } 


Originally Posted by Gambet

That doesn't really matter because of the fact that I made it a 10 character limit and I even added a password strength checker.

I don't know about you, but I find it hard to believe that people would use 10 character passwords for things such as emails and so forth.

Besides, why would you use the same password for your personal information on a registration NPC on Graal?

I overlooked the password length check. That keeps people from using their graal password, so its a good start. However, even if its not an IDENTICAL password, that ten char password could lead to hints of what they use as passwords elseware. like "hey, i always use butter as my password, so ill use Butter1984 here." someone who can see this can still with a few tricks and turns still crack a password they use elseware. Its still a risk.

Originally Posted by Gambet

I don't know about you, but I wouldn't be bothered with having a 10 character password for every site I have to register with. Not to mention it's quite easy to give -r to the DB NPC so that no one except the Manager or so can access it (assuming that right doesn't allow you to access it even via script).

Like i said, you dont even need access to it, or even the clientside weapon. You can construct another weapon to add to their account that reads the string in other weapons. its very possible. its still a risk, and one you cant avoid.

Originally Posted by Gambet

I don't really understand what you mean by this.

You have one big long function serverside. Its good practice to break it up into tasks.
You had things like function onCheckWhatever(temp.stuff,temp.that). On just denotes an event (like onPlayerEnters). you dont need on in your custom declared functions. Also, you dont have to put temp. in the function declaration, they are temp. by default. CheckWhatever(stuff,that) is sufficient. inside that function you can access it as stuff or temp.stuff.

Originally Posted by Gambet

This was the only part of the script I did not fully make, the password strength checker. As I stated in my first post, Joey helped me with this part.

Are there better ways to do it? Most of the time there are always better ways of doing something, mostly due to the type of habits that certain scripters have, where they prefer one method over the other and so forth.

Yes! I provided a function even!

Originally Posted by Gambet

This system isn't perfect, but it's a 'core' system that can be tampered with to be made even greater to fit any server, really.

No one expects things to be perfect, however, its a security risk. I cannot just say thats okay.

[Gambet]

Originally Posted by Kristi

Really? All i see on the serverside is this. Doesn't seem to check if the player account already has a bank account. If its on the clientside then youre screwed anyway because someone can always screw with clientside scripts and just trigger the server. This means they could still endlessly flood the database.

I'm going to assume you overlooked this part, then:

PHP Code:

if (gambet_bankDB.(@params[1]) == "") 


Originally Posted by Kristi

I overlooked the password length check. That keeps people from using their graal password, so its a good start. However, even if its not an IDENTICAL password, that ten char password could lead to hints of what they use as passwords elseware. like "hey, i always use butter as my password, so ill use Butter1984 here." someone who can see this can still with a few tricks and turns still crack a password they use elseware. Its still a risk.

I guess, but I can't exactly make up for the stupidity of some of the users. No matter how much thought you give into it, there will always be a skilled scripter that can find out the information anyways.

I don't exactly see a fullproof way of doing it.

Originally Posted by Kristi

You have one big long function serverside. Its good practice to break it up into tasks.
You had things like function onCheckWhatever(temp.stuff,temp.that). On just denotes an event (like onPlayerEnters). you dont need on in your custom declared functions. Also, you dont have to put temp. in the function declaration, they are temp. by default. CheckWhatever(stuff,that) is sufficient. inside that function you can access it as stuff or temp.stuff.

That onCheckWhatever part was created by Joey.

If you look at the rest of the script, I didn't do such in my custom functions.

Originally Posted by Kristi

No one expects things to be perfect, however, its a security risk. I cannot just say thats okay.

Wouldn't be a risk if the players would use some logic.

Though, I still don't know of a fullproof way of doing it, because there will always be methods of finding the password data.

[Kristi]

Originally Posted by Gambet

I'm going to assume you overlooked this part, then:
if (gambet_bankDB.(@params[1]) == "")

params[1] can be anything the client passes it, for example, sadgkhssdfsdkjlj! So its still exploitable to keep filling your database, even claiming bank accounts for other peoples graal accounts BEFORE they do :O.
if(gambet_bankDB.(@player.account) == "")

Originally Posted by Gambet

I guess, but I can't exactly make up for the stupidity of some of the users. No matter how much thought you give into it, there will always be a skilled scripter that can find out the information anyways.

I don't exactly see a fullproof way of doing it.

Then just DONT do it! Graal, as of now, has no safe way to protect data in a client. Why even present a risk you KNOW is there. Do you plan on telling the players its POSSIBLE a rouge staff could get their password if they wanted to? How would they feel about it? You cannot just let them believe its safe.
I don't ever make my passwords the same theme, but MOST people do.

Originally Posted by Gambet

That onCheckWhatever part was created by Joey.

If you look at the rest of the script, I didn't do such in my custom functions.

Hey, in the end it was your release.

Originally Posted by Gambet

Wouldn't be a risk if the players would use some logic.

Though, I still don't know of a fullproof way of doing it, because there will always be methods of finding the password data.

You cannot assume all (even most) players are logical. It is your job to protect such data if you are going to ask for it, and honestly, with what is available to graal, you can't.

[Gambet]

Originally Posted by Kristi

Then just DONT do it! Graal, as of now, has no safe way to protect data in a client. Why even present a risk you KNOW is there. Do you plan on telling the players its POSSIBLE a rouge staff could get their password if they wanted to? How would they feel about it? You cannot just let them believe its safe.
I don't ever make my passwords the same theme, but MOST people do.

It doesn't really matter if anyone sees what password you put as your password for your Graal bank account unless they feel like assuming you use that same password for other things and bother checking into it, which is an unlikely situation if you have trustworthy staff.

Hell, anyone could easily send a keylogger over to another person to steal their information if they wanted to. You think most Graalians could even bother to learn about anti-virus protection? And even with that there are ways to bypass detection.

Originally Posted by Kristi

Hey, in the end it was your release.

Yes, but you make it sound like it was done for each custom function.

It's not really a big deal, it's easily fixable.

Originally Posted by Kristi

You cannot assume all (even most) players are logical. It is your job to protect such data if you are going to ask for it, and honestly, with what is available to graal, you can't.

That's no excuse not to have such systems.

If the player knows it's possible for staff to see their password and they still choose to use a similar password as those that they use on other sites, then I'm sorry to say this, but they deserve to get their accounts hijacked for being such imbeciles.

[Kristi]

Originally Posted by Gambet

If the player knows it's possible for staff to see their password and they still choose to use a similar password as those that they use on other sites, then I'm sorry to say this, but they deserve to get their accounts hijacked for being such imbeciles.

IF a player knows, which is a pretty big assumption, wouldn't you say? They deserve to be protected. Using a common theme password is common amongst MOST people. Usually bad actions are a result of tensions, like, lets say a staff member hates a player, then hes like OH i want to RUIN HIS LIFE BY STEALING HIS EMAIL. So then he intercepts his bank password for clues on how he formulates his passwords, and gets to random cracking attempts. He is now more equipped to do so then before, thus making the poor player have a disadvanteous position due to this script. Just saying your players are "Imbesiles" and therefore deserve to be open to this risk is a horrible thing to say, and bad service as staff! You seem to be unaware how many people would assume their information is safe and trust the server they love, and here you are saying its their fault if they use something wrong. At least inform them that staff can see these passwords.

[Gambet]

Originally Posted by Kristi

IF a player knows, which is a pretty big assumption, wouldn't you say? They deserve to be protected. Using a common theme password is common amongst MOST people. Usually bad actions are a result of tensions, like, lets say a staff member hates a player, then hes like OH i want to RUIN HIS LIFE BY STEALING HIS EMAIL. So then he intercepts his bank password for clues on how he formulates his passwords, and gets to random cracking attempts. He is now more equipped to do so then before, thus making the poor player have a disadvanteous position due to this script. Just saying your players are "Imbesiles" and therefore deserve to be open to this risk is a horrible thing to say, and bad service as staff! You seem to be unaware how many people would assume their information is safe and trust the server they love, and here you are saying its their fault if they use something wrong. At least inform them that staff can see these passwords.

If they use the script then they should know how it works, thus they can go about securing it as they wish.


If I based my systems on the level of intelligence of the average Graalian, I'd probably make everything text based, requiring absolutely no information to be given from the player, mostly due to the fact that players don't even read long descriptions and so forth.


Hell, if they do get hijacked they can take it as a learning experience. The warnings have been laid out, it's the users responsibility to heed the warnings and intelligently create a password that would have little to do with their actual passwords that they use for other things.


You base your arguments assuming that the players will use similar passwords to those they use on other sites, and then you go on to assume that your staff will try to hijack email accounts and so forth with this information, which is going way out of the limb, though yes, it may be possible in some instances, but nobody is going to check each and every password for each and every player's email accounts to see which one is a match.

It's always nice to give way to all possibilities, but when there's no way of securing the information, all you can do is give out warnings and hope the players heed to them.

I'd understand you arguing if there were currently a way to secure the passwords, but since there isn't, I don't really see why we need to continue going back and forth.

I understand the risks, thus you're talking to the wrong person. If I could secure the password system, I would.