authentication script

[Destramic]

hey guys im after a bit of information regarding user authentication please...

 

now I have previously save a users session id in my database after they have logged in so when leaving and coming back to the site im able to compare session id's to get username etc...is this still the way or am I now a little old fashioned?

 

a few more things...do I save information such as username, access level as a session or cookie?...and what is the best way to encrypt passwords please?

 

thank you

 

 

[achieve2lead]

Php password hashing - http://php.net/manual/en/faq.passwords.php

[Jacques1]

now I have previously save a users session id in my database after they have logged in so when leaving and coming back to the site im able to compare session id's to get username etc...is this still the way or am I now a little old fashioned?

 

When was this ever the way? I don't even know what you're doing there.

 

You store the session ID in the database? Why would you do that? Or are you saying you store the entire session in the database with a custom session handler?

 

By default, a PHP session is a file holding data. PHP automatically sets a cookie with a session ID and resumes the session whenever the user presents the cookie. So all you have to do is store the user ID in the session. If you depart from this scheme, what's your reason?

 

In any case, when it comes to sessions, the devil is in the details. There are many mistakes you can make, so if you want to make sure you're doing it correctly, you should post the exact code and preferably also your session configuration (the session.* directives from the php.ini).

 

 

 

a few more things...do I save information such as username, access level as a session or cookie?

 

Storing critical data like the access level is definitely a bad idea.

 

The problem is that the session doesn't get updated when you change the underlying data in your database. For example, if you reduce the access level of a user, they may still run around with the original access level in their session. That's obviously a problem. In the worst case, they can actively prevent your changes from taking effect.

 

So be very careful what you put into the session. In general, you shouldn't abuse the session for caching at all. If you already store the data in your database, simply look it up there.

 

 

 

...and what is the best way to encrypt passwords please?

 

You do not encrypt them at all. You hash them with the bcrypt algorithm. If you already have PHP 5.5, you can use the new Password Hashing API. If you have at least PHP 5.3.7, you can use a compatibility library which offers the same functions. PHP versions before to 5.3.7 have a defect in the low-level hash algorithm and cannot be used.

[Destramic]

well this is why im asking the question...but anyways that was the way I used to do it by using the session id

 

but back on the point about storing the username as a session or possibly as a cookie if the user wishes to be remembered...do I then just select the user in the database via just the username which will then get me his/her credentials like email and access level?

 

I read up about whirlpool hashing which suppose to be the best to encrypt passwords...what do you think?

function getPasswordSalt()
{
    return substr( str_pad( dechex( mt_rand() ), 8, '0',
                                           STR_PAD_LEFT ), -8 );
}

// calculate the hash from a salt and a password
function getPasswordHash( $salt, $password )
{
    echo $salt . ( hash( 'whirlpool', $salt . $password ) );
}

// compare a password to a hash
function comparePassword( $password, $hash )
{
    $salt = substr( $hash, 0, 8 );
    return $hash == getPasswordHash( $salt, $password );
}

// get a new hash for a password
$hash = getPasswordHash( getPasswordSalt(), "hello" );

[Jacques1]

but back on the point about storing the username as a session or possibly as a cookie if the user wishes to be remembered...do I then just select the user in the database via just the username which will then get me his/her credentials like email and access level?

 

You should store the ID of the user, not their name. But apart from that, yes, you fetch the user ID from the session and then use it to look up any data you need in the database.

 

 

 

I read up about whirlpool hashing which suppose to be the best to encrypt passwords...what do you think?

 

I don't know where you've read that and where you've got the code from, but you need to stay away from that place. This is complete and utter nonsense. You should have read our replies instead.

 

First of all, you do not encrypt passwords. You hash them. Maybe you're just confusing the terms, but it's very important that you understand the difference between those two concepts.

 

