[RESOLVED] Security in Authentication Scripts

Denholm

Hello everyone,

I'm out to do the same thing as so many others before me, make an authentication script with PHP and MySQL. However, before I dive in, I want to make sure how deep the pool is. So, let's start with the syntax I should use.

Reading in the PHP manual, it seems "mysqli" can be used to connect to MySQL databases and is actually better to use. Please, correct me if I'm wrong. If I am, I guess I'll be reverting to the "mysql" syntax?

Anyways, in making an authentication script, how would I ensure that it remains secure? I've done some reading on the Internet and the most popular methods are to, "sanitize" any user input, to store passwords through MD5 encryption, to store user IPs in the database, to store cookies in the database, and to store sessions in the database (Feel free to correct me on some of this. I'm new at it and probably misused some terms).

Is there anything else that I should be aware of that could help add to the security of an authentication script?

And lastly, are there any other tips on the construction of an authentication script for a first-timer, such as me?

Thank you all in advance, for any advice.

NogDog

A few thoughts:

The choice between mysql or mysqli may depend on what is available on the target host, but if you have a choice mysqli is definitely the preferred extension as far as functionality and future support goes. Or you could go with the PDO extension in order to be less DBMS vendor-specific.

Simply storing IPs in the database will not make the app more secure. If you have problems with a user it might possibly be useful for some sort of tracking info, though with so many dynamic IPs, proxy hosts, and not to mention AOL users who may have a different IP between 2 consecutive page requests, it may be of limited utility.

Since cookies are stored on the user's PC, also storing them in the DB probably has little use.

MD5 is not really encryption, it is "hashing" (sometimes informally called one-way-encryption since it is intended to not be reversible). There are more powerful hashing mechanisms you could use such as [man]sha1[/man] (and you should include a "salt" of some sort with whatever hash you use).

For a non-trivial site (e.g. if monetary transactions will be involved and/or sensitive user data will be stored), you should make use of SSL for your connections (https) to help prevent network sniffing of sensitive data being exchanged between the host and client.

PS: Get yourself a copy of Chris Shifflet's Essential PHP Security.

Denholm

Thank you very much for the information. Yes, if I were ever to setup an E-commerce on my website I will definitely make light of SSL connection encryption. However at the moment I'm simply trying to allow users to upload content and at the same time keep the users, and their data, secure. No, the data being uploaded will not contain sensitive data, however I want to ensure the security of the users, their content, and the website.

Thank you again. Are there any other tips that might be useful to a beginner, such as me?

Denholm

NogDog;10910677 wrote:
A few thoughts:
...MD5 is not really encryption, it is "hashing" (sometimes informally called one-way-encryption since it is intended to not be reversible). There are more powerful hashing mechanisms you could use such as [man]sha1[/man] (and you should include a "salt" of some sort with whatever hash you use)...

Hello again,

I'm wondering if I could get some information on using SHA-1 and then using a, "salt" of some sort. Firstly, when inserting the SHA-1 value into the database, how much room does the SHA-1 key require? The default 32 characters or more? And in regard to the salt, what precisely is the, "salt?" How would I go about constructing then using it?

Thank you again.

NogDog

[man]sha1/man returns a 40-character string of hexadecimal digits.

A salt is additional data prepended and/or appended to the string being hashed with the intention of making it more difficult to discover the original string via the use of library look-up tables. The simplest way is to define some arbitrary string of characters that you will tack on to any string before hashing it.

define('SALT', 'mYrAndoMStrinG');
$name = mysql_real_escape_string(trim($_POST['username']));
$password = trim($_POST['password');
$hashedPassword = sha1($password . SALT);
$sql = "SELECT * FROM users WHERE user_name = '$name' AND `password` = '$hashedPassword'";

laserlight

NogDog wrote:
The simplest way is to define some arbitrary string of characters that you will tack on to any string before hashing it.

Unfortunately, that is also not a very good way since it reduces the amount of work an attacker has to do. The salt should be user specific.

Weedpacket

laserlight wrote:
The salt should be user specific.

The 20-character SHA-1 binary hash of their username, for example (hash it to normalise the length/type).

But why SHA-1? These days it's pretty much in the same condition as MD5 - the differences being that there are more dictionaries for the latter, and while I don't know of any successful collision attacks against the former, they are feasible.

Until SHA-3 is found, I'd recommend something from the SHA-2 family (sha-256, sha-384, sha-512). The [man]hash[/man] function should supply these.

laserlight

Weedpacket wrote:
I don't know of any successful collision attacks against the former, they are feasible.

On the other hand, that SHA-1 is theoretically (in practice now?) broken for collision attacks do not matter here since the attacker is interested in a pre-image attack. Likewise, I think that MD5 is still safe, except that for the problem of being relatively fast to compute.

I believe that the SHA-2 family of hash algorithms take longer to compute than SHA-1, so choosing them over SHA-1 would still be a good idea. If you really want to protect your users' passwords, I suggest reading this article on A Future-Adaptable Password Scheme.

EDIT:
Oh, and you would need to get users to use strong passwords, otherwise the first couple of unlucky sods on the list would have their passwords found out anyway. Then again, if everyone used strong passwords and never reused them, the salt would not even be particularly useful (but a slow hashing algorithm would still be useful).

Back to the original question: it seems to me that for your wish to "to ensure the security of the users, their content, and the website", you can only achieve security for the website, since you are sending the content in the clear (and that would include passwords!). Securing the website would mean securing the server, and if you do not have access to do that... well, the matter is out of your hands. The best you can do with PHP would still leave you open to an attacker.

Denholm

Thank you all, once more, for all the useful information. It certainly comes in handy! I'm taking steps to use suggestions from almost every response here.

Yet another question. I was reading up on the SHA hashing algorithms and it sounded as if SHA-2 and -3 are still in the works. Are you certain SHA-2 can be used with PHP 5.2?

laserlight

Denholm wrote:
Yet another question. I was reading up on the SHA hashing algorithms and it sounded as if SHA-2 and -3 are still in the works. Are you certain SHA-2 can be used with PHP 5.2?

SHA-3 is still in the works, yes, but the SHA-2 family has been around for years. Strictly speaking, whether the SHA-2 family of functions is available to your PHP 5.2.x installation depends on the installation, but it is likely to be available.

Denholm

Thank you for the information. I must have missed it.