15.10.2016, 01:30
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.
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.