[Tutorial] Short: Security around passwords - 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] Short: Security around passwords (/showthread.php?tid=619182)

---

Short: Security around passwords - Alcatrik - 15.10.2016

Hi all,

So having seen a couple of gamemodes and a couple of threads I noticed two really quite serious problems: many do not hash user passwords at all, and almost none salt the password.

So - a quick glossary:

Cleartext: The password the user has provided - for example sampiscool3264128.
Hash: The output provided by a hashing algorithm - such as MD5, SHA2, whirlpool, etc, when a password is fed into it. For example, 5be4f1603f9d0c0a8750ae530a2b9d3d.
Salt: A random selection of characters/letters appended or prepended to the password before it is fed into the hashing algorithm. For example, $1n*lMxN.


Why should you hash passwords?

If you store passwords in cleartext then this means that if you were to open your database - whether it's .ini files or a SQL server - you can see exactly what the user typed in to set as their password.

The main problem with this - besides the fact that it's ethically wrong to be peaking at your player's passwords - is that databases get hacked/leaked all the time.

What this means is that if anybody ever gets a hold of your database - whether that's a hacker attacking your server specifically, an opportunist who gains access through alternative means or a rogue member of staff - not only is your server rendered insecure (because they have the passwords of every administrator), but the vast (stupid) majority tend to reuse passwords for anything and everything - including online banking. Not only do you owe your users an ethical duty of care to keep their data safe and secure, there are good odds that - likely to be enforced or not - you are legally required to.

If you think you are safe just because you have no enemies - think again: there is a whole dark industry built around this practice - the keyword above is online banking; something cyber-criminals dearly want to access. There are good odds the person attacking you has never heard of SA-MP, you, heck there are good odds that on the other end of the attack is simply a computer running a script designed to scan the internet for victims.

If hashing is one way, how do I check to see if they've entered the right password?
This has a fairly elegant solution. Simply hash the user's input and strcmp the two: MD5("abc") == MD5(inputtext) where inputtext is also "abc", but not when inputtext is "def".



What is salting and why should you do it?

Salting is the process of generating a random string - for example $a12(m, and either prepending or appending it to the user's password before you hash it. For example, if you were to take "sampiscool3264128" as the password the user has provided, you should programmatically generate a random string at least 4 characters long and you should either strcat it to the start or the end of the string before you feed it to your hashing algorithm (whether it's MD5, SHA2, whirlpool, etc).

But why?

Simple: while bruteforcing (the process of iterating through every possible combination of characters) is slow, there are several services dedicated to building a database of password-hash combinations and have been doing so for years; for example, if the user's password is "dog", then it almost certainly appears in one of these databases and pulling up its value is as simple as pasting the hash into one of the many sites dedicated to hosting these databases.

However, the more complex the password (length being the greatest contributor) the harder it is to compute and the less likely it is to appear on any of these databases. The password "dog" is expected to take around 0.0000004 seconds to crack, for example, whereas if we were to prefix the password with our salt "$1n*lMxN", so that we are actually hashing "$1n*lMxNdog", it would take four hundred years to crack (ignoring a scenario where they build a bruteforce app SPECIFICALLY built to crack your database - which seems unlikely and highlights why users should also exercise proper password hygiene so that even without salting there is a great deal of entropy to their passwords.)

In conclusion, while this introduces a couple of small technical challenges, you not only owe it to your users to do everything you can to keep their data secure and safe, but you likely (as unlikely as they are to be enforced) have legal obligations to as well.

---

Re: Short: Security around passwords - BurnZ - 15.10.2016

It's funny why people still use MD5 hashing algorithm, since it is so damn easy to crack. (Take CNRSF servers for example.)

Although some people use special characters that cannot be cracked, most people do not.

Also, this isn't exactly a tutorial. This would fit better in the General section.

Anyway, good job!

+REP

---

Re: Short: Security around passwords - Gotham - 16.10.2016

Nicely explained Well done

---

Re: Short: Security around passwords - Spmn - 16.10.2016

It's still better to use md5 + salt than using whirlpool/udb/sha/any other algorithm with no salt at all.

---

Re: Short: Security around passwords - BurnZ - 16.10.2016

Thing is... most people don't salt their passwords

---

Re: Short: Security around passwords - Jayse - 16.10.2016

Nice tutorial. I've seen people using weird hashing algorithms made by them. I -myself- always use built-in SHA 256 hashing algorithm since I don't like plugins like whirlpool that eats much ram. There is a good tutorial about it if someone is interested.

---

Re: Short: Security around passwords - AmigaBlizzard - 16.10.2016

If the server owner doesn't hash passwords and saves them in the database unhashed, are hackers able to just read the password?
If yes, why would they bother to find your password to log into your account and change data?
They have direct access to your database and if they can see the unhashed password, they can also see the other data and change it without even logging in.

Even when the passwords are hashed and they need to brute-force decode the password to see which password would match "drg8512gsgdrg5dr6sa4f8" (hashed password, which they took from your database), what would they need it for?
They can see the hashed password so they can see the data as well, which usually isn't encoded in any way (money, score, kills, ...).

---

Re: Short: Security around passwords - BurnZ - 17.10.2016

Server owners want to see their player's password so that they can use their account on anither server.

---

Re: Short: Security around passwords - SickAttack - 17.10.2016

What the heck are you talking about

-----------------

A salt just makes your password longer, so it's harder to get the plain text from the hash.

---

Re: Short: Security around passwords - Alcatrik - 18.10.2016

The vast, vast majority of people reuse passwords (even if they shouldn't) - meaning that there are good odds that the majority of the passwords you have stored in cleartext are probably the passwords to your user's email accounts, their social media, their Steam accounts, their banking details, etc.

This is why sites like https://haveibeenpwned.com exist and is one of the three main technical vectors I can think of for someone stealing your account; the other two being flat out bruteforcing/dictionary attacking or a keylogger.

Bruteforcing/dictionary attacking can be pretty much eliminated via the user either providing a decent password, or by the script enforcing maximum login attempts and only reporting "invalid credentials" when user/pass is wrong rather than specifying that the password is wrong (which confirms to the attacker that the username is correct and halves the challenge).

Keylogging is a lot harder to defend against - but it's typically challenged via two-factor authentication, or for example requiring the 3rd, 8th, and 11th characters from your password (which most banks now do). I'm considering on making the most senior admins on my server use two factor authentication to login, for example.

To add to SickAttack's message, salting the password not only increases the password length (which is, fundamentally, is the best tool for secure passwords), but it also ensures symbols/capitals/numbers are being used (which further increases entropy because instead of guessing between a selection of 26 characters you are guessing between a selection of close to 100), and finally in the case where the user uses a dictionary word it somewhat mitigates the issue through not making it a dictionary word (though this is still a terrible idea - as anyone who's technically equipped and really wants to get in can just adapt their attack vector to prepend the salt).

---