Implementing a "Remember Me" system

[Fmdpa]

I just finished a login system, but now I'm trying to make a "remember me" system, so the user doesn't have to login each time he visits. I've visited sites that store the login info in a cookie in plain text, but that obviously is not what I'm going to do. Would it be bad to store the password in the cookie with the same hash and salt as the version in the database?

[boen_robot]

No need to store the password. Just store the session ID. The session ID itself is stored as a cookie. You can make the cookie expire at a more distant point in the future, therefore keeping the user logged in for a longer time, and effectively remembering them. Detecting someone as being "online" or not (assuming you want that for the sake of other features) will be a matter of tracking the last access time of each session ID, relative to the current time.

[[dx]]

Why not? Only you can see that record in cookie.. And there's no way to unhash it, so if other has your password with hash, they don't have anything of it.

[boen_robot]

Why not? Only you can see that record in cookie..

You and any program on the PC (even without your knowledge), and if no HTTPS is involved - everyone in your local network with a traffic capturing program too.

And there's no way to unhash it, so if other has your password with hash, they don't have anything of it.

If the hash is the thing you're checking, the hash is the thing an attacker needs to know. And as long as an attacker can impersonate you, they can do whatever they want on your behalf, including changing your password so that you can't enter.

[justsomeguy]

Session cookies are temporary, even if you save the session ID by the time they go back the server won't have that session any more. Most systems with a "remember me" checkbox only save the username, not the password. The browser can save the passwords itself.

[[dx]]

So let's say we are makeing admin cpanel.And we need some data which checks if you are really administrator.If we store ID, username and password (hash) in cookie, script can explode cookie and we can compare data from it.But if we store just username, how to protect from someone other..What would you do to make more secure?

[justsomeguy]

Use a session, not a cookie. It's a terrible idea to store authentication and authorization data in a cookie or any other user-submitted information. Keep it in the session.

[birbal]

i made a remember me. its store a hash string depend upon variable data (eg ip time). and when remember checkbox is true it stores it in db. next time when user comes if there is right cookie it redirects user. it is working but though not sure it is the right way or not. or it is totaly secure or not. (need some guide too)

The browser can save the passwords itself.

if i am not missunderstandingbut to do that user have to accept password save. otherwise it will not work...is not it?[hope this post will not considered as topic hijack]

[Fmdpa]

How can I tie the SESSID cookie in with their account to ensure that it is really a valid user? I thought the session automatically ended when the browser was closed, or does the PHPSESSID cookie last longer? Also, I was wondering if there's a way to do this: SELECT * FROM userdb WHERE hash_pswd(password) = $_COOKIE['autologin']Basically, I just want to select manipulated data from the database. Is there a way to do this?

[justsomeguy]

it is working but though not sure it is the right way or not. or it is totaly secure or not. (need some guide too)

There's no security there, an attacker still needs to know only a single value to log in as that user.

I thought the session automatically ended when the browser was closed

That's right.

Also, I was wondering if there's a way to do this: SELECT * FROM userdb WHERE hash_pswd(password) = $_COOKIE['autologin']

Of course you can do that. Is it secure in any way? Of course not.Even with "remember me", they still need to type their password in when they get there. The only thing saved in a non-session cookie would be their username. So, they show up on the page and it fills their username in, and they type their password and log in. After that, you're storing their log in information in the session. The next time they come back the same thing happens, their username gets filled in and they enter their password.Web browsers have their own way to save passwords in a fairly secure way. When you log in your web browser probably asks if you want to save the password. That's how people save passwords. If you're trying to replicate that behavior with cookies or something else then you're just asking an attacker to compromise your users.

[Fmdpa]

its store a hash string depend upon variable data (eg ip time). and when remember checkbox is true it stores it in db. next time when user comes if there is right cookie it redirects user.

I did something like that so non-users can edit their comments. The only problem is that it will not work with dial-up users who's IP changes each time they connect (even though they are in the minority).

[justsomeguy]

The only problem is that it will not work with dial-up users who's IP changes each time they connect (even though they are in the minority).

It will also work too well for public computers, like in a library or cafe. Anyone using the computer can edit anything else created on that computer, even not by them. You don't want to identify computers, you want to identify people. That's why we need passwords.

[Fmdpa]

Ok, JSG, I think you're answering a different question. I want to automatically login, completely bypassing the form, if, of course, the cookie is set with valid information. I want to make them be logged in for weeks at a time (or until they clear their cache). Are you saying that it isn't secure to do it that way? Also, I extend the session using the ini_set session.gc_maxlifetime directive, correct?

[birbal]

There's no security there, an attacker still needs to know only a single value to log in as that user.

is there any way to delete the hashed string in db after certain amount of time?i mean if a remember me feature works for suppose 5 days. then the store hash in db will be deleted after 5 days. so after 5 days if hashed string in cookie get compromised then noone can get login to that a/c (dont allowing permamnant access) and hopefully user will not be able to change password betwwn 5 days. cause to do that user need the password (to change existing password)

they show up on the page and it fills their username in, and they type their password and log in.

i saw that it i think in facebook most probably. most of sites are using string based access. even this board is using that one string i think (this forum dont asks for password)i am totally confused now :/

[[dx]]

Me too..

[ShadowMage]

What about Yahoo's "Keep me logged in for 2 weeks" checkbox? How does that work? Do they use cookies for that?

[[dx]]

I guess they do with time 60 secs x 60 mins x 24 hours x 14 days

[ShadowMage]

I guess they do with time 60 secs x 60 mins x 24 hours x 14 days

I know that. I was wondering about the security issues jsg was talking about. They must store the passwords somehow....

[justsomeguy]

I want to automatically login, completely bypassing the form, if, of course, the cookie is set with valid information. I want to make them be logged in for weeks at a time (or until they clear their cache). Are you saying that it isn't secure to do it that way?

Yes, that's what I'm saying.

is there any way to delete the hashed string in db after certain amount of time?

It would probably be more appropriate to store the timestamp in the database also and validate that as well.

so after 5 days if hashed string in cookie get compromised then noone can get login to that a/c (dont allowing permamnant access) and hopefully user will not be able to change password betwwn 5 days.

That's basically it, if you're just restricting or putting band-aids on the problem you're basically just hoping that it doesn't get compromised. "Hope" isn't a strategy.This is basically what Yahoo and IPB and Facebook and the others are doing. They sacrifice a little security so that people don't need to enter their passwords. If security is your priority, then that's not an option (obviously, security is not a priority for Facebook). Otherwise, think up a scheme that is unlikely to get exploited. One way may be to store a cookie with the user's username and a hashed version of their password which was salted with their IP address. When the server gets the cookie it checks their username, looks their password up in the database, gets their IP address, and hashes the database password with the IP to compare against the cookie. That means the cookie only works for the IP they started with, so it's one more level of protection but it's still not ideal. The more you do to get around security measures like requiring users to enter a password, the easier you make it for attackers to compromise your accounts. You need to find a balance of security and usability that works for you.

[[dx]]

So we can't do that in other way than cookie. Just hash username, hash password, hash IP, and unhashed ID. Al those hashed uses some salt.So when we check information select username, password, last ip where id=idif hash username from cookie == hashed username from db && hash pass from cookie == hashed pass from db && hash ip from cookie == hashed id from db {// do the restCould that be enough?

[Fmdpa]

This is basically what Yahoo and IPB and Facebook and the others are doing.

I guess they have done an evaluation and determined that users would prefer having a certain convenience and a little less security. After all, Facebook isn't a bank. I'm still undecided as to what I'll do.