Menu
I am developing a PHP-based login system. Each user has an ID(a number) and a password, which is stored as a salted hash.
I am able to figure out if a login is sucessful or not, but now I need to store that information somewhere(so that the user is not permanently logged out).
In the past, I've played with $_SESSION variables. However, these seem to be deleted when the user leaves the browser, which is undesired. Also, I can not "assume" that the user won't try to trick the system, so it has to be safe.
So, here are my questions:
$_SESSION or $_COOKIE? What are the main advantages of each of these approaches?Note that no database security issues are being taken in consideration in this particular question.
Regarding number 3, what I mean exactly is:
I want to keep my website as safe but efficient and user-friendly as possible. If a SessionID-based approach is taken, I'd also appreciate some explanation regarding how to store it in the database.
Thank you in advance
EDIT: Eran's and Brian's answers combined seem to be what I need. Unfortunately, I can only mark one of them as accepted. I'll try to go ahead and implement to see which one was more useful.
602
The result hash from password_hash() is secure because: It uses a strong hashing algorithm. It adds a random salt to prevent rainbow tables and dictionary attacks.
$user = User::where('email', '=', '[email protected]')->first(); Then, you'll need to CHECK the hashed password, like so: Hash::check('INPUT PASSWORD', $user->password); This will return true or false based on whether or not the password matches.
To verify the hashed password: PHP provides an inbuilt function called password_verify to match the hashed password to the original passwords. Parameters: $password: The password that we have hashed using a hashing algorithm. $hash: The hashed password that we are going to verify with the original password.
For this, we will use the password_verify() function. The password_verify() function hashes the given input, matches it with the database, and then gives a boolean output. So, we need to hash the password when someone enters it on the login page and match it with the database to make it work.
For sensitive information (ie, authentication results) use only sessions. Sessions are stored server side and are much less likely to be compromised.
Regarding session lifetime, the default is the lifetime of the browser session - but you can control that. There are several settings that affect that:
session.gc_maxlifetime - effectively controls the lifetime of the session.
session.gc_probability and session.gc_divisor together determine how often session garbage collection will take place.
And last - session.cookie_lifetime controls the lifetime of the session cookie (the cookie that holds the session id so it doesn't have to be tranmistted over the URL). It should match the value of the session.gc_maxlifetime.
Also, never store passwords in sessions or cookies (even in hashed format). Just the results of the authentication.
21
I want to reiterate Eran's point never store the users password or even a hash of the password in session or cookie data.
In general I've implemented the remember me functionality in web apps using Cookies. A good place to start for information on building a "secure" persistent login system is this blog post on the fishbowl. An in-depth answer is already covered in another Stack Overflow answer.
If you need to have ensure that the login is secure you have to use https. This is because cookies or sessions can be stolen if they aren't encrypted.
Another good practice to follow is the 2-level login system. You can see this at sites like Amazon, where you can add things to your cart without logging in but if you want to checkout or edit your account in some fashion you have to enter your password again.
112
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
