Question about login page

[hno]

Hi

 

Is it a good idea to save the user password by cookie in client?If so how can encrypt it ?And if not, so what is your suggestion?

 

tnx

 

[ialsoagree]

I do it, my site doesn't require very high security though, which is one reason I'm comfortable letting the client store the password.

 

Mind you, I ONLY do this for saving logins. To verify sessions I keep the IP, session ID, and user ID in a database, the two (IP and session) have to match up on every subsequent page load or the session is erased on the client side and an access log violation is made.

 

I md5 the password with a prefix.

 

<?php
$password = md5('something');
$prefix = 'something_else_';
$password_to_store = md5($prefix.$password);
?>

 

Assuming you store your passwords md5'ed, just follow through with the stored password and compare:

 

<?php
$password_from_database = md5($prefix.$password_from_database);
if ($password_from_database === $password_to_store) {
   // Matching passwords
}
else {
   // They don't match
}
?>

[trq]

Why would you ever need to store a users password in a cookie? Makes no sense.

 

I store a unique identifier (not the users username) in any cookie. And also next to there username in the database. I then use that identifier to identify the user and log them in, destroying (and then optionaly regenerating if need be) the cookie and identifier if need be.

[ialsoagree]

Why would you ever need to store a users password in a cookie? Makes no sense.

 

I store a unique identifier (not the users username) in any cookie. And also next to there username in the database. I then use that identifier to identify the user and log them in, destroying (and then optionaly regenerating if need be) the cookie and identifier if need be.

 

I do it because, as I pointed out, there's no need for that level of security on my site. The extra overhead of an additional column and generating new unique identifiers (which will be sent with every HTTP header even if they are only used to log the user in after the 1st request) are as easily hijacked as a password.

 

Further, there's no way anyone will be able to reverse engineer a double md5'ed password that has been prefixed, so there's no threat of the password being exposed.

[revraz]

But there is also no good reason to store it in a cookie, regardless of your level of security.

 

Why would you ever need to store a users password in a cookie? Makes no sense.

 

I store a unique identifier (not the users username) in any cookie. And also next to there username in the database. I then use that identifier to identify the user and log them in, destroying (and then optionaly regenerating if need be) the cookie and identifier if need be.

 

I do it because, as I pointed out, there's no need for that level of security on my site. The extra overhead of an additional column and generating new unique identifiers (which will be sent with every HTTP header even if they are only used to log the user in after the 1st request) are as easily hijacked as a password.

 

Further, there's no way anyone will be able to reverse engineer a double md5'ed password that has been prefixed, so there's no threat of the password being exposed.

[hno]

I do it, my site doesn't require very high security though, which is one reason I'm comfortable letting the client store the password.

 

Mind you, I ONLY do this for saving logins. To verify sessions I keep the IP, session ID, and user ID in a database, the two (IP and session) have to match up on every subsequent page load or the session is erased on the client side and an access log violation is made.

 

I md5 the password with a prefix.

 

<?php
$password = md5('something');
$prefix = 'something_else_';
$password_to_store = md5($prefix.$password);
?>

 

Assuming you store your passwords md5'ed, just follow through with the stored password and compare:

 

<?php
$password_from_database = md5($prefix.$password_from_database);
if ($password_from_database === $password_to_store) {
   // Matching passwords
}
else {
   // They don't match
}
?>

 

Thanks all for their replies

ialsoagree ,But if the ip change for the next time, i think it makes problem.Is it true?

 

 

[ialsoagree]

IP's for the most part will not change between page loads, but there is a solution for users of accounts like AOL (that often times WILL have some amount of IP change even during a single session).

 

I got the solution from phpBB although it's pretty intuitive. Simply save the first 3 sections of the IP in the database:

xxx.xxx.xxx

 

When you get the user's IP at the beginning of each session, shrink it to 3 sections and compare it with the IP in the database. The chances of it denying a valid user are pretty slim. Your users will certainly let you know if there's a problem.

 

But there is also no good reason to store it in a cookie, regardless of your level of security.

 

I don't see how it makes much difference myself.

 

You talk about a unique identifier as though it's significantly more secure. We both agree that you need something other than a username to verify a save login, otherwise people would just make a cookie with anyone's username.

 

Your unique identifier is nearly as easy to intercept as my md5ed password. Yours changes (occasionally, unless you change it on every page load) so it's a little harder, but not significantly.

 

And as I pointed out, there's no way someone is going to find someone's password after it's been md5ed, prefixed, and md5ed again so passwords getting stolen is a non-issue.

 

In the end, the only issue is that I don't change the identifier after a saved login attempt, and you do. As I've pointed out, there's no need for such overhead on the site I'm using, it's unnecessary information to store and update. If you think the site insecure, please feel free to try to hijack a login cookie, I'll even give you site address when it's out of beta.