[Tutorial] Do it yourself, or not - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP Scripting and Plugins (https://sampforum.blast.hk/forumdisplay.php?fid=8)
+--- Forum: Scripting Help (https://sampforum.blast.hk/forumdisplay.php?fid=12)
+---- Forum: Tutorials (https://sampforum.blast.hk/forumdisplay.php?fid=70)
+---- Thread: [Tutorial] Do it yourself, or not (/showthread.php?tid=566419)

---

Do it yourself, or not - Isolated - 05.03.2015

Introduction

In this tutorial I'm hoping to point out the fundamentals of handling user data. Please note, I will not discuss actually scripting in fact I'd be surprised if I display ANY code at all.

Why? I'm creating this tutorial because I believe that it's important that users understand how and why they should handle users data to ensure their information is secure and safe.

Something which Y_Less proposed a while ago was that users shouldn't be creating their own systems because of a number of factors I somewhat agree but for those who wish to create their own either to learn from, release or use in a productive server, I hope this will be of some help to you.

There are multiple things a developer SHOULD never work on without expecting a number of issues, I'll leave a very good video in the notes for people with interest to view.

I'd like to point out, I'm no expert MAUAHA.

Now, on to the actual tutorial.

Hashing and Salting

Hashing

What is hashing? Hashing should be a 1 way system, meaning that it cannot be reversed. Each methods has it's advantages and disadvantages but you should note that you are somewhat limited within Pawn development.

In this tutorial I'll be referencing mostly Whirlpool.

Whirlpool is a method produced by Vincent Rijmen and Paulo S. L. M. Barreto. Derived from AES Whirlpool has still yet to be recorded as cracked, nor any attack methods found.

Whirlpool produces a 128-bit result and is supported via a plugin for use within Pawn on this very forum. A Whirlpool hash is not backward compatible meaning that you cannot reverse it back to plaintext.

An example:

This hash will always be the same. However, changing even a single character would make the hash look completely different.

That pretty much covers it.

Salting

What is a salt. A salt is randomly generated and saved alongside a users password to add an extra level of security.

A salt is commonly also added to a hash.

Making it even harder to be cracked.

A salt can use a number of different hashing methods.

As stated below, Misiur correctly pointed out the fact that by salting a password and using in conjunction with your hash, it'll render rainbow tables - tables filled with hashes, passwords or other data - useless. Although still not impossible, it'll ensure that a hacker has some serious hard work when attempting to crack user passwords.

User input

In this part I will discuss a couple of aspects, firstly we'll start with Pawn and SA-MP usages and then web based usages.

Pawn / SA-MP

Security exploits within in SA-MP seem to be minimal relative to user input, so as a developer escape user input isn't a huge issue however, still should be looked into.

Web

Now, this is where a lot of issues arise for budding developers. You may have the best user system inside your gamemode and never experienced any issues with it, however converting it to a web application can bring a lot of issues to developers if not done correctly.

So what can we do?

Frameworks - frameworks such as YII or CodeIgniter, links are at the bottom, allow ease of mind to developers by adding a lot of classes and functions that save the developer time and resources, CodeIgniter has introduced Active records which do a lot of the SQL injection protection - that rhymes FYI - for the developer however, it's considered a best practice for the developer to also take extra measures, better safe then sorry right?

Server side security - It's great talking about designing and developing your UCP where you may even mix multiple databases but what is the point if your root login data is default or easy. When testing applications for people - WITH PERMISSION - I've come across a lot of common mistakes, some of these frontend, some backend and some just plain stupid.

$_GET requests I've found to be the aspect people forget about, I can't and won't discuss why and how to find vulnerabilities within a website because I do not encourage the 'scriptkiddy' however, it is always important to sanitize user input, even if, and this is a big if, you ONLY do that. I mean you'd still be in my opinion rather silly, but it's better than nothing.

When discussing security you have a few different things to consider. Firstly, I'd say the most important is what systems you have in place to prevent data loss or unauthorized access. This very forum has a system in place, next time you're at the login page, try enter your login information incorrectly. You'll receive a message saying something similar to: You've used 0 out of 5 login attempts. Why? Brute forcing is an attack method in which the hacker or attacker will use a list of passwords and the attack will go through each password as a guess.

Once again, this is all irrelevant if you don't have the basics in place. When installing MySQL onto a linux based system, insure your run: mysql_secure_installation as a step in the right direction, another good tip is never use root. But create a new user account for MySQL to use.

Plaintext passwords I've been very open minded when writing this tutorial however, if you store your users passwords without ANY hashing involved you are an idiot. I know there are some kiddies out there who'll think having a list of their users passwords in plaintext form is great as they can read through them and 'hack' other services, GREAT!!! Until all your accounts get leaked, in plaintext form, including your own. Then not only do you look like an idiot, but I'm pretty sure your community will die out pretty damn quick (PDQ).

But what if a user forgets? Good question, the safest option is to ensure that accounts are registered with an email address, that then allows you to email a password reset link, then you can decide on the method that suits you best.

DO NOT EVER GIVE OUT THEIR PASSWORD TO THEM. How do you know they are who they say they are? I normally ask them to follow a link and then generate a random password and email them that.

Summary / tl;dr

• Always ensure that you are saving passwords as a hash inside a secure database. (OR FILE)
• Never save a users information as plaintext EVER.
• Research, research and research. Keeping up to date is key.

Credit

Wikipedia - Whirlpool creators

Notes

I'd like to thank each and everyone who has read this topic, and also wish you the best in your projects, if you've noticed a mistake or like to add something please post below and I'll integrate it within this topic.

https://www.youtube.com/watch?v=-5wpm-gesOY a video from Computerphile which was brought to my attention by Y_Less, worth a watch!

https://www.youtube.com/watch?v=ZuTDihlwamg defcom talk on SQL injection and MySQL exploitation.

---

Re: Do it yourself, or not - Misiur - 06.03.2015

Simple yet nice. You could add example of how to properly salt passwords. Also, how salt increases security (renders rainbow tables ineffective), also that it's not so secret (REST sends a digest from client-side, so salt is required to not send plaintext passwords).

---