Beta Release: Sophisticated Banking System
 

I just finished working on a sophisticated banking system. I worked on it solely to release for public use, since I tried to make it as fancy as possible (not graphic wise, since I can't make any graphics >_<). Although this version is complete, I consider it a beta version since I want to implement a few things like a loan system, credit system, and interest system and so forth for possibly a future release, depending on how much time I feel like investing on this thing.

This beta version comes with a custom log in screen for users to log in to access their account information. It also comes with a registration feature for users that have not yet registered an account, which, of course, would be first time users. When inputting a desired account, if your account is less than 10 characters, right under the textbox you will see the text
"Insufficient Characters...," the same applies for when inputting a desired password. With this system, I made it a 10 character requirement for usernames and passwords. When you input the 10 characters for a username, the former "Insufficient Characters..." text will now display whether or not your desired username is available or not. Only one username is allowed per user, and only one account is allowed per user.

Now, the password portion is a bit different, with the fact that I have implemented a password strength checker to check the strength of your desired passwords (credits to Joey for helping me create this). When inputting a password, you will be notified whether it is either a 'weak' password, a 'semi-secure' password, and a 'highly secure' password.


How that works:

If your password only contains numbers, lower case letters, or upper case letters, your password will be considered 'weak'.

If your password only contains numbers and lower case letters or numbers and upper case letters or lower case and upper case letters, your password will be considered 'semi-secure'.

If your password has numbers, lower case letters, and upper case letters, it will be considered strong.


When you've inputted a desired username that is available for use and when you've inputted a desired password, you can press the register button to register your account. After pressing the register button, assuming you inputted the information correctly, you will be prompted with a 'success' gui for registering your account. In this form, you will see some text that you should read and then at the bottom you will see a copy of your username, password, and a personal code. This personal code is essentially very important for you to remember. Each user will have a different personal code. When you go to log in, if the information you type in is not the one you registered with, you will be prompted to a username/password recovery gui that will ask you for your personal code, of which you will have to enter in order for the system to tell you your username and password again. So, I'd suggest you store that number in a place that you wouldn't forget it.

After registering, you can log in, wait for the bank to load, and then you will be prompted with the actual bank gui. Currently, all you can do is view your balance, withdraw, and deposit gralats, which is essentially the basics of a banking system. This system uses player.rupees since I made it for the public, and thus, you'll have to configure it to whatever strings your server uses for money for the system to work correctly for your server.

DB: gambet_bankDB

^This system reads for this DB and simply stores and reads all information stored in this database. Just create a DB with this name and leave it alone, the system itself will do everything.


NOTE: I havn't had anyone to test it for me, so if there are any bugs or so, please let me know and I'll work on fixing them. Also, feel free to fix things around yourself if you wish. This system is for public use, so use it as you please. I didn't exactly implement different error messages for each and every case, so you might get an error message that doesn't apply to what you're trying to do at times, but just take note that what you're doing is in fact wrong, even if the error message displayed is not 100% correct. But, for the most part, I tried to make as many accurate error messages as possible.


NOTE 2: Besides the '/bank' command that you have to chat to fire the weapon, everything else is completely gui-based.



Enjoy :D

opened the script, a lot of fancy stuff...nice nice

Cool

Screenies:

Whoa Gambet this will be really useful to my server and I. Another script that doesn't have to be done. Thanks. :D Goodjob.

No problem, that's what I made it for - for people to use ^^

It's very nice of people to make scripts like this, but the problem with any server that is actually going to go anywhere is that if the server uses too many of these scripts, it will be the same as any other server doing it. (it would look bad if a classic server started using this script, while 10 other UC servers did, etc)

Not at all.


As long as it serves its purpose, what's the problem?


To be honest, I'd rather use this system than some plain purely text-based bank system anyday, no matter how many other servers were using it.


Besides, people don't have to just copy and paste and use the system exactly how I made it. It's easily customizable and can be turned to something fairly unique, though the core of it will still be my system, but at least it won't be completely the same.


But, yes, you do have a point, though I wouldn't agree with people just stopping from releasing scripts to the public.

Mine was made as a modular core. I thought that people may appreciate having the base commands in a player.<bank command> format as it would be useful. Thus you can change a bank style anywhere and yet still have the same useful commands. For instance, a bank in the side of an ogre mountain won't have the same level of customer service as a bank in a city ^^. Try to overdraw in ogreland and you'd probably die :D.

And this system is also a 'modular core', except it's completely gui-based with some nice login/registration features, instead of just the simple bank commands.


You can easily customize this system to work however you'd like it to.

Pretty nice piece of work there. Great job and great to see you have improved since NPulse.

The good, the bad, and the ugly:
I will start with the ugly first, since that translates to security risks! (these HAVE to be fixed in some way or accounted for)

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

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


The good:
Cool concept. Personally, I find typing "deposit 300" a lot easier, and I hate clicking/gui's period, but if someone wants to be wowed instead of efficient, this is the way to go. You get that feel of COOL. This is the type of thing that you cant really bungle down some code with more efficient algorithims, so it seems like you did an okay job.

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.

There were a few things that could have been done SLIGHTLY better/more efficiently, but for the most part the code was pretty good, and definitely better then most. The only thing that really bothered me was the following:

The previous snippet seems silly because we all know characters have asciicodes. (also, you never checked for nonalphanumeric codes, which generally automatically make a password strong).
for example, if(getascii(this.checkletter) in |65,90|) would do uppercase.
I rewrote the password checking part in full. this function takes a password and returns the strength (it adds 1 for Uppercase, Lowercase, a number, and anything else, for a total of 4).

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.

Good example of why i suggested Graal give scripters access to protected variables. Hidden/write protected variables are very handy for NPC's like this.

If you don't like GUI styled bank systems, look up mine (here).
Although i provided a textbased example, you could do Gui-based system and still use the player.<bankcommand> system. Depends on what you like.

Maybe to keep corrupt staff from phishing you could only allow numerical pins of a certain length?

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.

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

Hahaha.

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

Well, using md5 can be good tho

You're right :(

Removed URL due to rule--

Just found it within five or so seconds

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

Not at all.

You can only have one username per Graal account.

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

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

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.


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


Appreciate the feedback, though.

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

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

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.

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.

Yes! I provided a function even!

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

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

^^

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.


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.

:)



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.

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) == "")
:D

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.

Hey, in the end it was your release.




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.

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.

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.


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.

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.

Because you are calling the players idiots instead of doing anything. Revise the script to say *Staff can see your password, so do not choose anything that resembles passwords on other things you own* or something along those lines. Make it loud and clear.

There are things you can do to at least better it, like md5 ;/

You're calling the players idiots as much as I am, only in my case it's explicit and in yours it's implicit.

If someone wanted to go as far as trying to crack a persons password based on something as stupid as a Graal bank password, then what makes you think they wouldn't go to an md5 decryption site that does the work for them?

Sure, it would require an extra step, but if they're willing to do it in the first place, it won't stop them.

There is nothing wrong with being more secure. Of course its still flawed, but it can still be a deterrent. Also, my request for stating that staff can see your password right in the npc, as my last post requested, still stands, not to mention the other safety edit (using player.account serverside instead of letting the client pass what their account name is, since they can change it)

If I ever get back to touching up this system, then sure, but for now, I'll leave it up to whoever decides to use it on their server.

How about instead of a password, the script generates a 5 number long code which is used as a pin? Saves letting the user possibly give out an important password.