Encryption is by definition reversible: Given the key, one can turn the ciphertext back into the plaintext. Hashing is not reversible, it merely produces a “checksum” of the input. You can check if a particular string matches the original input by comparing the hashes, but you cannot convert a hash back into the input. The only way to find the original data is to try out different strings until the hashes match (which is called brute-force attack). How hard that is depends on the data and the hash algorithm.

 

Encrypting passwords is an awful idea, because it would allow an attacker to get all plaintext passwords once they've obtained the key. This is an unacceptable and completely unnecessary risk. We do not want to retrieve the passwords, we just want to be able to check them. And this is what a hash is for.

 

However, that doesn't mean you can simply pick any hash algorithm you found somewhere on the Internet. Like I already said above, hashes can be attacked by trying out many different inputs. This is a very real threat in today's world, because anybody with a bit of money has access to massive computing power. For example, even an old graphics card like the GTX 580 can calculate around 100 million Whirlpool hashes per second. It's easy to see that finding an average password is now only a matter of time and money.

 

So forget about Whirlpool and any home-made stuff. You need an actual password hash algorithm which was designed by actual cryptographers. The most important requirement is that it's computationally expensive to make brute-force attacks harder. We also need to be able to tweak the algorithm, because the hardware of tomorrow will be better than the hardware we're currently dealing with.

 

Currently, there are not many options to choose from:

• There's bcrypt. It's fairly strong, well-tested and well-integrated into PHP (see our links above). This is what you should use.
• scrypt is a newer design which is meant to replace bcrypt in the long run. It's rather young at this point, which means there's a bigger risk of undiscovered weaknesses. It's also rather complex and doesn't have a native PHP implementation. Right now, I wouldn't recommend scrypt.
• PBKDF2 is weaker than bcrypt and scrypt. But since it's NIST-approved, people sometimes bring it up (it's not approved for password hashing, though!).

There's actually a big competition for a new password hash algorithm going on right now, so we may see new and better algorithms in the future. But if we assume that it takes 15 years until an algorithm has been tested properly and made its way into all mainstream programming languages, that won't be before the year 2030.

Edited August 10, 2014 by Jacques1

[Destramic]

@jacques1, thank you for your information...that has helped me greatly ...one more thing I want to implement SSL to my site...would I have to put SSL into my auth class or would that be a completely different security that would works along side my auth class?

 

if you know of a good tutorial about this so I can understand more please?...the articles ive read just don't seem to sink in

 

 

thank you again for your help

[Jacques1]

...one more thing I want to implement SSL to my site...would I have to put SSL into my auth class or would that be a completely different security that would works along side my auth class?

 

TLS (or the older SSL) has nothing to do with PHP. This protocol is handled by your webserver before your PHP script is even executed.

 

So this is a system administration task. There are basically 5 steps to do:

1. Learn the basics: How does asymmetric cryptography work? What is a certificate? How does the client connect to the server? etc.
2. Generate an RSA key pair as well as a self-signed certificate for testing.
3. Configure your webserver to offer TLS.
4. Test your configuration with https://www.ssllabs.com/ssltest/.
5. If everything is running properly, generate a new RSA keypair to be used in production. You now need a certificate from a recognized certification authority (GlobalSign, Symtantec, Comodo etc.) so that browser will accept it. Be careful not to waste your money, though. A simple certificate protecting a single domain shouldn't cost more than, say, $25 per year. There's also StartCom which claims to offer certificates for free. However, this should be taken with a grain of salt. When people had to renew their certificates in the course of the “Heartbleed” bug, StartCom wanted them to pay for it.

There are tons of tutorials out there covering the basic webserver configuration. Just search for it. If you're using Apache, for example, the first tutorial that looked reasonable was this one.

 

 

 

if you know of a good tutorial about this so I can understand more please?...the articles ive read just don't seem to sink in

 

Tutorials about what?

Edited August 10, 2014 by Jacques1

[Destramic]

wow well that's some great information...SSL is new to with a lot of other things :/...but im looking forward to playing around with it when I buy my server in the next couple of months...

 

thank you...you help is much appreciated

 

*bookmarked