Jump to content

Best login method - discussion


Goose

Recommended Posts

I am not really looking for a definitive answer here, but just people's opinions.

 

For the longest time I have written PHP login systems that use cookies to store the login "session". Now, I am wondering if this isn't the best method. What do you guys think? What methods do you use and why?

 

I am assuming people are using some combination of cookies, sessions and/or MySQL. My criteria for login is most importantly, security followed by utility (i.e. can keep a user logged in for longer than their browser is open, or can store other account information).

 

Thanks ahead of time.

 

P.S. If your best choice uses some special implementation I would love to know more details about that.

Link to comment
Share on other sites

i was thinking to add another sesion.

u see..

u create name, password sesion.. include the time to expire.

try put another sesion.. i would say todayWord

 

if todayWord not match to todayWord (on database)... fail the script.. whole script

 

 

Link to comment
Share on other sites

i was thinking to add another sesion.

u see..

u create name, password sesion.. include the time to expire.

try put another sesion.. i would say todayWord

 

if todayWord not match to todayWord (on database)... fail the script.. whole script

 

 

 

Not sure I completely follow what you are saying here, but thanks for your input.

 

Would love more input on the subject.

Link to comment
Share on other sites

Been using sessions for awhile now.

but ya shud read information on session fixation (security)

as the session id is stored as a cookie, it is possible to steal/make id's.

 

So to make it more secure

1) use session_regenerate_id() so cookie id changes

2) do not rely on the session info, use a hash of other various info provided, in my routines I generally use IP & Browser agent info (md5 these two). So if either changed the session becomes invalid.

3) Change The Session life span, (I give 15 minute lifespan for a session cookie).

 

 

I see a lot of folks, who dont understand #2. and see something like

if($_SESSION['loggedin'])

 

when a little more thought ya can secure it with

if($_SESSION['hash'] == md5($ip.$_SERVER["HTTP_USER_AGENT"]))

as I said I use ip & browser agent info :)

 

Anyways

good luck

 

Link to comment
Share on other sites

Been using sessions for awhile now.

but ya shud read information on session fixation (security)

as the session id is stored as a cookie, it is possible to steal/make id's.

 

So to make it more secure

1) use session_regenerate_id() so cookie id changes

2) do not rely on the session info, use a hash of other various info provided, in my routines I generally use IP & Browser agent info (md5 these two). So if either changed the session becomes invalid.

3) Change The Session life span, (I give 15 minute lifespan for a session cookie).

 

 

I see a lot of folks, who dont understand #2. and see something like

if($_SESSION['loggedin'])

 

when a little more thought ya can secure it with

if($_SESSION['hash'] == md5($ip.$_SERVER["HTTP_USER_AGENT"]))

as I said I use ip & browser agent info :)

 

Anyways

good luck

 

 

Great information. I hope some more people post their thoughts.

Link to comment
Share on other sites

It should be noted that using the Browser and IP address as a secure login method can be insecure.

 

Both of these items can be faked, but also, some people use shared IP's (AOL users) which means they would not be able to access your system.

 

Using session_regenerate_id() often is a good practise. If someone does get hold of a users session id, by the time they use it, it would have changed and become invalid.

 

Using SSL, especially when login information is being sent is vital to any secure system.

Link to comment
Share on other sites

It should be noted that using the Browser and IP address as a secure login method can be insecure.

 

Both of these items can be faked, but also, some people use shared IP's (AOL users) which means they would not be able to access your system.

 

Using session_regenerate_id() often is a good practise. If someone does get hold of a users session id, by the time they use it, it would have changed and become invalid.

 

Using SSL, especially when login information is being sent is vital to any secure system.

 

Cool, well that is all great information. I will try using sessions instead. If anyone can point me to a good tutorial (I haven't looked yet, but will do the regulars (check php freaks and google)), that would be awesome.

 

Thanks again all.

Link to comment
Share on other sites

Hi

 

In addition to the above, one thing I have done is stored the session id in a column in the users table. I then have a column of when they last did anything, and update this whenever they invoke a script, but only where the time is later than now minus X minutes. If the number of records updated is not 1 then just redirect them to the login page.

 

Advantage of this is that you can easily boot people off the system by setting the last time they touched anything to null.

 

All the best

 

Keith

Link to comment
Share on other sites

Tbh, I find cookies better. They last longer, and I find them to be very secure, if you use them logically.

 

For example, for my login I set two cookies, the user's username, and their ID as an encrypted string.

 

Then, every page that requires them to be logged in, a check occurs which makes sure their username and ID match the database.

 

I haven't been hacked at all, I find it to be pretty secure :)

Link to comment
Share on other sites

Problem with cookies i find is that users can turn them off and not except any. Therefore no cookies can be set. So maybe a combination of sessions and cookies.

 

I personally use sessions and make sure any communications between the user and server is encrypted.

Link to comment
Share on other sites

Yeah I suppose...but I have a "friendly" ;) message that's displayed if people try to login and don't accept cookies.

 

Tbh, they can easily allow an acception to sites they trust.

 

Idk, you could use sessions and have the session ID in the url, but that's so impractical and untidy...

Link to comment
Share on other sites

What I've been doing lately for logins is I have a separate table for logged in users (id (auto increment) | uniqueID | userID ) and create a unique id for them. Salt + username (or anything related to the user) and md5, sha1, strrev, uniqid any of them or a combination just to mix it up from a straight up md5. Then in their session, I create a variable for a current timestamp, and update the timestamp if they are active throughout the site. If the timestamp is over some time (5, 10 mins...) I check that with the cookie / database to make sure it is the same user.

 

What do you guys think about that method? It is definitely a lot more secure then i used to use. Any suggestions about the method i use?

Link to comment
Share on other sites

I

I think hashing data multiple times is a good idea; makes it near impossible for people to guess your encryption algorythm.

 

However, does this cause a noticeable difference in page load times at all?

 

I really don't notice a difference in the page load times. Granted I'm starting the hash on login, and when i check the login after x minutes. I'm not checking it on every page refresh.  With adding a salt to the hash, it is definitely near impossible to figure out the encryption method.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.