Is my approach for persistent login secure?

I'm very much stuck with the reasonable secure approach to implement 'Remember me' feature in a login system. Here's my approach so far, Please advice me if it makes sense an开发者_如何学运维d is reasonably secure:

Logging:

1. User provides email and password to login (both are valid).. Get the user_id from DB Table Users by comparing provided email

2. Generate 2 random numbers hashed strings: key1, key2 and store in cookies. In DB Table COOKIES, store key1, key2 along with user_id.

To Check login:

1. If key1 and key2 both cookies exist, validate both keys in DB Table COOKIES (if a row with key1, and key2 exists, user is logged).

2. if cookie is valid, regenrate key2 and update it in cookie and also database.

Why re-genrating key: Because if someone steals cookie and login with that cookie, it will be working only until the real user login. When the real user will login, the stolen cookie will become invalid. Right?

Why do I need 2 keys: Because if i store user_id and single key in cookie and database, and the user want to remember the password on another browser, or computer, then the new key will be updated in database, so the user's cookie in earlier browser/PC will become invalid. User wont be able to remember password on more than one place.

Thanks for your opinions.

Consider this: How does adding a second cookie make it any more difficult for someone who can steal arbitrary cookies to log in as that user?

It doesn't. You have to tie it to something that the user can provide, but it can't be the same thing. If you can tie it to IP address, great. If not, consider hashing the user agent + user id using that first key as an HMAC or something. I'm still in the process of trying to design a secure login system myself, so I can tell you what definitely doesn't work--and this is one of those things.

Your scheme is based around cookie theft paranoia. There are really only three ways to steal cookies:

1. Man-in-the-middle attacks.
2. Cross-site Scripting or similar vulnerabilities that let arbitrary code run in the security context of your site.
3. Physical access to the machine with the browser.

We'll also classify malware as physical for our purposes.

Let's not worry about physical security. If a user loses control of his machine, he's going to have plenty more problems than worrying about your website!

Let's also not worry about XSS, blindly assuming that you're already doing all you can to prevent it.

That leaves MITM attacks.

One of the best (read: only) protections you can get against MITM attacks is SSL. If you are truly worried about MITM, you should be serving your entire site over SSL.

You don't need two of your own cookies. You just need the session cookie and a Remember Me cookie, which, by the way, you can simply store in a many-to-one table. This prevents the forced one-to-one relationship between users and Remember Mes.

Jay - this is the same thread as yesterday:

PHP login security

The answer is still the same, which is to say that SSL is the only way to ensure people can't sniff your plain text cookies. If you make a judgement call that you are willing to accept the risk that cookies might be intercepted, then your approach is fine (but more complex than necessary).

Assuming you've already concluded SSL isn't the approach you are going to work with, I'm not sure what benefit you think having two separate cookies provides over just a single cookie.

Don't tie to IP Address. This will render your website useless to any group of people sitting behind a NAT (or in a lot of cases aol).

Multiple cookies are only really helpful when one cookie is a prerequisite to receive the other.

In the case that the website requires a login, a secured session cookie can be generated and assigned and is then regenerated on subsequent page loads (it's impossible to perform session fixation against a site that doesn't keep the same session state identifier through the session).

In the case the website now prompts a user through some sort of checkout process, maybe you want to implement the second cookie as a secure token that is somehow linked to the first cookie. Both cookies become a prerequisite to transact through the site making it difficult to fixate.

Lastly, you'll probably want to do this linking in the $_SESSION super global. Doing this in the database can become quite costly if your website does any reasonable amount of traffic. That means each time a users session needs to be manipulated or started or stopped it requires a database connection and any number of queries/deletes/inserts/updates. This is not scalable.